Preventing Use of Recursive Nameservers in Reflector Attacks
RFC 5358

Network Working Group                                           J. Damas
Request for Comments: 5358                                           ISC
BCP: 140                                                        F. Neves
Category: Best Current Practice                              Registro.br
                                                            October 2008

      Preventing Use of Recursive Nameservers in Reflector Attacks

Status of This Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Abstract

   This document describes ways to prevent the use of default configured
   recursive nameservers as reflectors in Denial of Service (DoS)
   attacks.  It provides recommended configuration as measures to
   mitigate the attack.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Document Terminology  . . . . . . . . . . . . . . . . . . . . . 2
   3.  Problem Description . . . . . . . . . . . . . . . . . . . . . . 2
   4.  Recommended Configuration . . . . . . . . . . . . . . . . . . . 4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6

Damas & Neves            Best Current Practice                  [Page 1]
RFC 5358        Preventing Rec. NS in Reflector Attacks     October 2008

1.  Introduction

   Recently, DNS [RFC1034] has been named as a major factor in the
   generation of massive amounts of network traffic used in Denial of
   Service (DoS) attacks.  These attacks, called reflector attacks, are
   not due to any particular flaw in the design of the DNS or its
   implementations, except that DNS relies heavily on UDP, the easy
   abuse of which is at the source of the problem.  The attacks have
   preferentially used DNS due to common default configurations that
   allow for easy use of open recursive nameservers that make use of
   such a default configuration.

   In addition, due to the small query-large response potential of the
   DNS system, it is easy to yield great amplification of the source
   traffic as reflected traffic towards the victims.

   DNS authoritative servers that do not provide recursion to clients
   can also be used as amplifiers; however, the amplification potential
   is greatly reduced when authoritative servers are used.  It is also
   impractical to restrict access to authoritative servers to a subset
   of the Internet, since their normal operation relies on them being
   able to serve a wide audience; hence, the opportunities to mitigate
   the scale of an attack by modifying authoritative server
   configurations are limited.  This document's recommendations are
   concerned with recursive nameservers only.

   In this document we describe the characteristics of the attack and
   recommend DNS server configurations that specifically alleviate the
   problem described, while pointing to the only real solution: the
   wide-scale deployment of ingress filtering to prevent use of spoofed
   IP addresses [BCP38].

2.  Document Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Problem Description

   Because most DNS traffic is stateless by design, an attacker could
   start a DoS attack in the following way:

   1.  The attacker starts by configuring a record on any zone he has
       access to, normally with large RDATA and Time to Live (TTL).

Damas & Neves            Best Current Practice                  [Page 2]
RFC 5358        Preventing Rec. NS in Reflector Attacks     October 2008

   2.  Taking advantage of clients on non-BCP38 networks, the attacker
       then crafts a query using the source address of their target
       victim and sends it to an open recursive nameserver.

   3.  Each open recursive nameserver proceeds with the resolution,
       caches the record, and finally sends it to the target.  After
       this first lookup, access to the authoritative nameservers is
       normally no longer necessary.  The record will remain cached at
       the open recursive nameserver for the duration of the TTL, even
       if it's deleted from the zone.