[Unbound-users] bug ? atleast a difference in behaviour

[Paul Wouters]

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