[94755] in North American Network Operators' Group
Re: what the heck do i do now?
daemon@ATHENA.MIT.EDU (Jon Lewis)
Mon Feb 5 22:14:10 2007
Date: Mon, 5 Feb 2007 22:13:08 -0500 (EST)
From: Jon Lewis <jlewis@lewis.org>
To: Jeremy Chadwick <nanog@jdc.parodius.com>
Cc: Paul Vixie <vixie@vix.com>, nanog@merit.edu
In-Reply-To: <20070205230410.GA70538@icarus.home.lan>
Errors-To: owner-nanog@merit.edu
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_________
