Measures for Making DNS More Resilient against Forged Answers
RFC 5452

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 10

Network Working Group                                          A. Hubert
Request for Comments: 5452            Netherlabs Computer Consulting BV.
Updates: 2181                                                R. van Mook
Category: Standards Track                                        Equinix
                                                            January 2009

     Measures for Making DNS More Resilient against Forged Answers

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (http://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The current Internet climate poses serious threats to the Domain Name
   System.  In the interim period before the DNS protocol can be secured
   more fully, measures can already be taken to harden the DNS to make
   'spoofing' a recursing nameserver many orders of magnitude harder.

   Even a cryptographically secured DNS benefits from having the ability
   to discard bogus responses quickly, as this potentially saves large
   amounts of computation.

   By describing certain behavior that has previously not been
   standardized, this document sets out how to make the DNS more
   resilient against accepting incorrect responses.  This document
   updates RFC 2181.

Hubert & van Mook           Standards Track                     [Page 1]
RFC 5452         DNS Resilience against Forged Answers      January 2009

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements and Definitions . . . . . . . . . . . . . . . . .  4
     2.1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Key Words  . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Description of DNS Spoofing  . . . . . . . . . . . . . . . . .  5
   4.  Detailed Description of Spoofing Scenarios . . . . . . . . . .  6
     4.1.  Forcing a Query  . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Matching the Question Section  . . . . . . . . . . . . . .  7
     4.3.  Matching the ID Field  . . . . . . . . . . . . . . . . . .  7
     4.4.  Matching the Source Address of the Authentic Response  . .  7
     4.5.  Matching the Destination Address and Port of the
           Authentic Response . . . . . . . . . . . . . . . . . . . .  8
     4.6.  Have the Response Arrive before the Authentic Response . .  8
   5.  Birthday Attacks . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Accepting Only In-Domain Records . . . . . . . . . . . . . . .  9
   7.  Combined Difficulty  . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  Symbols Used in Calculation  . . . . . . . . . . . . . . . 10
     7.2.  Calculation  . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Repetitive Spoofing Attempts for a Single Domain Name  . . 13
   9.  Forgery Countermeasures  . . . . . . . . . . . . . . . . . . . 13
     9.1.  Query Matching Rules . . . . . . . . . . . . . . . . . . . 13
     9.2.  Extending the Q-ID Space by Using Ports and Addresses  . . 14
       9.2.1.  Justification and Discussion . . . . . . . . . . . . . 14
     9.3.  Spoof Detection and Countermeasure . . . . . . . . . . . . 15
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     12.2. Informative References . . . . . . . . . . . . . . . . . . 17

Hubert & van Mook           Standards Track                     [Page 2]
RFC 5452         DNS Resilience against Forged Answers      January 2009

1.  Introduction

   This document describes several common problems in DNS
   implementations, which, although previously recognized, remain
   largely unsolved.  Besides briefly recapping these problems, this
   document contains rules that, if implemented, make complying
   resolvers vastly more resistant to the attacks described.  The goal
   is to make the existing DNS as secure as possible within the current
   protocol boundaries.

   The words below are aimed at authors of resolvers: it is up to
   operators to decide which nameserver implementation to use, or which