Preventing DNS Fragmentation and Large DNS Packet Attacks

Often times, attackers will attempt to perform very rudimentary attacks against DNS resolvers in an attempt to cause a Denial of Service. It is not uncommon to see attackers crafting a DoS attack composed mostly of UDP packets destined to port 53 with invalid payloads containing the ‘more-fragments’ bit set. In some cases, the packets may contain the ‘non-more-fragments’ bit set with packets of specific lengths, typically larger than the average size of a normal DNS packet.

Many flow analysis tools and IDP products have the ability to look for IP fragmentation misuse based on parameters that the operator may set; these tools are invaluable as an early warning system to alert the network administrator that their infrastructure is under attack.

Insofar as being able to mitigate these types of attacks, a few simple approaches can be utilized by a network administrator in order to filter this type of traffic using simple ACLs or firewall filters on routers or other types of equipment capable of filtering at Layers 3 and 4. Normally, is is not typical to see DNS queries which are fragmented, therefore the following Juniper firewall-filter should effectively filter the fragmented packets:

term DNS-Fragments {
  from {
     destination-prefix-list {
         dns-server-prefixes;
   }
     }
     fragment-flags more-fragments;
     destination-port 53;
  }
  then {
     count dns-fragments;
     log;
     discard;
  }
}

For packets containing the ‘non-more-fragments’ bit set, or which all packets within the attack flows share a common packet size (typically this will be large, on the order of 540 bytes or larger), a network administrator can easily filter those on the router as well. Normally we should not expect to see queries of this large size, so the following could be effectively used to filter these types of attacks as well.  In this example we are filtering UDP or TCP packets destined to port 53, with a size of either 540 bytes or 1480:

term DNS-InvalidSize {
   from {
       destination-prefix-list {
          dns-server-prefixes;
    }
       packet-length [ 540 1480 ];
       destination-port 53;
   }
   then {
       count dns-InvalidSize;
      log;        
      discard;
   }
}

NOTE: It is more than likely a network administrator would need to adjust the above packet sizes after analysis of the packet size used in the attack vector using whatever flow reporting or network visibility tools are in use, since it is unlikely an attacker would use the exact same packet sizes listed in the example above.