Re: unbound signature expired
On Mon, Mar 18, 2024 at 08:04:38PM +0100, Evan Sherwood wrote: > > Wild guess, your time is off. > > Huh, I think you're right. `date` shows me 7 hours ahead of my timezone. > > I restarted ntpd and I see no errors in /var/log/daemon, but the time is > still off. I should be 1200 PDT but it's showing me as 1900 PDT (not > UTC). > > What do I do to fix this? Pretty sure I had set my timezone to > America/Los_Angeles when I installed OpenBSD. > ntpd will not jump the clock backwards. You need to do a manual set. -Otto
Re: unbound signature expired
> ... however I'm getting different errors now for the Slack-group > specific URLs: > > ... > > validation failure : signatures from unknown keys > from 2620:fe::fe Was able to fix this by running `unbound-anchor` after fixing my system clock. I think everything is working normally now. Thanks!
Re: unbound signature expired
> You can use rdate to jump the clock instead.
That updated my system clock to the correct time. dig queries against
Slack now work as expected, however I'm getting different errors now for
the Slack-group specific URLs:
```
# dig @::1 kubernetes.slack.com
; <<>> DiG 9.10.6 <<>> kubernetes.slack.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 50998
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 09 76 61 6c 69 64 61 74 69 6f 6e 20 66 61 69 6c 75 72 65 20 3c 6b
75 62 65 72 6e 65 74 65 73 2e 73 6c 61 63 6b 2e 63 6f 6d 2e 20 41 20 49 4e 3e
3a 20 73 69 67 6e 61 74 75 72 65 73 20 66 72 6f 6d 20 75 6e 6b 6e 6f 77 6e 20
6b 65 79 73 20 66 72 6f 6d 20 32 36 32 30 3a 66 65 3a 3a 66 65 ("..validation
failure : signatures from unknown keys from
2620:fe::fe")
;; QUESTION SECTION:
;kubernetes.slack.com. IN A
;; Query time: 20 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon Mar 18 13:46:54 PDT 2024
;; MSG SIZE rcvd: 149
```
Again, querying directly from Quad9 works.
Any idea what's going on here?
Re: unbound signature expired
On 2024-03-18, Evan Sherwood wrote: >> Wild guess, your time is off. > > Huh, I think you're right. `date` shows me 7 hours ahead of my timezone. > > I restarted ntpd and I see no errors in /var/log/daemon, but the time is > still off. I should be 1200 PDT but it's showing me as 1900 PDT (not > UTC). > > What do I do to fix this? Pretty sure I had set my timezone to > America/Los_Angeles when I installed OpenBSD. ntpd will take ages to correct that much offset (it can set the clock _forwards_ more quickly to the time of a trusted server at startup, but not backwards). You can use rdate to jump the clock instead. -- Please keep replies on the mailing list.
Re: unbound signature expired
> Wild guess, your time is off. Huh, I think you're right. `date` shows me 7 hours ahead of my timezone. I restarted ntpd and I see no errors in /var/log/daemon, but the time is still off. I should be 1200 PDT but it's showing me as 1900 PDT (not UTC). What do I do to fix this? Pretty sure I had set my timezone to America/Los_Angeles when I installed OpenBSD.
Re: unbound signature expired
They seem to be using extremely short-lived signatures, probably created
by an online-signer.
$ dig +short ns slack.com
ns-1493.awsdns-58.org.
ns-166.awsdns-20.com.
ns-1901.awsdns-45.co.uk.
ns-606.awsdns-11.net.
$ TZ=UTC dig @ns-1493.awsdns-58.org. +norec +dnssec +multiline +nocrypto
slack.com
; <<>> DiG 9.18.24 <<>> @ns-1493.awsdns-58.org. +norec +dnssec +multiline
+nocrypto slack.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8196
;; flags: qr aa ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;slack.com. IN A
;; ANSWER SECTION:
slack.com. 60 IN A 18.134.215.41
slack.com. 60 IN A 18.169.120.191
slack.com. 60 IN A 18.168.172.238
slack.com. 60 IN A 18.169.61.189
slack.com. 60 IN RRSIG A 13 2 60 (
20240318194315 20240318174215 8040 slack.com.
[omitted] )
;; Query time: 44 msec
;; SERVER: 2600:9000:5305:d500::1#53(ns-1493.awsdns-58.org.) (UDP)
;; WHEN: Mon Mar 18 18:42:15 UTC 2024
;; MSG SIZE rcvd: 207
The signature is only valid for an hour.
Wild guess, your time is off.
On 2024-03-18 19:20 +01, Evan Sherwood wrote:
> I have an unbound server using Quad9 as an upstream DNS provider. I have
> been unable to resolve records from slack.com recently using my local
> unbound.
>
> On the server:
>
> ```
> # dig @::1 slack.com
>
> ; <<>> dig 9.10.8-P1 <<>> @::1 slack.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54174
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; EDE: 7 (Signature Expired): 76 61 6c 69 64 61 74 69 6f 6e 20 66 61
> 69 6c 75 72 65 20 3c 73 6c 61 63 6b 2e 63 6f 6d 2e 20 41 20 49 4e 3e
> 3a 20 73 69 67 6e 61 74 75 72 65 20 65 78 70 69 72 65 64 20 66 72 6f
> 6d 20 32 36 32 30 3a 66 65 3a 3a 66 65 ("validation failure
> : signature expired from 2620:fe::fe")
> ;; QUESTION SECTION:
> ;slack.com. IN A
>
> ;; Query time: 26 msec
> ;; SERVER: ::1#53(::1)
> ;; WHEN: Mon Mar 18 18:02:25 PDT 2024
> ;; MSG SIZE rcvd: 116
> ```
>
> But when I try to query Quad9 directly, it works:
>
> ```
> # dig @2620:fe::fe slack.com
>
> ; <<>> dig 9.10.8-P1 <<>> slack.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2705
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ;; QUESTION SECTION:
> ;slack.com. IN A
>
> ;; ANSWER SECTION:
> slack.com. 10 IN A 35.81.85.251
> slack.com. 10 IN A 44.234.235.93
> slack.com. 10 IN A 54.70.179.16
> slack.com. 10 IN A 44.237.180.172
> slack.com. 10 IN A 52.89.90.67
> slack.com. 10 IN A 54.245.50.245
> slack.com. 10 IN A 54.188.33.22
> slack.com. 10 IN A 54.71.95.193
> slack.com. 10 IN A 35.82.91.193
>
> ;; Query time: 2 msec
> ;; SERVER: 2620:fe::fe#53(2620:fe::fe)
> ;; WHEN: Mon Mar 18 18:05:05 PDT 2024
> ;; MSG SIZE rcvd: 182
> ```
>
> I've tried
>
> - `unbound-control reload`
> - `unbound-control flush slack.com`
> - `unbound-anchor`
>
> ... and there's no change. All other domains I've tried work.
>
> I am using one of StevenBlack's block lists and I changed that recently
> (from one list to another one), if that's relevant.
>
> I tried removing the block list entirely and saw no change.
>
> Here's my unbound.conf:
>
> ```
> server:
> interface: ::1
> interface: :::::
> do-ip6: yes
> ede: yes
> do-nat64: yes
> access-control: ::0/0 refuse
> access-control: ::1 allow
> access-control: ::::: allow
> access-control: 192.168.1.0/32 allow
> access-control: :::5700::/64 allow
> access-control: :::5702::/64 allow
> do-not-query-localhost: no
> hide-identity: yes
> hide-version: yes
> auto-trust-anchor-file: "/var/unbound/db/root.key"
> val-log-level: 2
> aggressive-nsec: yes
> private-address: ::1/128
> private-address: :::0:0/96
> private-address: fd00::/8
> private-address: fe80::/10
> module-config: "dns64 validator iterator"
> include: /etc/unwind.conf.deny
>
> remote-control:
> control-enable: yes
> control-interface: /var/run/unbound.sock
>
> forward-zone:
> name: "."
> forward-addr:
unbound signature expired
I have an unbound server using Quad9 as an upstream DNS provider. I have
been unable to resolve records from slack.com recently using my local
unbound.
On the server:
```
# dig @::1 slack.com
; <<>> dig 9.10.8-P1 <<>> @::1 slack.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54174
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 7 (Signature Expired): 76 61 6c 69 64 61 74 69 6f 6e 20 66 61 69 6c 75
72 65 20 3c 73 6c 61 63 6b 2e 63 6f 6d 2e 20 41 20 49 4e 3e 3a 20 73 69 67 6e
61 74 75 72 65 20 65 78 70 69 72 65 64 20 66 72 6f 6d 20 32 36 32 30 3a 66 65
3a 3a 66 65 ("validation failure : signature expired from
2620:fe::fe")
;; QUESTION SECTION:
;slack.com. IN A
;; Query time: 26 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon Mar 18 18:02:25 PDT 2024
;; MSG SIZE rcvd: 116
```
But when I try to query Quad9 directly, it works:
```
# dig @2620:fe::fe slack.com
; <<>> dig 9.10.8-P1 <<>> slack.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2705
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;slack.com. IN A
;; ANSWER SECTION:
slack.com. 10 IN A 35.81.85.251
slack.com. 10 IN A 44.234.235.93
slack.com. 10 IN A 54.70.179.16
slack.com. 10 IN A 44.237.180.172
slack.com. 10 IN A 52.89.90.67
slack.com. 10 IN A 54.245.50.245
slack.com. 10 IN A 54.188.33.22
slack.com. 10 IN A 54.71.95.193
slack.com. 10 IN A 35.82.91.193
;; Query time: 2 msec
;; SERVER: 2620:fe::fe#53(2620:fe::fe)
;; WHEN: Mon Mar 18 18:05:05 PDT 2024
;; MSG SIZE rcvd: 182
```
I've tried
- `unbound-control reload`
- `unbound-control flush slack.com`
- `unbound-anchor`
... and there's no change. All other domains I've tried work.
I am using one of StevenBlack's block lists and I changed that recently
(from one list to another one), if that's relevant.
I tried removing the block list entirely and saw no change.
Here's my unbound.conf:
```
server:
interface: ::1
interface: :::::
do-ip6: yes
ede: yes
do-nat64: yes
access-control: ::0/0 refuse
access-control: ::1 allow
access-control: ::::: allow
access-control: 192.168.1.0/32 allow
access-control: :::5700::/64 allow
access-control: :::5702::/64 allow
do-not-query-localhost: no
hide-identity: yes
hide-version: yes
auto-trust-anchor-file: "/var/unbound/db/root.key"
val-log-level: 2
aggressive-nsec: yes
private-address: ::1/128
private-address: :::0:0/96
private-address: fd00::/8
private-address: fe80::/10
module-config: "dns64 validator iterator"
include: /etc/unwind.conf.deny
remote-control:
control-enable: yes
control-interface: /var/run/unbound.sock
forward-zone:
name: "."
forward-addr: 2620:fe::fe
```
This feels like a caching issue to me, but I don't know what to do to
resolve it.
Unbound logs show the same error from the failing dig command.
Would appreciate any help.
