[dns-operations] Survey of How to Solving DNS Errors

[Wessels, Duane]

> On Aug 20, 2024, at 6:08 PM, Dave Lawrence via dns-operations <dns-operations at dns-oarc.net> wrote:
> 
> 
> From: Dave Lawrence <tale at dd.org>
> Subject: Re: [dns-operations] Survey of How to Solving DNS Errors
> Date: August 20, 2024 at 6:08:10 PM PDT
> To: 苗发生 <mfs24 at mails.tsinghua.edu.cn>
> Cc: "dns-operations at lists.dns-oarc.net" <dns-operations at lists.dns-oarc.net>
> 
> 
> Peter Thomassen writes:
>> I still disagree with the characterization of NXDOMAIN as a
>> resolution error. That's like characterizing a red street light as a
>> driving error.
> 
> Just got back from PTO so apologies for the lag.  I wanted to heartily
> agree with this comment from Peter.  
> 
> While NXDomain might not be the result that either the client or the
> server really wanted (eg, it could well be an error that the
> authoritative server removed a name that should exist), it is a
> mistake to call this a resolution error.  The serve stale RFC, 8767,
> explicitly calls out that a resolver that gets NXDomain must consider
> that resolution to have been successful and not use stale data like it
> could in an error condition.


As does RFC 9520 (Negative Caching of DNS Resolution Failures) which says:

Note that NXDOMAIN and NOERROR/NODATA responses are not conditions
for resolution failure. In these cases, the server is providing a
useful response, indicating either that a name does not exist or that
no data of the requested type exists at the name.

DW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4209 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20240821/34fdc087/attachment.bin>