> From: Tony Finch <[email protected]> > Sendmail at one time tried to use ANY for combined MX+A lookups, which > doesn't work.
That would be true and relevant if sendmail did that. Requesting ANY, not getting all of the MX, A, and/or AAAA records needed, and failing to continue making other DNS requests simply does not work. If sendmail did that, then given what BIND has done for eons, that bug would have been noticed immediately eons ago. Tony Finch pointed out privately that it wasn't until sendmail 8.12 that stopped asking for ANY records. I found 8.11.6 on http://rpm.pbone.net/index.php3/stat/26/dist/4/size/1399432/name/sendmail-8.11.6-1.62.3.src.rpm sendmail/domain.c in 8.11.6 started by requesting ANY. However it continued requesting AAAA, A, and/or MX and parsing ANSWER sections until it got the records needed. It did not stop with the ANY response unless the ANY response was dispositive (e.g contained all types or NXDOMAIN). My superficial code reading says it ignored ADDITIONAL sections and so ignored potentially interesting A or AAAA RRs in ADDITIONAL sections. My quick side-by-side comparison of the old 8.11.6 and current 8.14.7 domain.c says that the relevant difference is that 8.14.7 starts with A or AAAA and never tries ANY. However, that is about dns_getcanonname(). getmxrr() in both 8.11.6 and 8.14 starts and ends with MX and never messes with ANY. There is broken in that ANY scheme. It might or might not reduce average DNS traffic for sending mail. I'd vote against it today for various reasons, but that doesn't make it wrong. There is an interesting comment in the 8.11.6 version of domain.c: ** The ANY query is really meant to prime ** the cache so this isn't dangerous. If your SMTP client is very close to your recursive resolvers (typical 10 or 20 years ago), then making an ANY request that you ignore could reduce your external DNS traffic by priming (not refreshing) the resolver's cache. I don't know that getmxrr() in sendmail is not called before dns_getcanonname(), which would prevent cache the priming by an ANY request. About chasing CNAMEs safely or otherwise, please recall the somewhat controversial DontExpandCnames. The current cf/README says: confDONT_EXPAND_CNAMES DontExpandCnames [False] If set, $[ ... $] lookups that do DNS based lookups do not expand CNAME records. This currently violates the published standards, but the IETF seems to be moving toward legalizing this. For example, if "FTP.Foo.ORG" is a CNAME for "Cruft.Foo.ORG", then with this option set a lookup of "FTP" will return "FTP.Foo.ORG"; if clear it returns "Cruft.FOO.ORG". N.B. you may not see any effect until your downstream neighbors stop doing CNAME lookups as well. Vernon Schryver [email protected] _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/bind-users
