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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
