Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie <[e-mail]>]

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