Maintained by: NLnet Labs

SV: Domain not being resolved?

Søren Peter Skou
Wed Apr 18 13:10:12 CEST 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.
> >
>