> bert hubert <mailto:bert.hub...@netherlabs.nl> > Monday, March 16, 2015 11:23 PM > On Mon, Mar 09, 2015 at 04:18:12PM +0100, bert hubert wrote: >> On Mon, Mar 09, 2015 at 11:08:03AM -0000, D. J. Bernstein wrote: >>> My "qmail" software is very widely deployed (on roughly 1 million SMTP >>> server IP addresses) and, by default, relies upon ANY queries in a way >>> that is guaranteed to work by the mandatory DNS standards. > (...) >> Do you think I read 4.3.2 wrong? Or is there another RFC that updates the >> algorithm? > > Thanks to some clarification from Dan, I now understand that one can indeed > rely on ANY queries to resolvers to either deliver a CNAME or no CNAME, in > which case there is no CNAME.
i'd like to see those clarifications. if any non-CNAME RRset had existed and been cached, and then replaced by a CNAME, then ANY would not see the CNAME until the last non-CNAME RRset had expired from that cache. which is why, when i want to know if there is a CNAME, i ask if there's a CNAME. i realize that this only matters when the non-CNAME TTL's are one to two weeks long, and weren't trimmed before replacement with the CNAME. however, that situation is common enough that i dispute the phrase quoted above, "guaranteed to work by mandatory DNS standards." > > Separately, I fail to see why we actually need to outlaw ANY queries when we > can happily TC=1 them. TC=1'ing them would be a way to prevent them from being used as an amplifying reflector. that is not the use case for this. the updated document makes clear that the iteration complexity in split-authority systems having a lightweight front end, is the situation where ANY is painful. there never was an ANY-related problem for which TC=1 was the solution. -- Paul Vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
