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

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Leen,

On 09/07/2009 01:06 AM, Leen Besselink wrote:
> 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 :)

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkqkscsACgkQkDLqNwOhpPggDgCfXj6V/GHJzpSYDyBqEzFT+pbi
XFUAmwdiGzZ6xWae9BqiQOr+Hk5E4xLe
=/VtV
-----END PGP SIGNATURE-----