|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: what the heck do i do now?
On Mon, Feb 05, 2007 at 10:13:08PM -0500, Jon Lewis wrote:
> On Mon, 5 Feb 2007, Jeremy Chadwick wrote:
> >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.
>
> 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.
I was going purely off of what ARIN reports:
Internet Assigned Numbers Authority RESERVED-192 (NET-192-0-0-0-1)
192.0.0.0 - 192.0.127.255
Internet Assigned Numbers Authority IANA (NET-192-0-2-0-1)
192.0.2.0 - 192.0.2.255
If there is something magical about 192.0.2.0/24, then I'd love to
know what it is (please do educate me!). But from my perspective, it
just looks like another IANA-reserved netblock.
> 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.
Right, so the mentality here is that "someone" will eventually
filter the packets or they'll be dropped due to a null route
BGP rule. This I understand, but IMHO it's better to filter such
packets before they ever reach someone else's networking gear.
(Sorry if I'm not phrasing this as eloquently as possible.) In my
case, I simply purchase co-lo space from providers and rely on their
routing configurations, hoping they're doing things properly. But
as one can see from the ipfw stats I pasted, some aren't. Understand
where I'm coming from?
> >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.
In that case, it's a win-win situation.
> >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.
Hmm, yes, you're absolutely correct. But I'm curious why you picked
192.0.2.0/24 rather than some other reserved block? (I've also sent
a copy of this discussion to an associate of mine at Nominum, who's
now wondering the same thing I am...)
I've found this thread immensely educational so far!
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
|