nanog mailing list archives
Re: what the heck do i do now?
From: John Payne <john () sackheads org>
Date: Tue, 6 Feb 2007 01:31:45 -0500
On Feb 6, 2007, at 12:40 AM, Jeremy Chadwick wrote:
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 indocumentation and example code. It is often used in conjunction withdomain names example.com or example.net in vendor and protocoldocumentation. Addresses within this block should not appear on thepublic 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.
RFC 3330 192.0.2.0/24 - This block is assigned as "TEST-NET" for use indocumentation 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.BTW - there's nothing that says anything about filtering 192.0.0.0/17. It might be reserved for IANA, but there's nothing saying it can't be used. Looks to me like ICANN is using some of their sub-allocation in that space.
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 anISP/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?
Packets destined for 192.0.2.0/24 will follow the money trail. As soon as someone stops paying, the packets will die. (Actually sometimes they'll drop off sooner than the money trail, but that's irrelevant). What I'm saying is that by sending packets to 192.0.2.0 the only people who'll be "harmed" by that action are people you're paying.
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 whatPaul wants.In that case, it's a win-win situation.
Which is probably why it was suggested....
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 theyhave 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...)
Pointing to RFC 1918 space is likely to cause "harm". 192.0.2.0/24 is guaranteed not to (unless people don't follow RFC allocations....)
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 |
Current thread:
- Re: what the heck do i do now?, (continued)
- Re: what the heck do i do now? Scott Weeks (Feb 01)
- Re: what the heck do i do now? Michael Froomkin - U.Miami School of Law (Feb 01)
- Re: what the heck do i do now? bmanning (Feb 01)
- Re: what the heck do i do now? Paul Vixie (Feb 01)
- Re: what the heck do i do now? Tony Finch (Feb 01)
- Re: what the heck do i do now? Paul Vixie (Feb 01)
- Re: what the heck do i do now? Jon Lewis (Feb 01)
- Re: what the heck do i do now? Jeremy Chadwick (Feb 05)
- Re: what the heck do i do now? Jon Lewis (Feb 05)
- Re: what the heck do i do now? Jeremy Chadwick (Feb 05)
- Re: what the heck do i do now? John Payne (Feb 05)
- Re: what the heck do i do now? Stephane Bortzmeyer (Feb 06)
- Re: what the heck do i do now? Jon Lewis (Feb 06)
- Re: what the heck do i do now? Scott Weeks (Feb 01)
- Re: what the heck do i do now? Simon Lyall (Feb 04)
- Re: what the heck do i do now? Jon Lewis (Feb 04)
- Re: what the heck do i do now? Warren Kumari (Feb 04)