Preventing Use of Recursive Nameservers in Reflector Attacks
RFC 5358
Document | Type |
RFC - Best Current Practice
(October 2008; No errata)
Also known as BCP 140
|
|
---|---|---|---|
Authors | Frederico Neves , João Damas | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5358 (Best Current Practice) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ron Bonica | ||
Send notices to | pk@isoc.de |
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. 4. Cleanup of the zone might, depending on the implementation used in the open recursive nameserver, afford a way to clean the cached record from the open recursive nameserver. This would possibly involve queries luring the open recursive nameserver to lookup information for the same name that is being used in theShow full document text