This is a discussion on Re: the RD bit is troubling me today - DNS ; Paul Vixie writes: > We've spent about half of the total DNSSEC development era to date (that is > around six years out of the twelve) going down ratholes due to > misunderstanding 1034/1035. Sometimes we amend 1034/1035 to explain ...
> We've spent about half of the total DNSSEC development era to date (that is
> around six years out of the twelve) going down ratholes due to
> misunderstanding 1034/1035. Sometimes we amend 1034/1035 to explain something
> that didn't used to need to be explained; sometimes we amend 1034/1035 to
> explain something that we thought had been explained that turned out to have
> ambiguities... The result of DNSSEC is that we now understand far more about
> the delegation model and wildcards (among other things) than we used to know.
> Sort of like one of the great side-benefits of NASA's moon programme was the
> ballpoint pen.
> There's been some interest recently in the question "should a nameserver also
> be recursive, if it's authoritative for any zones?" The old, sad, answer has
> been "don't do it, since BIND4 was terrible about mixing recursive and
> authority data, and dual-purpose nameservers are a recipe for cache pollution"
> but it turns out that since BIND8, BIND9, and all modern non-BIND servers can
> safely mix authority and recursive data, folks are starting to do this again.
> It's not that hard to run two nameservers on a host, and just use different
> IP addresses for your resolv.conf file vs. your NS RR -> A/AAAA RR chain, but
> even though it's not hard, it's not as easy as just using one nameserver.
> While the RD bit in a query can disambiguate the case of a name-below-zonecut
> such that if RD=0 a dual-use server will return a delegation whereas if RD=1
> it will go fetch the data, I don't think this helps when the qname is equal to
> a zonecut name. An authority server should respond with a non-AA delegation
> in that case, since the zone ends above the zonecut. A recursive server
> should respond with a non-AA answer in that case. But the non-AA answer
> should be first retrieved from the apex of the subzone, by following the
> delegation, all without allowing an RD=1 query to affect subsequent RD=0
> results. A dual-use server would therefore have to maintain separate NS
> RRsets (and associated A/AAAA glue) for RD=0 vs RD=1 answers.
> 1034/1035 does not anywhere say this, but it's the implication of the other
> "intent of the framers" clarifications we've made to 1034/1035 during the
> DNSSEC development era. But if we were going to write another clarification
> document on this point, I'd rather we just said "nameservers that offer both
> authority and recursive service are undefined, please just don't do it" than
> to try to describe how many RD bits should be dancing on the head of this pin.
This discussion is missing a crucial part: What happens when a
dual-server does not maintain a separate NS RRset for RD=0 and RD=1?
In other words, I'm looking for the failure mode caused by this
problem. There are two cases two consider. The first case is when
the dual-use server always send the RD=0 answer, and the second case
where it always send the RD=1 answer.
Forbidding dual-use servers seem like a slightly unrealistic solution
to me, given deployed use. Without understanding what the actual
interoperability problems are (in contrast to implementation
problems), it seems that there is no justification for that solution.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.