On Aug 14, 2007, at 10:22 PM, Mark Andrews wrote:
On Wed, 2007-08-15 at 11:58 +1000, Mark Andrews wrote:
Since all valid email domains are required to have a working postmaster you can safely drop any email from such domains.
Use of root "." as a name for a target may create undesired non- cached traffic when applications unaware of this convention then attempt to resolve an address for servers named root.
All modern iterative resolvers are required to support negative caching.
Indeed, RFC 2308 changed negative caching support from optional for any caching resolver. Those that have negative caching may significantly truncate the duration. There are several websites recommending negative caching be disabled to permit faster recovery from intermittent negative answers. In other words, a negative answer is less likely to have been cached. Use of root target names will impact roots in cases where: - an assumption of negative caching is wrong, - for MX records where the root name convention is not in place. With email, transaction rates are high and highly distributed which tends to diminish negative caching protections.
The use of root as a convention will complicate a general strategy identifying adoption of a protocol by publication of a discovery record. The use of root as a target name in SRV records has been problematic, although this convention was defined for SRV records at the outset.
Using an MX record to mean "no email is accepted" by naming the target 'root' changes the meaning of the MX record.
Not really. It's entirely consistant with existing DNS usage where "." is a domain name / hostname place holder.
Lots of RR types use "." to indicate non-existance.
Yes, and this convention still generates nuisance root traffic whenever the application fails to comprehend "." is a special target. This is true even when _defined_ as a special target for the specific resource record, as with SRV. In the case of an MX record, there is _no_ such definition.
It is also not clear whether the root target would mean "no email is sent" as well.
That is, I'll agree, more of a issue but no one can reasonably expect people to accept non-repliable email.
That would have been made clear by simply requiring MX records for acceptance!
A clearer and safer strategy would be to insist that anyone who cares about their email delivery, publish a valid MX record. Especially when the domain is that of a government agency dealing with emergencies. At least FEMA now publishes an MX record. This requirement should have been imposed long ago. : )
I much prefer positive data vs the absence of data to make a decision. "MX 0 ." is a definitive response saying you don't want email.
Not having an SMTP server and no MX record provides a clear indication of a policy "I don't want email." Policy will often require a greater amount of information. To discovery policy must the entire domain be queried? A wildcard MX record and root name convention exposes a domain to an SPF script attack, where a different convention is expected for no email. In this case, one cached SPF record may utilize a sequence of originating email-address local-parts in a spam campaign to generate 10, 20 or perhaps 30 MX record transactions per message. Each MX transaction might be given a maximal label size as well. This attack would completely free for spammers and would not expose their 0wned systems, as the attack will emanate from the recipient's resolvers. Email logs may not offer clues in how the attack happened, as victim domains might have been obfuscated by a combination of local-part and SPF script. And yes, SPF is another method some recommended for expressing email policy. When can the recipient of a message know whether the originating domain expressed policy that goes beyond NO? Query all TXT RR? Examine policy at some policy location? The only place where policy should published is at a protocol discovery record. In the case for email, it would be at the MX record. Wildcards for policy will likely create other problems. The XPTR proposal by Phillip Hallam-Baker envisions such a wildcard scheme where a new pointer record is to be published at _every_ existing node. http://www.ietf.org/internet-drafts/draft-hallambaker-xptr-00.txt A simpler scheme would be to require a protocol discovery record and then expect any related policy be published adjacent to the discovery record. For email, the MX record would be a protocol specific discovery record. -Doug