On Mon, 5 Feb 2007, Jeremy Chadwick wrote:
u1.vix.com. 604800 IN A 192.0.2.1 u2.vix.com. 604800 IN A 192.0.2.2 u3.vix.com. 604800 IN A 192.0.2.3 ... [as many as you like]
i hadn't thought of that. i'll think seriously about it, thanks.
The caveats to this are:
1) DNS servers which are not configured to blackhole IANA-reserved network blocks (read: the majority) will blindly try to reach 192.0.0.0/17 and friends.
Huh? 192.0.2.0/24 - This block is assigned as "TEST-NET" for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation. Addresses within this block should not appear on the public Internet. That /24 doesn't show up in BGP unless something is broken or you have a cymru bogon feed. Either way, worst case is you're default routing to an ISP/NSP and the packets get a few hops before someone drops them as unroutable.
2) Some people (like myself) have ipfw/pf rules which block and log outbound packets to reserved blocks. We log these because usually it's the sign of broken software or possibly some weird IP routing (read: OS IP stack) problem. In the case of ipfw (I haven't tested pf), the block gets reported to underlying layers as EACCES, which can be incredibly confusing for admins.
If it means they get noticed, mission accomplished. That's exactly what Paul wants.
My vote is to simply remove the NS and A records for maps.vix.com and let people utilise search engines and mailing list archives to figure out where to go (mail-abuse).
The vix.com NS's will get slammed with all the DNSBL queries then. The suggestions I made at least get some of the queriers (assuming they have properly functioning caches) off your back for a while. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________