--- Begin Message ---
> On Aug 20, 2024, at 6:08 PM, Dave Lawrence via dns-operations
> <dns-operati...@dns-oarc.net> wrote:
>
>
> From: Dave Lawrence <t...@dd.org>
> Subject: Re: [dns-operations] Survey of How to Solving DNS Errors
> Date: August 20, 2024 at 6:08:10 PM PDT
> To: 苗发生 <mf...@mails.tsinghua.edu.cn>
> Cc: "dns-operations@lists.dns-oarc.net" <dns-operations@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
smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
