Domain not being resolved?

Unbound
1

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 :blush: And google can resolve this just fine.

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.

2

Hi Søren,

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 :blush: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

3

(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

4

Hi Søren,

It looks like frederiksberg.dk is doing an algorithm roll-over, from
SHA1 to SHA256. There are SHA256 DS records in the parent zone, but the
zone itself is still signed with the older key and SHA1 signatures.

Regards,
Anand