Robert Edmonds wrote:
Paul Vixie wrote:
the implication of REFUSED is that if someone else asked this question, we
might be able to answer. so if BIND is doing what you say, it's wrong.
In theory, any authoritative nameserver could secretly also be a
resolver that will answer from cache if the right client sends it the
same question. Does that make it OK, then?
no, because it can, should, and probably will have different responses
and different reasons for those responses based on the query's RD value.
in this sense, we (i was at ISC when it happened) got
"allow-query-cache" almost precisely wrong. with what confusion, you can
now witness.
The REFUSED RCODE is documented as:
Refused - The name server refuses to perform the specified operation
for policy reasons. For example, a name server may not wish to
provide the information to the particular requester, or a name
server may not wish to perform a particular operation (e.g., zone
transfer) for particular data.
In this case the server's policy would be that it doesn't perform a
particular operation (i.e., QUERY) for particular data (i.e., data that
it's not authoritative for).
if the reason were due to something about the specified operation such
as the RD bit (like, it's 1 when it has to be 0) then i'd follow your
reasoning here.
Where does the implication that REFUSED is only appropriate if the
server might be able to answer if "someone else" asks the question come
from?
first, the example, "provide the information to the particular
requester". as in, some other requester might get a non-REFUSED answer.
second, the example, "zone transfer". when i added my very first BIND4
feature it was "allow-xfer" and i did indeed return REFUSED when asked
by someone who wasn't allowed. this also happens on TSIG failures today.
third, the differences and distinctions in initiator behaviour. there is
no difference in desired or expected initiator behaviour between "i am
out of disk space and can't write a secondary zone file, so while i am
configured to be a secondary server for this zone, i can't do it", vs.
"i am configured to be a primary server for this zone but there is no
zone file so i can't do it", vs. "i am not configured to be a server for
this zone and either RA=0 or RD=0 or both".
in all three cases, we want the initiator to cache our inability to
satisfy it so as not to melt the tubez with repeated (doomed) requests,
try other name servers (but not other addresses for this name server),
and retry here later (after, say, ten minutes) in case the situation
improves. the only hoped-for reason i can imagine for sending SERVFAIL
in the first two cases and REFUSED in the last case is to control the
logging on the initiator -- expecting the sysadmin to behave differently
when cleaning up the resulting mess.
using REFUSED vs. SERVFAIL in this case is a distinction without a
difference, and a costly one, because REFUSED actually has a different
intended reaction in the initiator than SERVFAIL. but i've covered that
in the archives (several times) and won't repeat it again here.
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
