[dns-operations] CloudFlare policy on ANY records changing
guu at google.com
Tue Mar 10 13:25:23 UTC 2015
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
> > 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
So the problem is, why NOTIMP? REFUSED sounds like a better choice.
> 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...
More information about the dns-operations