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
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| 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.
Show full document text