peter wrote:

# Algorithms 4.3.2 and 5.3.3 in RFC 1034 say that in the case RD=1 the query
# will be answered by local data. So, if a server is authoritative for the
# parent, but not for the child, a query would be satisfied from "local data",
# i.e. the NS RRSet that's present in the parent.

that's an odd "i.e.", one i consider nonsequitur. 1034/1035 are at best
unclear and at worst inconsistent and at least guideance-free on this point,
as they were on some other dnssec-relevant definitions like ownership of data
at delegation points, and the real meaning of wildcards.

# The response won't be authoritative, but why should that matter? The problem
# seems to be that you won't be able to receive a signed response this
# way. But then, why would one ask for an NS RRSet in the first place (yeah,
# DynUpd, I know, but QTYPE SOA is better here anyway)?

what i want to know is, what's the right answer. the rest of 1034/1035, and
common programmer-in-the-street intepretation, is that a non-empty response to
an RD=1 query will contain data that came from the authority zone. we know
(because dnssec required that we learn) that an authority-only server should
not respond to queries for its out-of-zone glue. we know (again, from dnssec)
that zone-bottom NS RRs are only authoritative in the child zone (where they
would be apex NS RRs) and that an authority server should return delegations
rather than answers when queried about them. what we don't know, and what i
really do want to know now, is what the right answer is to an RD=1 query that
matches a zone-bottom NS RRset. the answer to this will bear on how we handle
future debates on the merits of wildcard NS RRsets, among other things.

simon wrote:

# 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?

that leads to the fallacy of the argument from utility. i didn't want to
go there but see below.

# 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.

there are more than two cases. it can answer with one type of answer unless
it has ever answered with the other type of answer; it can return SERVFAIL or
an upward delegation; it can return inconsistent answers across a loadbalance
set if some loadbalance members are also configured for recursion and others
not. there are all kinds of undefined things that can happen -- that's why
i called them "undefined" in my previous mail on this topic.

# 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.

rfc's have no power to forbid. however, they are looked at by folks who want
to hold eachother to a standard when negotiating a contract, and they are even
sometimes looked at by people who are wondering what the right thing to do
would be, either out of curiousity or because they want to do the right thing.

peter added:

# Agreed. "Don't" won't work. "Education" (quoting Olaf) will need to explain
# the (theoretical) problem and its practical relevance.

i'm not really as interested in practical relevance as i am in nailing down
the definition of the protocol so that we know what "the right answer" is, and
under what conditions, and so on.

but consider the case where the parent's zone-bottom delegation is wrong or
out of date -- a VERY common case, as most of you know first hand. (and it's
likely to remain the common case until the DNS protocol or a new protocol
adds the ability for parent-zone delegation glue to be updated by child zone
servers or child zone operators, and yes, i know this is being discussed in
conjunction with the key rollover feature set, but that's not relevant here.)

if the parent zone-bottom NS RRset and the child zone-apex NS RRset differ,
then by definition, the parent is wrong. we know this because the parent's
zozne-bottom NS RRset is called glue and is not authoritative for dnssec
purposes; we know because other recursive/caching DNS protocol agents will
prefer to cache the authority data from the child zone as "more credible",
and we know it because it's the least-strenuous interpretation of 1034/1035's
words on the topic.

if the parent's zone-bottom NS RRset happens to be wrong, or for that matter,
can be wrong or is known to be sometimes or often wrong, then we ought to be
limiting the use of that data. it ought to be used not only as seldom as
possible, but also, for as few purposes as possible. there is only one real
purpose for it, and that's delegation. if it's so wrong that delegation won't
work, then we're done, because the child's apex NS RRset will never be seen.
if it's only partly wrong, such that some of the nameservers designated by the
parent's zone-bottom NS RRset exist, some don't, some have had their names
changed, and so on... but there is some "data path" through the bad data that
does in fact lead to the right and proper and intended child zone, then we're
not done, and we have to ask, what NS RRset should a dual-purpose server give
out if asked for an NS RRset at its zone-bottom?

the rule of least astonishment demands, in my interpretation, that if RD=1 and
a response's answer section will be nonempty (that is, it's not a referral),
the answer section contain only data that came, originally, from the authority
zone. that would require the dual-purpose server recurse for names equalling
a delegation point, just as they do for names below a delegation point. but
such recursion should not change the content of referrals, or else an authority
server will respond with a different below-zonecut referral after an equal-to-
zonecut referral, than it did before the equal-to-zonecut referral. that way
lies madness, from a conformance testing and interoperability testing and
operational debugging standpoint. also it would still be inconsistent, even
if no longer undefined.

therefore let me repeat my previous observation. a dual-purpose server would
have to maintain discrete NS RRset data for all zonecut nodes ("delegation
points") in order to satisfy the other protocol invariants we know about. we
all believe that this is overly burdensome. we can therefore recommend that
no server be configured for both authority and recursive service. although
i guess we can also define the proper behaviour so that those implementors
who don't find it burdensome can just operate in the "right" way.

let me show my colours for a moment. BIND4 taught me to hate dual-purpose
servers, and there is no nameserver within reach of my keyboard that is
configured that way, or is allowed to be configured that way. i find the
whole idea of dual-purpose servers disturbing and repellent. this knowledge
may help some of you to decide to ignore my tirade on the topic, but in the
spirit of full disclosure, now you know where i'm coming from.


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