SV: Domain not being resolved?
Søren Peter Skou
sps at DanskKabelTV.dk
Wed Apr 18 11:10:12 UTC 2018
(Apologies for stupid quoting - Corporate Exchange does not like me..)
Having fiddled a bit around with unbound-host, I got this :
[1524049237] libunbound[21181:0] info: Did not match a DS to a DNSKEY, thus bogus.
[1524049237] libunbound[21181:0] info: Could not establish a chain of trust to keys for frederiksberg.dk. DNSKEY IN
[1524049237] libunbound[21181:0] info: resolving frederiksberg.dk. DNSKEY IN
frederiksberg.dk has address 131.165.177.71
validation failure <frederiksberg.dk. A IN>: no keys have a DS with algorithm RSASHA256 from 74.116.176.8 for key frederiksberg.dk. while building chain of trust
[1524049237] libunbound[21181:0] info: query response was nodata ANSWER
validation failure <frederiksberg.dk. AAAA IN>: key for validation frederiksberg.dk. is marked as invalid because of a previous validation failure <frederiksberg.dk. A IN>: no keys have a DS with algorithm RSASHA256 from 74.116.176.8 for key frederiksberg.dk. while building chain of trust
So, there's something wrong with the domain after all, strange that dnssec-validation does not catch this.
Best regards
Søren P. Skou
> -----Oprindelig meddelelse-----
> Fra: Unbound-users [mailto:unbound-users-bounces at unbound.net] På
> vegne af W.C.A. Wijngaards via Unbound-users
> Sendt: 18. april 2018 12:10
> Til: unbound-users at unbound.net
> Emne: Re: Domain not being resolved?
>
> Hi Søren,
>
> On 18/04/18 11:54, Søren Peter Skou via Unbound-users wrote:
> > Hiya all,
> >
> >
> >
> > This perplexes me a bit. My unbound seems to have taken a dislike
> > towards a couple of domains. Specificially frederiksberg.dk and fkb.dk
> > and the tld .ke If I try doing a dig ns frederiksberg.dk and equivalent
> > for fkb.dk – I simply get a SERVFAIL. Initially I thought it might be
> > something related to DNSSEC, but
> > https://dnssec-debugger.verisignlabs.com states all green for both
> > domains. Now, neither of the domains are mine, I still need to resolve
> > them 😊And google can resolve this just fine.
>
> It works fine for me with unbound; I see no problems with validation
> either. Perhaps you could enable verbosity, say at level 4, and see
> what the output is. It then prints out the 'dig-style' outputs of all
> the packets retrieved. And then you can see at what point it concludes
> SERVFAIL, for example by searching the output for the keyword servfail.
>
> If you had a validation failure your val-log-level: 2 would have already
> printed that as a report to your logs.
>
> Best regards, Wouter
>
> >
> >
> >
> > Example failing for fkb.dk:
> >
> > -bash-4.2$ dig ns fkb.dk @62.61.130.1
> >
> >
> >
> > ; <<>> DiG 9.10.4-P3 <<>> ns fkb.dk @62.61.130.1
> >
> > ;; global options: +cmd
> >
> > ;; Got answer:
> >
> > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 50361
> >
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> >
> >
> >
> > ;; OPT PSEUDOSECTION:
> >
> > ; EDNS: version: 0, flags:; udp: 4096
> >
> > ;; QUESTION SECTION:
> >
> > ;fkb.dk. IN NS
> >
> >
> >
> > ;; Query time: 82 msec
> >
> > ;; SERVER: 62.61.130.1#53(62.61.130.1)
> >
> > ;; WHEN: Wed Apr 18 11:39:06 CEST 2018
> >
> > ;; MSG SIZE rcvd: 35
> >
> >
> >
> > Same result for both, however if I ask cloudflare, google or a Bind
> > recursive server – I get a the result I expect.
> >
> >
> >
> > -bash-4.2$ dig ns fkb.dk @62.61.136.249
> >
> >
> >
> > ; <<>> DiG 9.10.4-P3 <<>> ns fkb.dk @62.61.136.249
> >
> > ;; global options: +cmd
> >
> > ;; Got answer:
> >
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23239
> >
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3
> >
> >
> >
> > ;; OPT PSEUDOSECTION:
> >
> > ; EDNS: version: 0, flags:; udp: 4096
> >
> > ;; QUESTION SECTION:
> >
> > ;fkb.dk. IN NS
> >
> >
> >
> > ;; ANSWER SECTION:
> >
> > fkb.dk. 86400 IN NS ns3.prodns.net.
> >
> > fkb.dk. 86400 IN NS ns1.prodns.net.
> >
> > fkb.dk. 86400 IN NS ns9.prodns.net.
> >
> > fkb.dk. 86400 IN NS ns2.prodns.net.
> >
> > fkb.dk. 86400 IN NS ns4.prodns.net.
> >
> >
> >
> > ;; ADDITIONAL SECTION:
> >
> > ns9.prodns.net. 95119 IN A 74.116.176.8
> >
> > ns9.prodns.net. 8719 IN AAAA 2001:678:5::8
> >
> >
> >
> > ;; Query time: 66 msec
> >
> > ;; SERVER: 62.61.136.249#53(62.61.136.249)
> >
> > ;; WHEN: Wed Apr 18 11:41:50 CEST 2018
> >
> > ;; MSG SIZE rcvd: 179
> >
> >
> >
> > Same goes for google (8.8.8.8) and cloudflare (1.1.1.1).
> >
> >
> >
> >
> >
> > Configuration is as follows:
> >
> > server:
> >
> > auto-trust-anchor-file: "/usr/pkg/etc/unbound/root.key"
> >
> > verbosity: 1
> >
> > do-ip4: yes
> >
> > do-ip6: yes
> >
> > do-udp: yes
> >
> > do-tcp: yes
> >
> >
> >
> > interface: 62.61.130.1
> >
> > port: 53
> >
> > statistics-interval: 60
> >
> > extended-statistics: yes
> >
> > statistics-cumulative: yes
> >
> > root-hints: "/usr/pkg/etc/unbound/root.hints"
> >
> > hide-identity: no
> >
> > hide-version: yes
> >
> > use-caps-for-id: no
> >
> > harden-glue: yes
> >
> > harden-dnssec-stripped: yes
> >
> > cache-min-ttl: 3600
> >
> > cache-max-ttl: 86400
> >
> > prefetch: yes
> >
> > num-threads: 4
> >
> > msg-cache-slabs: 8
> >
> > rrset-cache-slabs: 8
> >
> > infra-cache-slabs: 8
> >
> > key-cache-slabs: 8
> >
> > outgoing-range: 950
> >
> > num-queries-per-thread: 512
> >
> > rrset-cache-size: 256m
> >
> > msg-cache-size: 128m
> >
> > so-rcvbuf: 204k
> >
> > so-sndbuf: 204k
> >
> > unwanted-reply-threshold: 10000
> >
> > val-clean-additional: no
> >
> > val-log-level: 2
> >
> >
> >
> >
> >
> > I may be overlooking something extremely obvious, however I cannot see
> > what that might be.
> >
>
More information about the Unbound-users
mailing list