On Sun, 6 Sep 2009, Leen Besselink wrote: > The one just talks to the powerdns-recursors, I think that's the difference. > I just installed powerdns-recursor on my desktop to test it and it works when I do: > > dig @127.0.0.1 nmap.org ns > > (although it times out the first time) > > it will show the titan-nameservers as the nameservers for nmap.org. > > That's the difference I'm talking about. > > This is the powerdns-recursor (with an empty cache): > > $ dig @127.0.0.1 nmap.org ns > > ; <<>> DiG 9.5.1-P2 <<>> @127.0.0.1 nmap.org ns > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 64235 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;nmap.org. IN NS > > ;; Query time: 3604 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sun Sep 6 19:11:16 2009 > ;; MSG SIZE rcvd: 26 > $ dig @127.0.0.1 nmap.org ns > > ; <<>> DiG 9.5.1-P2 <<>> @127.0.0.1 nmap.org ns > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37573 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 > > ;; QUESTION SECTION: > ;nmap.org. IN NS > > ;; ANSWER SECTION: > nmap.org. 86390 IN NS ns1.titan.net. > nmap.org. 86390 IN NS ns2.titan.net. > > ;; ADDITIONAL SECTION: > ns2.titan.net. 172790 IN A 64.13.134.59 > ns1.titan.net. 172790 IN A 64.13.134.58 > > ;; Query time: 1 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sun Sep 6 19:11:22 2009 > ;; MSG SIZE rcvd: 103 > > This is unbound with or without an empty cache: > > $ dig @172.20.1.1 nmap.org ns > > ; <<>> DiG 9.5.1-P2 <<>> @172.20.1.1 nmap.org ns > ; (1 server found) > ;; global options: printcmd > ;; connection timed out; no servers could be reached > > Do you see what I mean with a diffence in behaviour. :-) So powerdns-recursor uses the glue and treats it as authoritative data. Perhaps it has an option to change that and allow "hardening" of the data too (kind of as per draft-wijngaards-dnsext-resolver-side-mitigation-01) Unbound seems to want to verify the glue at the authoritative server. That's why I thought of unbound's harden-referral-path: setting. It's ony of the anti-kaminsky measures of not just blindly trusting any using glue you got. Since there is no working authoritative source for titan.net, unbound with harden-referral-path: yes fails to resolve titan.net and therefor insecure.org. Paul