Re: [DNSOP] [apps-discuss] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
Nico Williams n...@cryptonector.com wrote: I think what you're objecting to is the section 4.3 and related text that conflates does not accept e-mail with does not send e-mail. Section 4.3 describes what is already done by existing implementations of this spec. Exim in its default configuration validates the domain part of email addresses and will reject mail if the sending domain does not exist or if its MX records point to nonexistent hosts. Exim also recognizes null MX records and suppresses the target A and lookups and treats the domain as invalid. However the null MX logic is just an optimization: Exim's validation logic would get the same result if it tried to do the A and lookups and found that . does not have any addresses. Postfix does the same if you use the reject_unknown_sender_domain option. There are good reasons for rejecting mail from invalid domains, e.g. because you would not be able to send a delivery failure report. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Biscay: Variable 3 or 4. Slight or moderate. Thundery showers later. Good, occasionally poor later. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
Hi. I have a few questions that I don't want to clutter the IETF list about but about which I would hope DNS experts, especially DNS root operations experts, would step in if they have opinions. IESG copied only for the record. I want to stress that these are questions: I may know enough to ask them but can't even competently speculate on the answers. The new specification proposes what is, in essence, a convention. If an SMTP-Sender (to use the original and very precise terminology), while doing the required lookup for an MX RR, encounters IN MX 0 . it is expected to abort the message-sending process -- no further lookups, not connection attempts, no queuing. At least in the near term, some SMTP Server (MTA) implementations will conform to that rule (many already use it) and some won't. For the latter, they will presumably do what the SMTP specs say to do. In summary, that is to look up the address(es) associated with the root and try to open a mail connection to one of them. When that connection fails (presumably times out), the SMTP server may decide to try more (or all) of the other addresses. When all of those it chooses to try fail, it is then required to queue the message, retrying the process (potentially to all 13 root servers) at regular intervals for an extended period of time. It is impossible for me to estimate the actual likely volume of such connection attempts. I suggest that any such estimate would be no better than a wild guess. It is clear that the requirement for retries and the number of root servers (i.e., that there is more than one address record) provides a multiplier effect on the number of MTAs and misdirected messages that do not follow the convention. Given that the DNS configurations for some domains are using this convention now, it should be possible to measure present-day SMTP connection attempts to the root servers. I don't know if anyone has those data. Because such attempts could originate from multiple causes, it might also be hard to interpret if it existed... beyond my experience. So, three (obviously-related) questions: (1) I understand that there have been concerns from time to time about the load caused by spurious queries to the root servers. These would not be spurious DNS queries (I assume primarily UDP) but spurious TCP connections to a port that I assume no contemporary root server uses to accept mail. Is that potential change in load an issue that anyone should be concerned about? (2) Would you recommend that the root servers take any special action to mitigate the potential problem? Such action might involve a port 25 responder that immediately closes connections (at least reducing timeout waits), or a fake SMTP server that would allow a connection to be opened, then immediately send a 5yz response to the SMTP sender. If the SMTP specs are followed by the sender, the latter would prevent attempts on other root server address and the queuing behavior. Either obviously involves some additional resources. (3) Independent of the answer to the question above, does the possibility of DNS operational impact as the result of this convention merit comments in the I-D that are not now present and, if so, what should be said? Recommendation: if the participants in DNSOP consider either of the above questions (and they are only questions) to be significant, it may be worthwhile to ask the IESG to postpone a decision on this document until this WG has an opportunity to comment. The above is obviously independent of the concerns about terminology that I raised in my Last Call response. As some of you know, sloppy and ambiguous terminology in discussions of the DNS has become a pet peeve of mine. If no one else cares, or cases enough to put effort into the problem -- even to prevent new ambiguous usage from entering the vocabulary via IETF standards track documents -- then I will go back to whining into my beer and stop trying to waste other's time on the issues. best, john ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
In message 93f32648fd67ae6abac47...@jck-hp8200.jck.com, John C Klensin writes : Hi. I have a few questions that I don't want to clutter the IETF list about but about which I would hope DNS experts, especially DNS root operations experts, would step in if they have opinions. IESG copied only for the record. I want to stress that these are questions: I may know enough to ask them but can't even competently speculate on the answers. The new specification proposes what is, in essence, a convention. If an SMTP-Sender (to use the original and very precise terminology), while doing the required lookup for an MX RR, encounters IN MX 0 . it is expected to abort the message-sending process -- no further lookups, not connection attempts, no queuing. At least in the near term, some SMTP Server (MTA) implementations will conform to that rule (many already use it) and some won't. For the latter, they will presumably do what the SMTP specs say to do. In summary, that is to look up the address(es) associated with the root and try to open a mail No. Lookup the address _at_ _the_ _root_. This is _not_ the addresses of the root servers. connection to one of them. When that connection fails (presumably times out), the SMTP server may decide to try more (or all) of the other addresses. When all of those it chooses to try fail, it is then required to queue the message, retrying the process (potentially to all 13 root servers) at regular intervals for an extended period of time. What connection? There are no addresses records at . so the MTA returns a NDN. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
John C Klensin john-i...@jck.com wrote: IN MX 0 . At least in the near term, some SMTP Server (MTA) implementations will conform to that rule (many already use it) and some won't. For the latter, they will presumably do what the SMTP specs say to do. In summary, that is to look up the address(es) associated with the root and try to open a mail connection to one of them. There are no addresses associated with the root, so the mail server will immediately report a delivery error. RFC 5321 section 5.1 paragraph 2 final sentence. The SMTP server will not try to connect to the root name servers, as your message suggested. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Biscay: Variable 3 or 4, becoming northwesterly 5 or 6 for a time in east. Slight or moderate. Rain or thundery showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
Tony Finch wrote: John C Klensin john-i...@jck.com wrote: IN MX 0 . At least in the near term, some SMTP Server (MTA) implementations will conform to that rule (many already use it) and some won't. For the latter, they will presumably do what the SMTP specs say to do. In summary, that is to look up the address(es) associated with the root and try to open a mail connection to one of them. There are no addresses associated with the root, so the mail server will immediately report a delivery error. RFC 5321 section 5.1 paragraph 2 final sentence. The SMTP server will not try to connect to the root name servers, as your message suggested. true as stated. what's unstated here is that every SMTP sender who encounters such an MX without understanding its new meaning will do two or three lookups: . MX, [. ,] and . A. if they are behind an RDNS that doesn't do negative caching (and there are many, though none of them are open source; the open source RDNS servers do negative caching right) then these two or three queries will flow through to the authority servers for . which is to say the root name servers. the long tail on old interpretation is between one and three decades. (which is also why repurposing/redefining things like TCP/53 is unworkable, as discussed separately.) if IETF had rules, one of them should be, don't redefine things that are in an existing datapath -- make a new datapath. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
--On Friday, July 18, 2014 23:18 +1000 Mark Andrews ma...@isc.org wrote: At least in the near term, some SMTP Server (MTA) implementations will conform to that rule (many already use it) and some won't. For the latter, they will presumably do what the SMTP specs say to do. In summary, that is to look up the address(es) associated with the root and try to open a mail No. Lookup the address _at_ _the_ _root_. This is _not_ the addresses of the root servers. I tried to make clear that I'm ignorant of many of the details here, so, if there is no issue, I apologize for wasting people's time. If the answer to those questions is not an issue, that is the answer and the end of the discussion. However, because I'm paranoid, let me mention an issue in passing without any reason to believe that it is a problem in practice. For SMTP (and at least some other applications) there has always been a question about what to do with DNS queries in mixed IPv4 and IPv6 environments when the application wants to get both sets of addresses. I vaguely remember an idea about a query type of ADDEESS (or equivalent) that would return both A and RRs but, as far as I know, it didn't go anywhere. If there are best practices recommendations for applications writers in this area, I don't think they have been widely disseminated in the applications development community. The poor bewildered application author then has two choices, both of which appear to be rational. One is to issue two queries, one for A RRs and one for , and then sort things out in the application. The other is to issue an ANY query and sort the relevant information out from it. I at least superficially understand the problems with the latter and you obviously understand them much better. But, should an application writer make that choice (and, again, clear advice has not been broadly disseminated), a query for the root does get back address records. It is probably sensible to conclude that the number of implementations that are that stupid doesn't make the issue worth worrying about but that should be your conclusion, not mine, because I am obviously out of my depth here. john ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
--On Friday, July 18, 2014 06:46 -0700 Paul Vixie p...@redbarn.org wrote: ... There are no addresses associated with the root, so the mail server will immediately report a delivery error. RFC 5321 section 5.1 paragraph 2 final sentence. The SMTP server will not try to connect to the root name servers, as your message suggested. true as stated. what's unstated here is that every SMTP sender who encounters such an MX without understanding its new meaning will do two or three lookups: . MX, [. ,] and . A. if they are behind an RDNS that doesn't do negative caching (and there are many, though none of them are open source; the open source RDNS servers do negative caching right) then these two or three queries will flow through to the authority servers for . which is to say the root name servers. Paul, Thanks. I obviously got the question wrong but, if it accidentally called attention to an issue that deserves even minimal consideration, I don't mind looking and feeling stupid. I obviously knew about the multiple queries but, by thinking about this from an SMTP context, was more concerned about the connection and queuing part of the problem. FWIW, many SMTP servers will deal with a negative answer from a DNS query by queuing the message (for the historical reason that a DNS change might not yet have caught up with the server queried). While the port 25 issue that I incorrectly focused on will not arise, the two or three queries you mention might, depending on the behavior of the resolver on which that SMTP server calls, be repeated at each queue retry interval. Again, I'm not competent to evaluate whether that is an issue or not. thanks again, john p.s. Just one or two lookups against the root. The sequence would be an MX lookup for the putative mail delivery domain (which should not affect the root servers), then . A and, optionally, . , in either order. While some implementations have historically done it, SMTP (at least as of RFC 5321) forbids doing an MX lookup on the information obtained from the DATA of a prior MX query. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
Paul Vixie p...@redbarn.org wrote: what's unstated here is that every SMTP sender who encounters such an MX without understanding its new meaning will do two or three lookups: . MX, No, MTAs do not look up MX records for MX targets. [. ,] and . A. But they might do these lookups, yes. 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). Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Plymouth: South 4 or 5, becoming variable 3 or 4. Slight or moderate. Rain or thundery showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
On Jul 18, 2014, at 10:18 AM, Tony Finch d...@dotat.at wrote: Paul Vixie p...@redbarn.org wrote: what's unstated here is that every SMTP sender who encounters such an MX without understanding its new meaning will do two or three lookups: . MX, No, MTAs do not look up MX records for MX targets. [. ,] and . A. But they might do these lookups, yes. 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). Tony. - 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+ lookups would never take place. http://tools.ietf.org/html/draft-jabley-sink-arpa-03 Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
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+ lookups would never take place. http://tools.ietf.org/html/draft-jabley-sink-arpa-03 While I don't think it's relevant for this application, isn't that what RFC 6761 defines invalid to be? R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [apps-discuss] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
Nico Williams n...@cryptonector.com wrote: I think what you're objecting to is the section 4.3 and related text that conflates does not accept e-mail with does not send e-mail. Section 4.3 describes what is already done by existing implementations of this spec. Exim in its default configuration validates the domain part of email addresses and will reject mail if the sending domain does not exist or if its MX records point to nonexistent hosts. Exim also recognizes null MX records and suppresses the target A and lookups and treats the domain as invalid. However the null MX logic is just an optimization: Exim's validation logic would get the same result if it tried to do the A and lookups and found that . does not have any addresses. Postfix does the same if you use the reject_unknown_sender_domain option. FWIW, the equivalent option in the Oracle MTA is called mailfromdnsverify. There are good reasons for rejecting mail from invalid domains, e.g. because you would not be able to send a delivery failure report. Yep. I believe setting this option is fairly common. Ned ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
On Jul 18, 2014, at 10:52 AM, John Levine jo...@taugh.com wrote: 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+ lookups would never take place. http://tools.ietf.org/html/draft-jabley-sink-arpa-03 While I don't think it's relevant for this application, isn't that what RFC 6761 defines invalid to be? R's, John John, I think it would be great to have this document use “no-mail.invalid.” as the domain name rather than “.” in the MX record i.e. foo.bar.example MX 0 no-mail.invalid. But this is just a question of preference and installed base. Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
Olafur Gudmundsson o...@ogud.com wrote: I think it would be great to have this document use “no-mail.invalid.” as the domain name rather than “.” in the MX record I don't think this would help. It would be different from what existing code recognizes and it would not divert the unwanted A+ queries away from the root name servers. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: West or southwest 4 or 5. Slight or moderate. Thundery showers in north. Good, occasionally poor in north.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
I think it would be great to have this document use ?no-mail.invalid.? as the domain name rather than ?.? in the MX record i.e. foo.bar.example MX 0 no-mail.invalid. But this is just a question of preference and installed base. The aspirations of this document were far more modest than people seem to think. The original intent was to merely document a relatively standard operating procedure that mail admins routinely deploying. Up to that point it was trade-craft that sometimes surprised and confused new mail admins. We wanted to reduce that surprise and confusion. Nothing more. There was no original intent to try and change the practice nor to pass judgment on it. It was deemed that that would be covered by some future activity if warranted. Maybe NULLMX considered harmful if enough IETF wonks were keen on an admonition or driving an alternative. It's been nearly ten years since the original draft was posted, and it has travelled just about the full length of the IETF digestive tract. I can readily understand why the original goal may no longer be apparent. Importantly, in the intervening decade there has been zero evidence of sufficient energy to pursue alternatives, yet alone pursue them to completion. And of course the practice has become far more entrenched since then. I encourage folk to consider the doc in that context if they can. Mark. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
(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+ 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
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
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 DNS experts on which of several DNS approaches have the least bad operational properties. But, John, this is the one that's implemented in many popular MTAs, has been in daily use for the better part of a decade, and has no observed issues at all that I ever heard of. No doubt it sends some traffic to the root servers, but have any root server surveys ever even mentioned A or query traffic to . ? I can sorta kinda see not wanting to bless it in an RFC, but if we tell people to do something different, we'll just look ever more out of touch and they'll ignore us. Again. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
John C Klensin john-i...@jck.com wrote: 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 -- There are actually more constraints than you imply in your message. . Has the advantage of being implemented and deployed. Has the disadvantage of directing useless queries to the root name servers from MTAs that do not understand null MX records. *** MX target names should obey the LDH host name rules. You won't be able to enter this target into many DNS admin tools since they enforce LDH syntax. Some nameservers (e.g. BIND) will by default refuse to load a zone with a non-hostname MX target. This loses the advantages of a . target and fails to keep useless queries away from the root name servers. a special name in example.com or example.net, These domains are reserved for use in examples, not for production purposes. Are their name servers scaled up enough to handle stray queries from MTAs that don't understand null MX records? This question applies to any non-. target. The reason I suggested using AS112 was because it is designed for sinking unwanted queries that should not have leaked out in the first place. But I still prefer to stick with .. 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. You are muddling up the IDNA layers here. The MX target comes from the DNS so if you try to put an IDNA name there it has to be encoded as an A-label before you put it in the DNS. If you try hard you can put un-encoded UTF-8 in the DNS, but then it would violate the hostname rules in a similar way to ***. It is likely that there are MTAs which do not check that MX targets actually obey hostname syntax, so this kind of hack is not going to reliably suppress lookups. They will certainly do lookups; how far they will get and whether they will requeue and try again depends somewhat on the string chosen I think it depends more on the MTA's and/or postmaster's attitude to DNS misconfiguration. Some are quicker to permfail than others. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Irish Sea: South or southeast 4 or 5, becoming variable 3 or 4. Moderate becoming slight. Rain or thundery showers, fog patches. Moderate or good, occasionally very poor.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
--On Friday, July 18, 2014 14:59 -0400 John R Levine jo...@taugh.com wrote: 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 DNS experts on which of several DNS approaches have the least bad operational properties. But, John, this is the one that's implemented in many popular MTAs, has been in daily use for the better part of a decade, and has no observed issues at all that I ever heard of. No doubt it sends some traffic to the root servers, but have any root server surveys ever even mentioned A or query traffic to . ? If you head read all of my note, you would have noticed that I expressed a strong preference for staying with MX . unless there were compelling reasons for doing something else. Compelling is a pretty high bar, but I think we need to ask and then listen. Also see below. As to no observed issues and indications of support in the many popular MTAs you have cited elsewhere, I think counting SMTP implementations is essentially bogus for reasons discussed (and claims made) in another thread on the IETF list. For those with the patience for the analysis, see [1] below. More relevant, I think, is that the deployment scale for this convention has nothing to do with how many SMTP servers implement it -- whether they do by string matching (also see below) or by giving a just stop here interpretation to certain types of DNS responses to lookup of MS DATA field contents. If no one created an MX . entry, then the number or types of servers who were prepared to deal with one in a special way would be completely irrelevant and the number of queries to the root would be zero. Now we both know that there are a bunch of MX . records out there. I assume the number is not very large compared to the total number of nodes in the DNS that own address records or even that number less the number of nodes who have MX records that point to SMTP servers. But the load on the root as the result of this convention (whether approved by the IETF or not) is, unless my brain is completely not working today, dependent on how often such records are encountered less the number of systems that trap the . convention locally. If the reason for asking for IETF approval is to encourage more nodes to be associated with these records (otherwise, you presumably wouldn't be looking for standards track) then more MX . entries are likely to result in more DNS queries -- how many more is, I believe, anyone's guess although I discuss some parameters below. Part of the issue here is an SMTP subtlety (or perhaps an RFC 5321 glitch). Your spec says (Section 3) The DNS root is not a valid host name, so a NULL MX record can not be confused with an ordinary MX record. That is clearly true. But, while an SMTP implementation could invoke the operational necessity provision of 5321 and make a string comparison check rather than sending a query to the root, SMTP does not require that the DATA associated with an MX record pass SMTP tests of valid host name (in SMTP a rather restrictive bit of local syntax); it basically requires that whatever is out there be looked up, with validity (getting back an address record) depending on what the DNS has to say (see 5321 Section 5.1) So, again with the stipulation that I may still not fully understand the issues here, I'd look, not at numbers of SMTP server implementations, or even the amount of traffic they might carry, but the number of MX RRs with . in the DATA. I'd assume that number would grow significantly and asymptotically after this specification is approved and more operators install the records and then with the growth in the Internet (or the DNS). The actual number of queries would depend on the subset of those nodes that were hit, either intentionally or by mistake. I don't think we have any way to estimate that. In any event, if one believes in Internet growth and that don't send me mail MX records are a good idea, there will be a lot more of them in the future, maybe enough to justify a change now if one is otherwise appropriate (or maybe not). My apologies for not thinking of it sooner but, if I were worried about DNS root server impacts (email messaging with mistakes about domains may be such a small percentage of traffic to not count) or even unnecessary DNS traffic minimization more generally, I'd recommend that this new specification explicitly update Section 5.1 of RFC 5321 to require that DNS servers make a string-comparison test against . (or whatever the string turns out to be) and stop if it is found rather than doing DNS lookups on whatever is in the data field. As an alternative, 5321 could be updated to require checking the contents of MX DATA against the SMTP mailbox domain rules. Neither would affect anything that exists today that is reasonable, but they would move that check from
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
--On Friday, July 18, 2014 20:39 +0100 Tony Finch d...@dotat.at wrote: John C Klensin john-i...@jck.com wrote: 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 -- There are actually more constraints than you imply in your message. Yes, almost certainly. . Has the advantage of being implemented and deployed. Has the disadvantage of directing useless queries to the root name servers from MTAs that do not understand null MX records. *** MX target names should obey the LDH host name rules. I completely agree, but SMTP imposes no such requirement. You won't be able to enter this target into many DNS admin tools since they enforce LDH syntax. Some nameservers (e.g. BIND) will by default refuse to load a zone with a non-hostname MX target. Does that imply that this spec should contain a warning that loading one of these null MX records may require a configuration change in one's nameserver? Just asking. This loses the advantages of a . target and fails to keep useless queries away from the root name servers. a special name in example.com or example.net, These domains are reserved for use in examples, not for production purposes. Are their name servers scaled up enough to handle stray queries from MTAs that don't understand null MX records? Yep. Sorry for not selecting a better example, but I hope the point was clear. This question applies to any non-. target. The reason I suggested using AS112 was because it is designed for sinking unwanted queries that should not have leaked out in the first place. But I still prefer to stick with .. Ok, thanks for clarifying. 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. You are muddling up the IDNA layers here. The MX target comes from the DNS so if you try to put an IDNA name there it has to be encoded as an A-label before you put it in the DNS. If you try hard you can put un-encoded UTF-8 in the DNS, but then it would violate the hostname rules in a similar way to ***. I'm actually not... and sorry if I wasn't clear. Because SMTP doesn't impose any restrictions on what it can pick up from MX DATA (presumably the only limits are those imposed by 2181) and knows nothing about IDNA, un-encoded UTF-8 (or, for that matter, un-encoded UTF16 or something else as long as it is within the 64 byte label limit, is just meaningless trash -- far further up the trash scale than **. If an implementation chooses to apply host name checks (or SMTP mailbox domain name validity checks) that seems wise to me, but goes beyond what SMTP requires. It is likely that there are MTAs which do not check that MX targets actually obey hostname syntax, so this kind of hack is not going to reliably suppress lookups. Exactly. They are different examples of guaranteed bogus strings; they don't help a bit with the query problem. If we really want help with the query problem, we need to update SMTP (see previous over-long note to DNSOP, which I'll forward to you under separate cover. They will certainly do lookups; how far they will get and whether they will requeue and try again depends somewhat on the string chosen I think it depends more on the MTA's and/or postmaster's attitude to DNS misconfiguration. Some are quicker to permfail than others. Yep, And that is independent of whether we agree about what constitutes DNS misconfiguration. Had you said misconfiguration, abuse, or stupidity, we'd probably agree. :-) john ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
John C Klensin john-i...@jck.com wrote: MX target names should obey the LDH host name rules. I completely agree, but SMTP imposes no such requirement. RFC 974 specifies that the target of an MX record is a host name. You won't be able to enter [***] into many DNS admin tools since they enforce LDH syntax. Some nameservers (e.g. BIND) will by default refuse to load a zone with a non-hostname MX target. Does that imply that this spec should contain a warning that loading one of these null MX records may require a configuration change in one's nameserver? No, because . doesn't violate LDH syntax. (What admin GUIs do is another matter...) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Humber, Thames: Mainly southeast 4 or 5, increasing 6 at times. Slight or moderate. Thundery showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
John C Klensin john-i...@jck.com wrote: To the contrary, I think the problem here (if there is one) is that these types of ideas are being invented, specified through formal or informal private discussions, deployed, and then brought to the IETF for standardization. The null MX record is simply re-using the existing logic for null SRV records, so the design already has IETF approval. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ East Sole, Lundy, Fastnet: Southerly becoming variable 3 or 4. Slight or moderate. Thundery showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
(Warning to DNSOP and IESG -- this response is going to descend quickly into SMTP esoterica and is probably safe to ignore from a DNS perspective) --On Friday, July 18, 2014 22:39 +0100 Tony Finch d...@dotat.at wrote: John C Klensin john-i...@jck.com wrote: MX target names should obey the LDH host name rules. I completely agree, but SMTP imposes no such requirement. RFC 974 specifies that the target of an MX record is a host name. And so? RFC 2821 obsoleted 974. As far as I can tell, it says nothing at all about the DATA field in an MX record, leaving pulling that information out and looking it up in the DNS to be inferred from context and a parenthetical comment (perhaps taken from the preferred MX record). It does use the term host addresses and destination host, but in a too-informal context to assume that people would infer host name (aside: whatever that means) in the DNS sense. After 14+ years, I no longer remember and cannot reconstruct whether that was a DRUMS screwup or mine although the WG is ultimately responsible for not reviewing carefully enough. When RFC 5321 was done, we obviously knew there was a problem with the 2821 text because its text improves on the situation. The pre-5321 change log doesn't say much that sheds light on the change, other than saying that the description of MX handing was changed in -10 (one of several post-Last-Call versions). The relevant section is more clear and it does explicitly say the data field of that response MUST contain a domain name. That domain name, when queried, MUST return at least one address record (e.g., A or RR). But that is it: domain name. One can read that as an invocation of the discussion in Section 2.3.5 but that isn't the only possible reading. The section invokes 1035 and a sequence of letters, digits, and hyphens drawn from the ASCII character set. The following sentence reads Domain names are used as names of hosts and of other entities in the domain name hierarchy. so, while 2.3.5 (if one believes that the text in 5.1 invokes it) requires LDH, it does not require a host name.If one doesn't believe that 2.3,5 is invoked, then a domain name is presumably just an FQDN conforming to 1034/1035 as interpreted by 2181). There is, fwiw, some additional test in 2.3.5 that further muddies the waters. That is definitely not a good example of clarity or precision. Mea culpa, with or without comments about quality of review. I have tightened things up in the 5321bis editing copy (yes, there is such a thing). ... Does that imply that this spec should contain a warning that loading one of these null MX records may require a configuration change in one's nameserver? No, because . doesn't violate LDH syntax. (What admin GUIs do is another matter...) Those admin GUIs or text input converters were what I was concerned about (should have said nameserver configuration interface or words to that effect). Your call (and John L.'s). john ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
In message alpine.lsu.2.00.1407182019070.28...@hermes-1.csi.cam.ac.uk, Tony F inch writes: John C Klensin john-i...@jck.com wrote: 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 -- There are actually more constraints than you imply in your message. . Has the advantage of being implemented and deployed. Has the disadvantage of directing useless queries to the root name servers from MTAs that do not understand null MX records. *** MX target names should obey the LDH host name rules. You won't be able to enter this target into many DNS admin tools since they enforce LDH syntax. Some nameservers (e.g. BIND) will by default refuse to load a zone with a non-hostname MX target. This loses the advantages of a . target and fails to keep useless queries away from the root name servers. . is a place holder exception. Below is a minimal zone with a MX with all the domains set to .. Named will load MX 0 . fine. . prevents lots of the internal checks at load time from triggering. % named-checkzone zone zone zone:1: no TTL specified; using SOA MINTTL instead zone zone/IN: loaded serial 0 OK % cat zone @ SOA . . 0 0 0 0 0 @ NS . @ MX 0 . % MX 0 . is also consistent with SRV 0 0 0 . which is documented. no-mail.invalid however will elicit a warning / failure depending upon what the error level is set to. Named-checkzone looks up every MX target and check for A or records with the exception of .. It also checks that they are syntactically valid hostnames. It also tries to determine if a IPv4 address has been used instead of a hostname by mistake. % named-checkzone zone zone zone:1: no TTL specified; using SOA MINTTL instead zone zone/IN: zone/MX 'no-mail.invalid' (out of zone) has no addresses records (A or ) zone zone/IN: loaded serial 0 OK % cat zone @ SOA . . 0 0 0 0 0 @ NS . @ MX 0 no-mail.invalid. % . is a really good exception marker. It is also the minimal exception marker we can have. a special name in example.com or example.net, These domains are reserved for use in examples, not for production purposes. Are their name servers scaled up enough to handle stray queries from MTAs that don't understand null MX records? This question applies to any non-. target. The reason I suggested using AS112 was because it is designed for sinking unwanted queries that should not have leaked out in the first place. But I still prefer to stick with .. Since SMTP prohibits non-ASCII domain names, one might even consider something Like =D1=84=D0=B8=D0=BA=D1=82=D0=B8=D0=B2=D0=BD=D1=8B=D0=B9.ex= ample.com or =E8=99=9A=E5=81=87.example.com (literally, not as IDNA A-labels) which would cause many SMTP servers to do something nasty that does not involve the DNS. You are muddling up the IDNA layers here. The MX target comes from the DNS so if you try to put an IDNA name there it has to be encoded as an A-label before you put it in the DNS. If you try hard you can put un-encoded UTF-8 in the DNS, but then it would violate the hostname rules in a similar way to ***. It is likely that there are MTAs which do not check that MX targets actually obey hostname syntax, so this kind of hack is not going to reliably suppress lookups. They will certainly do lookups; how far they will get and whether they will requeue and try again depends somewhat on the string chosen I think it depends more on the MTA's and/or postmaster's attitude to DNS misconfiguration. Some are quicker to permfail than others. Tony. --=20 f.anthony.n.finch d...@dotat.at http://dotat.at/ Irish Sea: South or southeast 4 or 5, becoming variable 3 or 4. Moderate becoming slight. Rain or thundery showers, fog patches. Moderate or good, occasionally very poor. --1870869256-999632820-1405712346=:28941 Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop --1870869256-999632820-1405712346=:28941-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
The target us a hostname (RFC 1035). 3.3.9. MX RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PREFERENCE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / EXCHANGE/ / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: PREFERENCE A 16 bit integer which specifies the preference given to this RR among others at the same owner. Lower values are preferred. EXCHANGEA domain-name which specifies a host willing to act as a mail exchange for the owner name. In message d6cbb305b5bc2818e7b34...@jck-hp8200.jck.com, John C Klensin writes : (Warning to DNSOP and IESG -- this response is going to descend quickly into SMTP esoterica and is probably safe to ignore from a DNS perspective) --On Friday, July 18, 2014 22:39 +0100 Tony Finch d...@dotat.at wrote: John C Klensin john-i...@jck.com wrote: MX target names should obey the LDH host name rules. I completely agree, but SMTP imposes no such requirement. RFC 974 specifies that the target of an MX record is a host name. And so? RFC 2821 obsoleted 974. As far as I can tell, it says nothing at all about the DATA field in an MX record, leaving pulling that information out and looking it up in the DNS to be inferred from context and a parenthetical comment (perhaps taken from the preferred MX record). It does use the term host addresses and destination host, but in a too-informal context to assume that people would infer host name (aside: whatever that means) in the DNS sense. After 14+ years, I no longer remember and cannot reconstruct whether that was a DRUMS screwup or mine although the WG is ultimately responsible for not reviewing carefully enough. When RFC 5321 was done, we obviously knew there was a problem with the 2821 text because its text improves on the situation. The pre-5321 change log doesn't say much that sheds light on the change, other than saying that the description of MX handing was changed in -10 (one of several post-Last-Call versions). The relevant section is more clear and it does explicitly say the data field of that response MUST contain a domain name. That domain name, when queried, MUST return at least one address record (e.g., A or RR). But that is it: domain name. One can read that as an invocation of the discussion in Section 2.3.5 but that isn't the only possible reading. The section invokes 1035 and a sequence of letters, digits, and hyphens drawn from the ASCII character set. The following sentence reads Domain names are used as names of hosts and of other entities in the domain name hierarchy. so, while 2.3.5 (if one believes that the text in 5.1 invokes it) requires LDH, it does not require a host name.If one doesn't believe that 2.3,5 is invoked, then a domain name is presumably just an FQDN conforming to 1034/1035 as interpreted by 2181). There is, fwiw, some additional test in 2.3.5 that further muddies the waters. That is definitely not a good example of clarity or precision. Mea culpa, with or without comments about quality of review. I have tightened things up in the 5321bis editing copy (yes, there is such a thing). ... Does that imply that this spec should contain a warning that loading one of these null MX records may require a configuration change in one's nameserver? No, because . doesn't violate LDH syntax. (What admin GUIs do is another matter...) Those admin GUIs or text input converters were what I was concerned about (should have said nameserver configuration interface or words to that effect). Your call (and John L.'s). john ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
