On Mon, Mar 9, 2015 at 10:58 PM, Mark Andrews <[email protected]> wrote: > > > > In message < > cagmqtqjrpx_xg_ojtshsw5yqaefkzwdma16xw7iry9pr0_f...@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: [email protected] >
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
