Re: [DNSOP] Clarifying referrals (#35)

[Evan Hunt <[e-mail]>]

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-mail]
Internet Systems Consortium, Inc.