On 12/17/09 4:54 AM, Tony Finch wrote:
On Wed, 16 Dec 2009, Douglas Otis wrote:
To avoid server access and hitting roots:
host-1.example.com. IN A 192.0.2.0 host-10.example.com. IN A 192.0.2.9
example.com. IN MX 0 host-1.example.com. example.com. IN MX 90 host-10.example.com.
This is not very good from the point of view of a legitimate but mistaken sender, because their messages will be queued and retried. The advantage of pointing MX records at nonexistent hosts is most MTAs (and all common ones) will stop trying to deliver the message immediately. It is perhaps more polite to use a nonexistent name that you control, but that doesn't allow the source MTA to skip further DNS lookups, unlike the nullmx or sink.arpa ideas.
"." or "*.ARPA." are domains that won't resolve A records. Omit the A record in the above example accomplishes the same thing. DNS traffic can be reduced with long TTLs by using the TEST-NET technique. Pointing MX records toward root or ARPA domains exposes shared infrastructure to nuisance traffic from perhaps millions of sources expecting NSEC responses at negative caching rates. Traffic that should be handled by the name server declaring the service hostname. Better operators handling large email volumes reduce bounces and use retry back-off. Those who don't will find themselves disproportionally affected by a TEST-NET scheme. This seems to be a good thing, since there are far too many operators who carelessly accept email and expect others to deal with spoofed DSNs. Often the problem is due to serves being behind a border server lacking a valid recipient list that filters spam. The subsequent server with the valid recipient lists then aggressively attempts to deliver a growing number of DSNs having spoofed addresses holding spam that gets past filters. Why be friendly toward this type of behavior, especially at the expense of shared infrastructure? -Doug