Re: DNS question, null MX records

[Douglas Otis <dotis () mail-abuse org>]

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