In message <6eb799ab0912172126g1eac7e49ve8f803552f6db...@mail.gmail.com>, James Hess writes: > On Thu, Dec 17, 2009 at 6:54 AM, Tony Finch <d...@dotat.at> wrote: > > On Wed, 16 Dec 2009, Douglas Otis wrote: > more polite to use a nonexisten > t name that you control, but that doesn't allow the source MTA to skip furt > her DNS lookups > If you want to be kind, point the MX to an A record that resolves to > 127.0.0.1. > Common MX'es should immediately reject, and report a "configuration > error"/MX loop with the domain. > > Your intent will also be clear, to just about everyone, it will be > obvious the MX is intentionally broken. Other tricks may be more > obscure, will be less obvious that you don't want mail, and may look > like a mistake -- you might even get visitors to your domain > contacting you to report the broken MX record. > > An alternative to resolving MX to an invalid IP might be to cut to the > chase and just make further DNS lookups impossible altogether... > > @ 604800 IN MX MX.BOGUSMX > BOGUSNS 604800 IN A 0.0.0.0 > BOGUSMX 604800 IN NS BOGUSNS > > Or for that matter delegate the subdomain to 255.255.255.255. > The recursive resolvers already have to immediately reject DNS > delegation to broadcast addresses and the like. > > Though i'd be afraid of finding that some obscure resolver didn't...... > > [EG] "Gee thanks... some spammer exploited my open relay, and your > broadcast NS delegation, caused my LAN to get swamped by my mail > servers' DNS lookups while it was trying to send the 10 million > spams to you...." > > -- > -J
Just document "MX 0 ." and be done with it. MTA and MUA vendors will update their products. Most caching nameserver negatively cache the non-existance of address records so the traffic is mostly between the non-updated MTA and the recursive server. 2 queries (A and AAAA) every 3 hours won't kill the roots. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org