Re: An interoperability disaster

["D. J. Bernstein" <djb@cr.yp.to>]

I agree that parent configuration advice is generally an operations
issue. However, resolution and caching procedures are protocol issues.
They're things that I have to deal with as an implementor, and they're
things that DNSEXT should address.

Here's one possible explanation for the missing A records: someone asked
the cache for the records a few hundred times. Under BIND's new ``reduce
TTLs for queried ARs by 5%'' policy, the TTLs would drop rapidly, and
would expire moments later. Can anyone explain this strange policy?

Mark.Andrews@nominum.com writes:
> However the NS RRset is correctly rejected as not being as credable as
> that from the child zone.

I've sent a message to bugtraq shredding your ``credibility'' notion.
You're rejecting essential NS records from the parent even when they're
all _newer_ than what you have cached. An attacker can exploit this to
trivially break your access to any domain that changes all its NS names.

Are you going to blame sysadmins who change more than one NS at once
(shame on them for switching ISPs!) and tell me that this is an
operations issue?

You're also blatantly violating the RFC 1034 resolution procedure. I
realize that RFC 2181 requires this; RFC 2181 is wrong, and DNSEXT
should fix it.

> Before you make more complaints about credability checks, think
> about the case when zone are actually signed.  To get out of this
> case you would have to throw out signed data in favour of unsigned
> data.

That ``signed data'' is (1) useless---that's why you're contacting the
parent!---and (2) meaningless without the parent's approval. DNSSEC
signatures need to be provided all the way up the chain to a domain
whose key you know, normally the root.

I find it very strange that you're willing to shred the TTLs of valid
A records, and to throw away essential NS records from the parent, but
not to discard useless records from your cache.

---Dan