Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie <[e-mail]>]

Dave Lawrence wrote:
> Evan Hunt writes:
>> Okay. I haven't encountered a resolver that propgates REFUSED from the
>> authority to the stub.  If there is such a beast, then IMHO that, not the
>> authority, is the one that's mis-using REFUSED; REFUSED only makes sense on
>> a hop-by-hop basis.

i'll stop arguing about it.

> Very much agree.  I'd be surprised to see REFUSED from a resolver.

i think you'd be within your rights as a stub to treat REFUSED as your 
lack of permission to use that recursive, and not an end-to-end signal. 
this bolsters evan's observation of its ambiguity.

> Now on the other hand, using extended-error for signalling from a
> resolver that the known authorities all returned REFUSED, that's
> interesting and can be made unambiguous as a code apart from the
> currently proposed extended-error 4, "Prohibited".

for each code we have to be explicit about what we expect the initiator 
to do in response.

the reason i use SERVFAIL for NOTAUTH is because what i want the 
initiator to do when i'm configured as primary but can't read my zone 
file, or am configured as secondary but can't write my zone file, is the 
same as what i want when i'm not configured for the zone: cache this 
failure under a hold-down timer so as not to melt the tubez, but do try 
again later in case i'm merely late to change my config, or flubbed my 
config in some way.

i think the need for a hold-down timer on cached SERVFAIL may be 
catching a number of you by surprise. but really, what we want for 
NOTAUTH, we already have to have for SERVFAIL.

administrative denial is something else.

-- 
P Vixie