(copying John Levine given his recent summary on the IETF list as well as his co-author role)
--On Friday, July 18, 2014 10:36 -0400 Olafur Gudmundsson <o...@ogud.com> wrote: >> If this is a worry for the root server operators (but I >> thought they had said in the past that it doesn't pose a >> problem) then the draft could specify a canonical >> address-less domain lower down the hierarchy, e.g. >> empty.as112.arpa (making use of the AS112 DNAME proposal). >... > Many years ago Joe Abley and I suggested to create a special > name for exactly this purpose a name that was guaranteed to > never exist in the DNS thus the first lookup would always > return NXDOMAIN thus the A+AAAA lookups would never take > place. http://tools.ietf.org/html/draft-jabley-sink-arpa-03 One more general observation and then I'm going to stop and leave this part of the issue to you folks. I believe there is fairly general (if still a bit "rough") consensus in the email community that having some clear, DNS-based, way for a system to indicate that it does not accept email. Long ago, there was some hope that WKS records would solve that problem (and others like it), but we know how that worked out. Today's problem, IMO, is that, while there is little debate about "DNS-based solution", or even "DNS-based solution involving something special in the relevant MX record", I haven't seen a careful analysis by DBS experts on which of several DNS approaches have the least bad operational properties. If a particular SMTP implementation is aware of and follows the spec, almost any consensus indicator that doesn't conflict with other things should be fine -- ".", "*******", a special name in example.com or example.net, the proposal above, or something else, because there will be a string compare within the SMTP server and no lookups will be done. Since SMTP prohibits non-ASCII domain names, one might even consider something Like "фиктивный.example.com" or "虚假.example.com" (literally, not as IDNA A-labels) which would cause many SMTP servers to do something nasty that does not involve the DNS. DATA containing "." has the advantage of already being deployed, so anything else has to offer enough marginal value to overcome the assumptions that go with existing practice. But, modulo that issue, I don't think the SMTP community really cares what the string is as long as there is a string and a mechanism (Tony and others have said as much). The only issue that is, IMO, really important is with side-effects or damage caused by SMTP implementations that do not know about the convention or conform to the spec. They will certainly do lookups; how far they will get and whether they will requeue and try again depends somewhat on the string chosen and, modulo the observation about non-ASCII bogus strings, that is your area of expertise and not mine (or that of the AppsAWG). Given that the IETF used to pride itself on the application and quality of cross-area review, I think it is desirable and appropriate that the DNS community generally, and DNSOP in particular, weigh in on the string. I'd be happiest, and I'm confident that John L would be too, if the answer was any of * Just fine, "." is no problem * Ok, "." isn't likely to cause enough of an incremental problem to be worth worrying about. * We really wish you had asked ten years ago, but don't see "." as causing enough of an incremental problem to be worth the difficulties associated with getting existing implementations to change their ways. But, again in the spirit of cross-area review, I'd really like it --and, as someone who periodically plays email expert on television, be a lot more comfortable-- if DNSOP had enough of a discussion to advise on this. I would hope that, if the advice were "use a different string, preferable <whatever>, because..." the IESG and the advocates of "no mail received here" indicator MXs would pay careful attention. And I'd like to see the spec reflect the analysis, if only in an appendix, which may require someone on the DNSOP list to help John L with text. But that is, as always, secondary to getting the spec, protocol, and operational issues right. john _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
