DNSSEC and CVE-2012-1033 (Ghost domain names)
casey at deccio.net
Thu Feb 9 20:38:42 UTC 2012
On Thu, Feb 9, 2012 at 1:26 AM, Stephane Bortzmeyer <bortzmeyer at nic.fr>wrote:
> Unless you make DNSSEC mandatory, how will
> you solve the ghost domain problem with DNSSEC? If the resolver is
> sticky (will not go to the parent to ask the NS RRset), it won't check
> the NSEC at the parent either...
Actually, it should, in the spirit of DNSSEC. With a trusted anchor,
DNSSEC provides a chain of trust--whether it terminates in an insecure
delegation (i.e., with NSEC or NSEC3 RRs) or continues all the way to the
RRset begin sought. Once any records in that chain expire from cache, the
chain needs to be refreshed, or there is no way to tell if the name is
expected to have a secure validation path or not. While I don't know if
the "how" is specified in RFCs, in my recent observation both bind and
unbound do exhibit that behavior, though with slight differences.
> Is it because the resolver, even if sticky, re-queries the parent when
> the negative TTL of the (missing) DS records ends? And chokes when it
> receives back a NXDOMAIN?
Actually, what I have observed in my limited testing is that the resolver
re-queries the parent after the TTL of the NS RRset in the parent, not the
negative TTL of the parent. Upon receiving a NXDOMAIN response, it passes
that along to the client.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bind-users