# ...
# What this means is that no matter what the setting of the RD is the server
# ought to answer with the learned NS set over the authoritative NS set when
# the learned set is more trustworthy. (Applying to the case where the QNAME
# is a zone cut, etc.)

i disagree with this interpretation in two ways.

first, an authority server doesn't send answers when asked for non-apex NS,
it sends a referral. that is, if you ask the COM-zone servers for VIX.COM NS,
you should get back a response with an empty answer section and a non-empty
authority section.

second, an authority server should not, in general, fetch any glue or
otherwise send any packets to anybody, and especially, it should never answer
differently unless its own authority zone data has been made different.

# It's tempting to make (a) DNS (server) be able to answer with the
# authoritative data when RD=0 and the learned data when RD=1, but I'd say
# this is a "siren's call."

i'm not tempted by any sirens here. i just want to know what the right thing
is, so that i can do it, and complain if/when others don't, and test for it in
conformance suites, and so on. none of that is possible while this case
remains undefined.

# I'm no longer against mixing caching and authoritative servers. I think
# that the reasons once used to justify separating the two have largely
# vanished. I think that there are now valid reasons to combine them into
# one (at times).

i think i've pointed out a case where a server's answer not defined by the
spec, where authority and recursion are done on the same IP/UDP listener
address. since undefined is not what we usually want in a spec, and isn't
what folks think this spec offers, i'm calling that a problem.

we can decide that it's not really undefined, or that it's always been
undefined and everybody knew it but me and i'm chasing parked cars again, or
that it's not defined but the operational cost is low so we'll just document
it as undefined, or we can say that it's undefined and should become defined,
or we can say that it's undefined and therefore not a recommended practice.

our chairs will have to take the lead on determining which way we want to go.

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