draft-ietf-dnsext-forgery-resilience-08.txt   draft-ietf-dnsext-forgery-resilience-09.txt 
DNS Extensions (DNSEXT) A. Hubert DNS Extensions (DNSEXT) A. Hubert
Internet-Draft Netherlabs Computer Consulting BV. Internet-Draft Netherlabs Computer Consulting BV.
Updates: 2181 (if approved) R. van Mook Updates: 2181 (if approved) R. van Mook
Intended status: Standards Track Equinix Intended status: Standards Track Equinix
Expires: May 21, 2009 November 17, 2008 Expires: May 22, 2009 November 18, 2008
Measures for making DNS more resilient against forged answers Measures for making DNS more resilient against forged answers
draft-ietf-dnsext-forgery-resilience-08.txt draft-ietf-dnsext-forgery-resilience-09.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 21, 2009. This Internet-Draft will expire on May 22, 2009.
Abstract Abstract
The current Internet climate poses serious threats to the Domain Name The current Internet climate poses serious threats to the Domain Name
System. In the interim period before the DNS protocol can be secured 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 more fully, measures can already be taken to harden the DNS to make
'spoofing' a recursing nameserver many orders of magnitude harder. 'spoofing' a recursing nameserver many orders of magnitude harder.
Even a cryptographically secured DNS benefits from having the ability Even a cryptographically secured DNS benefits from having the ability
to discard bogus responses quickly, as this potentially saves large to discard bogus responses quickly, as this potentially saves large
amounts of computation. amounts of computation.
By describing certain behaviour that has previously not been By describing certain behaviour that has previously not been
standardised, this document sets out how to make the DNS more standardised, this document sets out how to make the DNS more
resilient against accepting incorrect responses. This document resilient against accepting incorrect responses. This document
updates RFC 2128. updates RFC 2181.
Table of Contents Table of Contents
1. Requirements and definitions . . . . . . . . . . . . . . . . . 4 1. Requirements and definitions . . . . . . . . . . . . . . . . . 4
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Key words . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Key words . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Description of DNS spoofing . . . . . . . . . . . . . . . . . 7 3. Description of DNS spoofing . . . . . . . . . . . . . . . . . 7
4. Detailed Description of Spoofing Scenarios . . . . . . . . . . 8 4. Detailed Description of Spoofing Scenarios . . . . . . . . . . 8
4.1. Forcing a query . . . . . . . . . . . . . . . . . . . . . 8 4.1. Forcing a query . . . . . . . . . . . . . . . . . . . . . 8
skipping to change at page 8, line 48 skipping to change at page 8, line 48
indicate from which absolute time onwards a new query could be sent indicate from which absolute time onwards a new query could be sent
to refresh the expired entry. to refresh the expired entry.
The time to live of the target domain name's RRSets determines how The time to live of the target domain name's RRSets determines how
often a window of opportunity is available, which implies that a often a window of opportunity is available, which implies that a
short TTL makes spoofing far more viable. short TTL makes spoofing far more viable.
Note that the attacker might very well have authorised access to the Note that the attacker might very well have authorised access to the
target resolver by virtue of being a customer or employee of its target resolver by virtue of being a customer or employee of its
operator. In addition, access may be enabled through the use of operator. In addition, access may be enabled through the use of
reflectors as outlined in [I-D.ietf-dnsop-reflectors-are-evil]. reflectors as outlined in [RFC5358].
4.2. Matching the question section 4.2. Matching the question section
DNS packets, both queries and responses, contain a question section. DNS packets, both queries and responses, contain a question section.
Incoming responses should be verified to have a question section that Incoming responses should be verified to have a question section that
is equivalent to that of the outgoing query. is equivalent to that of the outgoing query.
4.3. Matching the ID field 4.3. Matching the ID field
The DNS ID field is 16 bits wide, meaning that if full use is made of The DNS ID field is 16 bits wide, meaning that if full use is made of
skipping to change at page 22, line 48 skipping to change at page 22, line 48
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
13.2. Informative References 13.2. Informative References
[I-D.ietf-dnsop-reflectors-are-evil]
Damas, J. and F. Neves, "Preventing Use of Recursive
Nameservers in Reflector Attacks",
draft-ietf-dnsop-reflectors-are-evil-05 (work in
progress), December 2007.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
Nameservers in Reflector Attacks", BCP 140, RFC 5358,
October 2008.
[vu-457875] [vu-457875]
United States CERT, "Various DNS service implementations United States CERT, "Various DNS service implementations
generate multiple simultaneous queries for the same generate multiple simultaneous queries for the same
resource record", VU 457875, November 2002. resource record", VU 457875, November 2002.
Authors' Addresses Authors' Addresses
Bert Hubert Bert Hubert
Netherlabs Computer Consulting BV. Netherlabs Computer Consulting BV.
Braillelaan 10 Braillelaan 10
 End of changes. 7 change blocks. 
11 lines changed or deleted 9 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/