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_________
