A new variant of DNS amplification attack relies on home gateways with open DNS proxies to forward DNS queries to ISP resolvers. To launch this exploit attacker can deploy their exploit code anywhere on the Internet that allows address spoofing, a compromised server in a hosting facility for example. From there DNS queries can be targeted at any network with open home gateways. These queries enter ISP networks at border routers.
One approach that's been discussed for deterring these attacks is to simply filter incoming traffic with a Destination Port of 53 at network borders (the well known port for DNS). On the surface it seems like a simple proposition but there's one important thing that should be considered - there is legitimate DNS traffic that will enter ISP networks on Port 53.
In a DNS query sent by a resolver the Destination Port is 53, and the Source Port is supposed to be randomized. Source Port Randomization was introduced after Dan Kaminsky's famous exploit was revealed in 2008. The goal was to make it more difficult for an attacker to guess query parameters, so they could not spoof a DNS answer and poison a DNS cache.
It turns out in practice not everyone is on board with Source Port Randomization. Recent DNS data analyzed by Nominum showed about 1% of DNS resolvers don't randomize, instead they use Port 53! Since authoritative servers sending answers back to resolvers simply mirror back the UDP Source Port as the Destination Port answers to queries sent from one of these resolvers located on a provider network would be sent back to that network on Destination Port 53.
This means if ISPs have subscribers on their networks that run resolvers configured in this way replies to their queries coming back into the network will get dropped if filters to block port 53 are used. 1% doesn't seem like a big number but even in a modest size network there could be a noticeable number of these servers. It's probably fair to note the kinds of subscribers who run resolvers are likely to be at least moderately sophisticated and correspondingly unhappy with compromised connectivity if their DNS queries are filtered.
Queries to authoritative servers ISPs manage on their networks, or those run by others but collocated on the provider network also come in on Port 53. Because they're critical infrastructure provider authoritative servers are likely on well known, stable addresses which makes the task easier. Presumably collocated authoritative servers can be identified as well. We've also found when providers methodically search for DNS servers they're often surprised by what turns up, so it might be worth going through the records to see if anything else turns up.
All this means a simple ACL to deny Port 53 could have unintended consequences - more precise ACLs that permit IPs with services using Port 53 are needed. Authoritative servers running in the network have to be accounted for and poorly configured resolvers (those that don't use UDP Source Port Randomization) also have to be covered. If subscribers running resolvers are addressed dynamically this has to be factored in as well - any ACL will have to change as addresses change. This is made even harder by the fact that subscribers can turn up new resolvers or at any time - so providers either have to wait for the phone to ring and deal with the fall out or figure out a way to identify them proactively.