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