Bug ? atleast a difference in behaviour

Unbound
1

Hi,

The following domains are 'down':
nmap.org
insecure.org

And I noticed a Unbound has different behaviour then I'm used to.

It seems the nameservers for those domains: ns1.titan.net. [64.13.134.58] and ns2.titan.net. [64.13.134.59] don't respond to questions about those domains.

And I noticed a difference in behaviour in Unbound 1.3 in comparison with Unbound 1.2 forwarding to 2 PowerDNS-recursors.

Unbound 1.3 is operating on OpenBSD 4.5, linked libs: event internal, ldns 1.6.0_20090602, OpenSSL 0.9.8j 07 Jan 2009, linked modules: validator iterator
Unbound 1.2 is operating on OpenBSD 4.4, linked libs: event internal, ldns 1.6.0_20090602, OpenSSL 0.9.8j 07 Jan 2009, linked modules: validator iterator

The first one is operating on it's own, the second is forwarding it's queries to 2 PowerDNS-recursors and is hardly ever used, just for internal DNS.

This works:

When I sent the Unbound 1.2 (which forwards to PowerDNS) the following request:

$ dig nmap.org ns | grep IN
;nmap.org. IN NS
nmap.org. 85325 IN NS ns1.titan.net.
nmap.org. 85325 IN NS ns2.titan.net.
ns1.titan.net. 171725 IN A 64.13.134.58
ns2.titan.net. 171725 IN A 64.13.134.59

When I sent the same request to Unbound 1.3, I get no answer, at all.

This is not just because the PowerDNS-recursors still those nameservers in cache, because:

$ dig +short org ns
c0.org.afilias-nst.info.
a2.org.afilias-nst.info.
d0.org.afilias-nst.org.
a0.org.afilias-nst.info.
b2.org.afilias-nst.org.
b0.org.afilias-nst.org.

$ dig +norec @c0.org.afilias-nst.info. nmap.org ns | grep IN
;nmap.org. IN NS
nmap.org. 86400 IN NS ns2.titan.net.
nmap.org. 86400 IN NS ns1.titan.net.

$ dig +short net ns
l.gtld-servers.net.
j.gtld-servers.net.
c.gtld-servers.net.
k.gtld-servers.net.
e.gtld-servers.net.
i.gtld-servers.net.
b.gtld-servers.net.
d.gtld-servers.net.
g.gtld-servers.net.
m.gtld-servers.net.
a.gtld-servers.net.
h.gtld-servers.net.
f.gtld-servers.net.

$ dig +short +norec @l.gtld-servers.net. ns2.titan.net.
64.13.134.59

Hope this was helpful.

Have a nice day,
  Leen Besselink.

2

Are you sure you dont just have different settings for harden-glue
or harden-referral-path? See if you can see the same difference
when resolving an NS record for www.rbc.com (a site known to be
reachable through trusting glue)

Paul

3

Paul Wouters wrote:

4

* Leen Besselink:

This is not just because the PowerDNS-recursors still those
nameservers in cache, because:

But it seems to me that ns1.titan.net and ns2.titan.net are down right
now.

5

Florian Weimer wrote:

* Leen Besselink:

This is not just because the PowerDNS-recursors still those
nameservers in cache, because:

But it seems to me that ns1.titan.net and ns2.titan.net are down right
now.

That's not a reason not to return what the toplevel nameservers return
when I'm asking for the nameservers of the domain.

If that makes any sense :wink:

6

Well, for me both ns1.titan.net. and ns2.titan.net, which are NS for
both titan.net and insecure.org are unreachable. Both are in the same
/24 too. I guess Fyodor needs a DNS admin :stuck_out_tongue:

I'd still still you were seeing some caching on one instance of unbound
that the other instance just did not have.

Paul

7

Paul Wouters wrote:

$ dig +short +norec @l.gtld-servers.net. ns2.titan.net.
64.13.134.59

Hope this was helpful.

Are you sure you dont just have different settings for harden-glue
or harden-referral-path? See if you can see the same difference
when resolving an NS record for www.rbc.com (a site known to be
reachable through trusting glue)

Changing those settings doesn't matter a thing. You can try those
domains on your recursive DNS, if you like. :slight_smile:

Well, for me both ns1.titan.net. and ns2.titan.net, which are NS for
both titan.net and insecure.org are unreachable. Both are in the same
/24 too. I guess Fyodor needs a DNS admin :stuck_out_tongue:

That's Fyodor's problem luckily. :slight_smile:

I'd still still you were seeing some caching on one instance of unbound
that the other instance just did not have.

The one just talks to the powerdns-recursors, I think that's the difference.

I get the same behaviour when talking directly to them, as I do below.

Paul

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. :slight_smile:

8

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

9

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.
    
Note that zonecheck.fr and similar sites apparently don't believe
the glue either.

  jaap

10

Jaap Akkerhuis wrote:

    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.
    
Note that zonecheck.fr and similar sites apparently don't believe
the glue either.

I'm not a protocol expert, but why would you not trust the toplevel
nameserver if DNSSEC isn't enabled ?

11

The records are "hints". They are published not by the zone owners,
but by there parents. This is required to void a recursion loop.
If you need ns1.example.com. to find ns1.example.com. someone else
will have to tell you. This is what glue records are for.

Since these are "out of zone" records, they are considered hints.
It's common sense to verify the information at the proper source.

It's like verifying gossip :slight_smile:

Paul

12

Paul Wouters wrote:

I'm not a protocol expert, but why would you not trust the toplevel
nameserver if DNSSEC isn't enabled ?

The records are "hints". They are published not by the zone owners,
but by there parents. This is required to void a recursion loop.
If you need ns1.example.com. to find ns1.example.com. someone else
will have to tell you. This is what glue records are for.

I know this part.

Since these are "out of zone" records, they are considered hints.
It's common sense to verify the information at the proper source.

The problem I see with that is, the proper source is just as
trustworthy as the parent.

Which is: not much, if any, atleast without something like DNSSEC to
verify something.

If we'd be talking about a CNAME that would something else, when we
were talking about "out of zone" records. But the parent-zone ?

If we can't trust the parent-zone a little, we can't trust the child,
because the parent-zone pointed us to it.

It's like verifying gossip :slight_smile:

Paul

Not that I want to argue with a DNS-expert, but I'm just surprised
at the answer.

Ooh, darn I think I know now, it's because it's a different domain,
isn't it ?

titan.net or it's parents, other then the root are in no way related
to nmap.org.

I wonder if Bert considers it a bug in 3.1.7 ?

13

Hi Leen,

Paul Wouters wrote:

I'm not a protocol expert, but why would you not trust the toplevel
nameserver if DNSSEC isn't enabled ?

The records are "hints". They are published not by the zone owners,
but by there parents. This is required to void a recursion loop.
If you need ns1.example.com. to find ns1.example.com. someone else
will have to tell you. This is what glue records are for.

I know this part.

Right.

Since these are "out of zone" records, they are considered hints.
It's common sense to verify the information at the proper source.

The problem I see with that is, the proper source is just as
trustworthy as the parent.

Which is: not much, if any, atleast without something like DNSSEC to
verify something.

If we'd be talking about a CNAME that would something else, when we
were talking about "out of zone" records. But the parent-zone ?

If we can't trust the parent-zone a little, we can't trust the child,
because the parent-zone pointed us to it.

No this is not true. This is because unbound strictly adheres to
RFC2181. The 'hint' was part of the additional section. And you
want an answer in the answer section. For that unbound really wants
to get the actual answer - not just something tacked on as a hint.

So unbound does not upgrade the hint to 'full answer' status.
If you do not do this it likely makes you vulnerable to poisoning.

It's like verifying gossip :slight_smile:

Yes!

Leen is of course correct in that the parent could point to a
different child, but apart from that (which you indeed need to
solve with DNSSEC signing the DS of the child), you can verify
the hints today by looking at the child.

The child is authoritative for the data.
Not the parent. The child zone is the owner of the data
and thus its answers should be used to return to clients.
Unbound does use the hints of course, to break the loop and
look things up, but that does not mean that a 'bad hint'
should be allowed to be returned to a client asking an
answer.

So, as Paul already surmised, this is part of Unbound's
anti-poisoning measures. It is not optional.

Not that I want to argue with a DNS-expert, but I'm just surprised
at the answer.

Ooh, darn I think I know now, it's because it's a different domain,
isn't it ?

titan.net or it's parents, other then the root are in no way related
to nmap.org.

Yes that too! The hints that .org gives for titan.net are not trusted
by unbound again for anti-poisoning reasons. This one is optional,
you can set harden-glue: false and it will trust this sort of hints
(just for hints, not for answers), which can 'unbreak' some lookups,
at the cost of becoming a target for (a specially crafted) poisoning
attack...

I wonder if Bert considers it a bug in 3.1.7 ?

Well, DNSSEC stops this poisoning hole as well, maybe Bert is
prioritizing.

Best regards,
   Wouter

14

Bert wrote:

I wonder if Bert considers it a bug in 3.1.7 ?

That would have been Bert Hubert of PowerDNS.

Did somebody call me?

Bert

----
Bert Goes Places
bert.secret-wg.org

But it's good to see you have IPv6. :slight_smile:

15

No this is not true. This is because unbound strictly adheres to
RFC2181. The 'hint' was part of the additional section. And you

Ah, you explain it better. The additional section is what Paul meant
with hint. Ofcourse. OK, now I know why.

Sometimes it's better to call things by their real name. :slight_smile:

Anyway, thank you all for your time and explanation.

Have a nice day,
  Leen.