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.

to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.