[dns-operations] CloudFlare policy on ANY records changing

[Yunhong Gu]

On Mon, Mar 9, 2015 at 10:58 PM, Mark Andrews <marka at isc.org> wrote:

>
>
>
> In message <
> CAGmQtQJrpx_XG_OJTShsW5YqAeFKZwdMa16XW7iry9PR0_FT+A at mail.gmail.com>
> , Yunhong Gu writes:
> >
> > Returning NOTIMP may confuse resolvers as it is not clear "what is not
> > implemented".
>
> Which is why you only change one thing at a time when trying to
> determine what is covered by NOTIMP.
>
> > A NOTIMP response to an ANY query with EDNS0 option could
> > cause a retry-without-EDNS0 query, or mislead the resolver to believe
> that
> > the nameserver does not support EDNS0.
>
> And if you retry w/o a OPT record you will still get NOTIMP, move
> onto the next nameserver and enventually return SERVFAIL.
>

Retry introduces latency, which matters a lot for resolvers. There are
situations a resolver may not want to enumerate all possibilities (e.g. the
client may already timeout before the resolver get the final response).


>
> Note there really is nothing special w.r.t. ANY here.  We have
> nameservers that return NOTIMP to TXT, MX, NS, SOA, DNSKEY etc.
> About the only query type that doesn't get NOTIMP is A.
>

ANY is indeed a little special compared to the examples you mentioned. If a
nameserver returns response for A, then it should return NODATA instead of
NOTIMP for TXT, MX, etc. Returning NODATA for ANY is a little confusing,
though it can be argued to be legitimate if only cached records are
returned.

So the problem is, why NOTIMP? REFUSED sounds like a better choice.


>
> Mark
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150310/069796fa/attachment.html>