On Thu, Feb 9, 2012 at 1:26 AM, Stephane Bortzmeyer <bortzme...@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. Casey
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
