On Mon, Nov 13, 2017 at 11:03:11PM -0800, Paul Vixie wrote: > while specific guidance was not given as to resolver action in response > to each possible authority RCODE, i have both witnessed and implemented > full resolvers which treated REFUSED as a permanent failure whereas > SERVFAIL was a temporary failure.
What do you mean by "permanent" in this context? As far as I know, BIND treats REFUSED as persistent during the resolution process -- i.e., it won't bother to retry the same server with the same query immediately. It would go to the next delegated name server, and if all servers refused, eventually it would return SERVFAIL to the client. It might add the address to a bad server cache; I'm not actually sure whether it does that in this scenario, I'd have to check. If it does, that would keep it from retrying the server for 30 minutes, which is a reasonable recovery time for the "haven't caught up with my inbox" class of error. > treating "i don't have the zone configured" as a REFUSED condition, > while treating "i can't write the secondary zone" or "i can't read the > primary zone" as SERVFAIL conditions, adds no value, but does subtract > it. I'm not seeing the value subtracted. In those two cases, your server knows that it's *supposed* to be authoritative for the zone in question, and that there's a problem preventing it from answering. This fits the definition of SERVFAIL, "unable to process this query due to a problem with the name server", and the other case doesn't. > usually when i don't have a zone configured that is delegated to me, > it's because i have not caught up with my inbox, or i have FUBAR'd my > configuration file using "git" or similar. in those cases, the name > being looked up _might exist_ and retrying later _might succeed_. Or, very likely, the parent zone is misconfigured or out of date, in which case the name doesn't exist and retrying later won't sucseed. Perhaps you run a secondary name service and your customer hasn't paid the bill, or they're in the process of switching to a new provider, or they just put in the wrong glue. Your server isn't failing; it's just being asked for a name it never heard of. > i have heard a number of folks argue that this logic is common, but i > have heard noone argue that it is superior to known alternatives. can we > hear someone who is in favour of this for reasons beyond "five million > frenchmen cannot be wrong"? I wish NOTAUTH had been defined in 1035. Since it wasn't, there are only three answers that make any sense: NOERROR with upward referral, SERVFAIL, REFUSED. We already disposed of upward referral. SERVFAIL gets you spurious retries. REFUSED makes the querant go away for a sensible amount of time; we have ten years of operational experience with it. I don't see the problem. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop