This is the RFC that is being violated: http://tools.ietf.org/html/rfc5625#section-6.2
6.2 <http://tools.ietf.org/html/rfc5625#section-6.2>. Interface Binding Some gateways have been observed to have their DNS proxy listening on both internal (LAN) and external (WAN) interfaces. In this configuration, it is possible for the proxy to be used to mount reflector attacks as described in [RFC5358 <http://tools.ietf.org/html/rfc5358>]. The DNS proxy in a gateway SHOULD NOT, by default, be accessible from the WAN interfaces of the device. Implemented correctly, CPE receives DNS request and proxies the request internally. Usually they are only listening on the LAN side. Sometimes they take DNS requests from the WAN side. When a local DNS cache is not defined, these requests can leak out to whatever cache is defined. In some cases, the CPE retains the IP address that originally sourced the packet. So you end up with external caches responding to requests from 3rd parties. Add to that spoofing the original packets to the bad CPE and you have that CPE proxying your DNS amplification attack to other caches. Don't blame the cache. The attacker was intending that the CPE amp directly. Fix: CPE should disable DNS proxying by default and require a restricted list of sources (LAN, vpn, etc) when enabled. Also/alternatively require cache to be local. --Heather On Sun, Aug 11, 2013 at 5:45 AM, Florian Weimer <f...@deneb.enyo.de> wrote: > * Jared Mauch: > > > Number of unique IPs that spoofed a packet to me. (eg: I sent a > > packet to 1.2.3.4 and 5.6.7.8 responded). > > That's not necessarily proof of spoofing, isn't it? The system in > question might legitimately own IP addresses from very different > networks. If the system is a router and the service you're pinging is > not correctly implemented and it picks up the IP address of the > outgoing interface instead of the source address of the request, > that's totally expected. > > I'm not saying that BCP 38 is widely implement (it's not, unless > operators have configured exceptions for ICMP traffic from private > address, which I very much doubt). I just think you aren't actually > measuring spoofing capabilities. > >