Re: the RD bit is troubling me today
At 3:33 +0000 2/8/06, Paul Vixie wrote:[color=blue]
># 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
>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.[/color]
I think what you said agrees with my interpretation. ;)
In my text I refer to "learned NS set" - which may be a null set,
which is what a nominal authority server would have. (I.e.,
authority only means not learning.) Looking at the COM-zone servers
you do see what I call hybrid responses (sorry, in my text, where I
said answer, I should have said response) that have the NS records in
the answer section. In this instance, "learned" is not from caching
but from being fed by the registry behind the servers.
No non-recursive server ought to do more than the priming queries for
the root zone. That's clear. To underscore this, when I say
"learned" I am assuming "passively learned" in this case - the result
of the server learning for another reason.
># 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
I understand. Nevertheless I think that if we open up the protocol
to say "RD=0" means that a server expose data that would otherwise be
obscured by what's learned passively relative to the query at hand
then we are reacting to a siren's call. (I.e., undesirable feature
creep in the protocol.)
># 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.[/color]
I don't like to say that "because X is undefined, don't do it." If X
solves a need, do it and clarify it. Don't let the specification
lead the code, don't let the code lead the service, don't let the
service lead the demand. As engineers, we have to remain ready to
answer the needs of the populace, not the other way around.
I say this in support of defining what needs defining in this case
and not because I saw you falling behind in a race with a parked car.
>our chairs will have to take the lead on determining which way we want to go.[/color]
The only thing I disagree with is that the chairs don't need to lead,
we need to have the WG talk about this. The chairs only need to
detect when we've gotten to tired to fight and they declare
Edward Lewis +1-571-434-5468
Nothin' more exciting than going to the printer to watch the toner drain...
to unsubscribe send a message to [email]email@example.com[/email] with
the word 'unsubscribe' in a single line as the message text body.