Re: what the heck do i do now?
One thing you might consider is putting together a script to harvest email addresses from whois records that correspond to the PTR for the querying IPs. Add to that list abuse, postmaster, webmaster, hostmaster, etc @ the poorly run domain. Then fire off a message explaining the situation and that you'll be adding a wildcard record on such and such date (preferably not 4/1). Script all of this and run it every couple of days until the date you gave and then follow through with the wildcard entry. This undoubtedly won't stop all of the whining but you can at least say you tried.
volunteers are welcome to apply for that job.
Perhaps you can get CNet or InfoWorld to pick it and write a story about the service and the impending change.
that, conversely, would be fun.
When it comes right down to it, you've got to do what you've got to do to recover your domain. You provided a service that many of us relied upon. The responsibility rests on our shoulders to keep up with the changing times. 7-8 years is more than enough time for even the laziest of mail admins to update their config. Think about how much bandwidth has been wasted over the years with these errant queries...
about 1 billionth as much as has been wasted by RFC1918-sourced DNS queries sent to the root name servers OR RFC1918-domained DNS updates sent to AS112. therefore i treat it as a personal annoyance but NOT a waste in its own right.
On Thu, 1 Feb 2007, Paul Vixie wrote:
One thing you might consider is putting together a script to harvest email addresses from whois records that correspond to the PTR for the querying IPs. Add to that list abuse, postmaster, webmaster, hostmaster, etc @ the poorly run domain. Then fire off a message explaining the situation and that you'll be adding a wildcard record on such and such date (preferably not 4/1). Script all of this and run it every couple of days until the date you gave and then follow through with the wildcard entry. This undoubtedly won't stop all of the whining but you can at least say you tried.
volunteers are welcome to apply for that job.
It's actually a trivial thing to do. Start with something like the geektools whois proxy. That'll handle getting the queries to the right RIR's whois server. Then all you need to do is parse the output for email addresses. For extra credit, you can look for common "abuse" addresses in the output and ignore other addresses in outputs where an "abuse" address is found. As for trying to "make it stop", the two methods thought to be most successful are: 1) maps.vix.com. 604800 IN NS . 2) maps.vix.com. 604800 IN NS u1.vix.com. maps.vix.com. 604800 IN NS u2.vix.com. maps.vix.com. 604800 IN NS u3.vix.com. ... [as many as you like] 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] 1) just tells them there is no NS, go away. 2) gives them someone unreachable to try, which they'll do, and do, and do, wasting lots of retransmitted queries and the time it takes them to timeout. If you're lucky, the timeouts might be noticed as increased load and mail slowdown on the servers sending these queries. Either way, a properly functioning caching DNS should leave you alone for a while after caching the fact that there (is no NS for maps.vix.com||the NS's for maps.vix.com are unreachable/unresponsive). i.e. Either of these should mitigate the traffic far better than simply returning NXDOMAIN for every maps.vix.com dnsbl query. Successful here doesn't necessarily mean "the traffic stopped" but rather the traffic has been mitigated as much as is possible without actually getting people to fix their systems and stop querying the dead zone. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
jlewis@lewis.org (Jon Lewis) writes:
As for trying to "make it stop", the two methods thought to be most successful are:
1) maps.vix.com. 604800 IN NS .
i've tried that. the retry rate actually goes up rather than down.
2) maps.vix.com. 604800 IN NS u1.vix.com. maps.vix.com. 604800 IN NS u2.vix.com. maps.vix.com. 604800 IN NS u3.vix.com. ... [as many as you like] 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.
Successful here doesn't necessarily mean "the traffic stopped" but rather the traffic has been mitigated as much as is possible without actually getting people to fix their systems and stop querying the dead zone.
right you are. it sort of goes against my personal grain to cause folks' mail to bounce when their only offense against the community is not reading the qmail man page and understanding the what the defaults are. -- Paul Vixie
On Thu, 1 Feb 2007, Paul Vixie wrote:
1) maps.vix.com. 604800 IN NS .
i've tried that. the retry rate actually goes up rather than down.
That's pretty messed up. I've tested both the strategies I suggested, and at least with both bind9 and DJB's dnscache, the caching name server will cache the NS, and in this (.) case, it won't ask the auth server(s) again for any subsequent queries in the former DNSBL zone (until the data expires from the cache). You must be getting hit by some seriously broken DNS caches. I don't have them handy to test, but I wonder what bind8 and bind4 do? After all, the sorts of people who setup servers to use a DNSBL 8 years ago and forgot about it, are the sorts who might still be running really old DNS server software.
2) maps.vix.com. 604800 IN NS u1.vix.com. maps.vix.com. 604800 IN NS u2.vix.com. maps.vix.com. 604800 IN NS u3.vix.com. ... [as many as you like] 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.
I prefer this method since it's non-destructive, but much more likely to be noticed than the immediate failure the queriers get with the . method. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Thu, Feb 01, 2007 at 08:45:52PM +0000, Paul Vixie wrote:
2) maps.vix.com. 604800 IN NS u1.vix.com. maps.vix.com. 604800 IN NS u2.vix.com. maps.vix.com. 604800 IN NS u3.vix.com. ... [as many as you like] 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. 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. Of course, this isn't an issue as long as every service on the face of the planet has some form of blackholing. In the case of someone pointing an MX record to something that has an A record of 127.255.255.255, for example, and lacks the blackholing capability, the service (postfix, sendmail, whatever) will blindly try to communicate with that destination, thus spewing out nasties on the console or in logfiles. Example: 00200 1234 93513 deny ip from { 127.0.0.0/8 or 192.168.0.0/16 or 172.16.0.0/12 or 10.0.0.0/8 } to any in recv fxp0 00201 3 180 deny log ip from any to { 127.0.0.0/8 or dst-ip 192.168.0.0/16 or dst-ip 172.16.0.0/12 or dst-ip 10.0.0.0/8 } out xmit fxp0 As you can see, there's still many routers which don't have outbound blocks in place. Since I do not trust my ISP to do this for me, and I believe in taking the initiative, I block them locally on the system. And as you can see (thus case in point), I don't have a very up-to-date list of IANA-reserved blocks in my list. Until I recently added the blackholing rules in BIND, I kept seeing the resolver try to contact 127.0.0.0/8 hosts, or 10.0.0.0/8 hosts. People who had things like "localhost" as auth. NS entries -- hey, isn't this what you did?! ;-) 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). -- | 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 |
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_________
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 |
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 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.
RFC 3330 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. 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 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?
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 what Paul 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 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...)
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 |
On Mon, Feb 05, 2007 at 10:13:08PM -0500, Jon Lewis <jlewis@lewis.org> wrote a message of 52 lines which said:
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
It SHOULD NOT show up, but it does (ROSPRINT-AS, AS2854, does announce it and, among others, routeviews.org sees it).
On Tue, 6 Feb 2007, Stephane Bortzmeyer wrote:
On Mon, Feb 05, 2007 at 10:13:08PM -0500, Jon Lewis <jlewis@lewis.org> wrote a message of 52 lines which said:
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
Somebody clipped the "unless something is broken" part of that statement.
It SHOULD NOT show up, but it does (ROSPRINT-AS, AS2854, does announce it and, among others, routeviews.org sees it).
So the simple conclusion is ROSPRINT-AS is broken. BTW, that route doesn't seem to propogate very far. I don't see it via Level3, Above.net, or TWTC. What I do see when looking at my incoming distribute list is that someone seems to keep trying to announce exactly 192/8. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
participants (6)
-
Jeremy Chadwick -
John Payne -
Jon Lewis -
Paul Vixie -
Paul Vixie -
Stephane Bortzmeyer