I work for a large email provider and we've run into trouble delivering mail to certain sites after bringing up new servers in a recently allocated subnet of 72/8. Apparently, some folks decided it would be a good policy to protect their nameservers from ddos attacks to silently drop requests from unallocated subnets. So they obtained a list of subnets at some point in the past, deployed it and then never updated it. This manifests itsself in our system when the dns query repeatedly times out on the smtp servers in that subnet while it works from elsewhere. In the instances we've run into this, it only seemed to affect dns and not, say, smtp connections. I just wanted to try to raise some awareness of this practice and the trouble it may cause if the ruleset gets out-of-date. This caused us a pretty major headache the result of which is that we've given up for now on trying to deliver mail out of that subnet. john
On Fri, 2 Dec 2005, John S. Bucy wrote:
I work for a large email provider and we've run into trouble delivering mail to certain sites after bringing up new servers in a recently allocated subnet of 72/8. Apparently, some folks decided it would be a good policy to protect their nameservers from ddos attacks to silently drop requests from unallocated subnets. So they obtained a list of subnets at some point in the past, deployed it and then never updated it.
Welcome to 2002. Have a look at http://69box.atlantic.net/ ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Hi, John. ] I work for a large email provider and we've run into trouble ] delivering mail to certain sites after bringing up new servers in a ] recently allocated subnet of 72/8. Apparently, some folks decided it ] would be a good policy to protect their nameservers from ddos attacks ] to silently drop requests from unallocated subnets. So they obtained ] a list of subnets at some point in the past, deployed it and then ] never updated it. This is why we recommend to those who filter unallocated and bogon space to keep current with lists such as the sundry formats found here: <http://www.cymru.com/Bogons/> Another option is to automate the updates and leave the hard work to us! :) Consider peering with the Bogon route-servers, located throughout the globe thanks to the kind donation of hosting from several folks. <http://www.cymru.com/BGP/bogon-rs.html> Thanks, Rob. -- Rob Thomas Team Cymru http://www.cymru.com/ ASSERT(coffee != empty);
Hi, Randy. ] > Another option is to automate the updates and leave the hard work ] > to us! ] ] the op was discussing port-specific filtering for dns only. could ] you explain how i can automake my /etc/ipfw.rules leaving the hard ] work to you? e.g. There are often subtle relationships when it comes to filtering. While the DNS name servers may have no such filters, they are unreachable due to filters on upstream routers. So we try to provide as wide a set of filters as possible. ] add deny udp from 203.49.118.0/24 to any 53 Now that is a set of filters we don't make available. I'll see if I can create another page for IPFW filters. I should do the same for IPF as well. You could Zebra peer with the Bogon route-servers and accept these prefixes as null routes. I've used null routes on servers frequently, but I've not tried the combination before. Take it with a grain of salt. :) Thanks, Rob. -- Rob Thomas Team Cymru http://www.cymru.com/ ASSERT(coffee != empty);
Hi Rob, On Sat, 2005-12-03 at 06:14, Rob Thomas wrote:
You could Zebra peer with the Bogon route-servers and accept these prefixes as null routes. I've used null routes on servers frequently, but I've not tried the combination before. Take it with a grain of salt. :)
This works fine if you can remember to keep your bogon filters current, which we and other networks in oz have found recently many networks in fact do not. Which reminds me, if anyone has 125.0.0.0/8 null routed, shame on you :) It was brought into life many months ago by APNIC. Cheers
participants (5)
-
John S. Bucy -
Jon Lewis -
Noel -
Randy Bush -
Rob Thomas