[120343] in North American Network Operators' Group
Re: DNS question, null MX records
daemon@ATHENA.MIT.EDU (Douglas Otis)
Wed Dec 16 19:42:31 2009
Date: Wed, 16 Dec 2009 16:41:46 -0800
From: Douglas Otis <dotis@mail-abuse.org>
To: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <D27C6F71-D6C7-4F4B-9B26-96EC35A4FCCF@hopcount.ca>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 12/16/09 4:08 PM, Joe Abley wrote:
>
> On 2009-12-17, at 00:02, 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 will still cause DNS requests to be sent towards 192.0.2.0 and
> 192.0.2.9, and they may not be dropped at the first router depending
> on local conditions. There are implications of state in the local
> resolver.
>
> Choosing MX RDATA with a name that is known not to exist ideally
> will only exercise the local cache for the non-existent name, since
> it will perhaps not be the first such query and the non-existence
> will already be cached.
>
> SINK.ARPA doesn't exist today. The document I referred to only
> exists to enforce that non-existence in the future; operationally you
> could install MX records towards SINK.ARPA today and get the desired
> effect, regardless of the state of the document.
The ARPA technique, as does pointing to the root, relies upon negative
caching of non-existent A records. This allows spammers to quickly
determine the inability to resolve addresses for MX hostnames and
thereby bypass connection attempts. Offering a sequence in the TEST-NET
block was to thwart the alternative of directly using the A record,
which is likely to point to a server.
If MX TEST-NET became common, legitimate email handlers unable to
validate messages prior to acceptance might find their server
resource constrained when bouncing a large amount of spam as well.
-Doug
