(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:[email protected]] På > vegne af W.C.A. Wijngaards via Unbound-users > Sendt: 18. april 2018 12:10 > Til: [email protected] > 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. > > >
