I've been trying to understand why mixing authority data and cached
data is confusing or ill-defined. Perhaps there are two angles.

1) CNAME?DNAME that "crosses" from authority to cache or vice versa.
2) At a delegation point, when considering the algorithm in 1034/4.3.2.

(I.e., the RD bit is the tip of the iceberg.)

At 8:06 +0000 2/8/06, Paul Vixie wrote:
># --
># Anyway, if RD=0, I'd argue that the authority section of the response
># should contain a delegation and the answer section cached data if available.

This sounds like what the COM-zone servers appear to do today, if you
interpret "cached data" as "otherwise learned data."

># If RD=1, the answer section has the answer, with aa set if the answer came
># from a zone's authoritative data, 0 otherwise.
>I am pleasantly surprised by your RD=0 clarification, but the RD=1 baffles me.
>For the RD=0 case, no existing server of which I'm aware works this way, and
>noone I've spoken to about this who has read 1034 and 1035 interpreted it this
>way. However, I can see the consistency in it and I can live with the ruling.
>In the RD=1 case, you'd have a dual-purpose server respond with data that did
>not come about by recursion, and is in practical terms "less credible than"
>what would result from querying the child zone's authority servers for it.

I don't see a problem here. If I ask a server for data, I may assume
some context like "I'm asking the tld server and expect to get back a
referral to the next-level server." The server doesn't have the
context and would say "I'm being asked about this Q-tuple, let me
find the most specific answer I can." The disconnect we often make
(and this came up repeatedly when developing the DS record years
back) is that we forget the context assumed by the client is not the
same context assumed by the server.

Ergo - the client shouldn't be surprised to find data it would label
less credible/trustworthy from a server because it thought the server
wouldn't answer from cached data. The client should always expect
the most trustworthy data it can get.

>To help understand my bafflement, consider that regeneration is all the rage,
>and AA=1 never occurs after recursion in BIND9. In BIND4 and early BIND8, we
>passed through the initial AA=1 from the authority server but gave back AA=0
>on subsequent queries for the same data. For a BIND9 recursive server, AA=0
>on all responses. I regard the current BIND9 behaviour as "more correct."

I think that BIND9 is "more correct." But I don't see why
regeneration is baffling in this case. (Unless it has to do with
4.3.2.) If any part of the answer section comes from learned data
(passively or actively cached), then the AA is off. Otherwise it is
on. When I say "part" I am thinking of CNAME situations, in

If a wild card domain name is in the cache, that is not a source of
synthesis. One more thing to keep in mind.

># --
># I can imagine lots of reasons where I might want to have a server configured
># to be authoritative only or caching only, but I don't think the one can
># credibly argue that the behaviour is "undefined" for a mixed server.
>I hope you're right, but I'd like to understand more about your reasoning in
>the RD=1 case. I really think that if a requestor wants recursion, that the
>data they should be given should be the result of recursion. If any other
>RA=1 server were to respond with parent-zone-glue rather than child-zone-data
>in this case, we would call that server "defective".

I disagree with "if a requestor wants recursion, that the data they
should be given should be the result of recursion." Maybe this is
where some confusion lies.

I see that the RD bit is a direction from the client to the server on
how to handle the query. Ordinarily the RD=1 only from stub to
recursive cache, RD=0 for all full resolvers. Exceptions to this are
not a problem though, I would think. If an implementation of a full
resolver wanted to send RD=1 all the time to off-load it's work.

I don't think the server ought to determine what the resolver is
asking for based on the header bits. Yes, RD=0 says give me what you
have but don't go looking elsewhere. To me that's query management,
not data lookup management. That's my interpretation though, not
based on any portion of a spec.

>There's another, more extreme problem with dual-purpose servers, and that's
>security. Recursive nameservers which are open to the internet are, because
>of the widespread ridicule heaped upon RFC2827/BCP38 and SAC004, "dangerous".
>(I am aware of a multi-gigabit attack occuring against a neighbor, even as I
>type this, involving a few thousand open-to-recursion nameservers, 4K TXT RRs,
>a low-intensity spoofed source query stream from a botnet, and EDNS0.) Since
>it's operationally difficult to use different ACLs for recursion vs authority,
>most people just don't do it. So most dual-purpose nameservers are fully open
>and thus "dangerous". So if we do manage to nail down a practical
>interpretation of dual-purpose, I'll want the resulting clarification document
>to sing most expansively the damnation against open recursive servers, and if
>I am an author of such a document, it will advise "just don't do it" as the
>safest course of action.

I think that deserves another Subj:
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 namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.