This is a discussion on Re: the RD bit is troubling me today - DNS ; # -- # # 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. # # If RD=1, the answer section has the answer, with ...
# 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.
# 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.
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 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".
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.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.