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 _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
