Skip to main content

Measures for Making DNS More Resilient against Forged Answers
RFC 5452

Revision differences

Document history

Date Rev. By Action
2018-12-20
10 (System)
Received changes through RFC Editor sync (changed abstract to 'The current Internet climate poses serious threats to the Domain Name System. In the interim period …
Received changes through RFC Editor sync (changed abstract to '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. [STANDARDS-TRACK]')
2017-05-16
10 (System) Changed document authors from "Remco Mook" to "Remco Mook, Bert Hubert"
2015-10-14
10 (System) Notify list changed from dnsext-chairs@ietf.org, draft-ietf-dnsext-forgery-resilience@ietf.org to (None)
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Pasi Eronen
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2012-08-22
10 (System) post-migration administrative database adjustment to the Yes position for Mark Townsley
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2009-02-02
10 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2009-02-02
10 Cindy Morgan [Note]: 'RFC 5452' added by Cindy Morgan
2009-01-28
10 (System) RFC published
2008-12-17
10 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2008-12-17
10 (System) IANA Action state changed to No IC from In Progress
2008-12-17
10 (System) IANA Action state changed to In Progress
2008-12-17
10 Amy Vezza IESG state changed to Approved-announcement sent
2008-12-17
10 Amy Vezza IESG has approved the document
2008-12-17
10 Amy Vezza Closed "Approve" ballot
2008-12-17
10 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2008-12-17
10 Mark Townsley [Ballot Position Update] Position for Mark Townsley has been changed to Yes from No Objection by Mark Townsley
2008-12-17
10 Mark Townsley [Ballot Position Update] Position for Mark Townsley has been changed to No Objection from Discuss by Mark Townsley
2008-12-16
10 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert
2008-12-15
10 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen
2008-12-15
10 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-12-15
10 (System) New version available: draft-ietf-dnsext-forgery-resilience-10.txt
2008-12-10
10 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2008-12-05
10 (System) Removed from agenda for telechat - 2008-12-04
2008-12-04
10 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2008-12-04
10 Russ Housley
[Ballot discuss]
I did not see a response to the Last Call comments from
  Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>.  Please point
  me to …
[Ballot discuss]
I did not see a response to the Last Call comments from
  Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>.  Please point
  me to the response.
2008-12-04
10 Russ Housley
[Ballot discuss]
I did not see a response to the Last Call comments from
  Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>.  Please point
  me to …
[Ballot discuss]
I did not see a response to the Last Call comments from
  Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>.  Please point
  me to the response.
2008-12-04
10 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2008-12-04
10 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2008-12-04
10 Jari Arkko [Ballot comment]
I agree though with Cullen's, Pasi's, and Lars's discusses.
2008-12-04
10 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko
2008-12-04
10 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2008-12-03
10 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2008-12-03
10 Mark Townsley [Ballot discuss]
Holding just to be sure that Cullen's Comment is considered. Unfortunately, I don't think we can ignore NATs here.
2008-12-03
10 Mark Townsley [Ballot Position Update] Position for Mark Townsley has been changed to Discuss from Yes by Mark Townsley
2008-12-03
10 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2008-12-03
10 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2008-12-03
10 Amy Vezza State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Amy Vezza
2008-12-02
10 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2008-12-02
10 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2008-12-02
10 Pasi Eronen
[Ballot discuss]
A process note: as the proto write-up points out, there's a normative
reference to an informational RFC. If that would have been mentioned …
[Ballot discuss]
A process note: as the proto write-up points out, there's a normative
reference to an informational RFC. If that would have been mentioned
in the IETF Last Call message, everything would be fine.... but it
was not.

We could change this to an informative reference  (it looks like reading
RFC 3833 isn't absolutely required to implement the implementable parts
of this draft), or re-do the IETF Last Call.
2008-12-02
10 Pasi Eronen [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen
2008-12-01
10 Cullen Jennings
[Ballot comment]
I'm wondering about the case where the resolver is behind a NAT, and the attacker can cause the NAT to do many thousands …
[Ballot comment]
I'm wondering about the case where the resolver is behind a NAT, and the attacker can cause the NAT to do many thousands of DNS queries in a a few minutes, the randomization of ports can cause complete depletion of all ports on the NAT resulting in failure of all applications behind the NAT.

I'd like authors to let me know if this has been considered and it is not a problem for some reason I'm not thinking of. If it is a problem, it might be worth adding a little text discussing the issue to the draft.
2008-12-01
10 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings
2008-12-01
10 Cullen Jennings [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings
2008-12-01
10 Lars Eggert
[Ballot discuss]
DISCUSS: Sections 4.5, 7.1 and 9.2 suggest that the port range 1-1024
  should be avoided when randomizing, but that the 1024-65536 range …
[Ballot discuss]
DISCUSS: Sections 4.5, 7.1 and 9.2 suggest that the port range 1-1024
  should be avoided when randomizing, but that the 1024-65536 range
  would be OK. The document needs some additional text that clarifies
  the tradeoffs surrounding this recommendation, because port numbers
  from 1-49152 can be registered and randomizing over 1024-65536 can
  cause problems for applications that have registered a port in the
  1024-49152 range and expect it to be available. The document does need
  to caution implementers that there is a potential downside to
  randomizing over the larger range and should recommend that a
  mechanism exist by which specific ports can be excluded from being
  used for randomization. Section 3.2 of
  draft-ietf-tsvwg-port-randomization has some related text that may be
  a starting point.
2008-12-01
10 Lars Eggert
[Ballot discuss]
DISCUSS: Sections 4.5, 7.1 and 9.2 suggest that the port range 1-1024
  should be avoided when randomizing, but that the 1024-65536 range …
[Ballot discuss]
DISCUSS: Sections 4.5, 7.1 and 9.2 suggest that the port range 1-1024
  should be avoided when randomizing, but that the 1024-65536 range
  would be OK. The document needs some additional text that clarifies
  the tradeoffs surrounding this recommendation, because port numbers
  from 1-49152 can be registered and randomizing over 1024-65536 can
  cause problems for applications that have registered a port in the
  1024-49152 range and expect it to be available. The document does need
  to caution implementers that there is a potential downside to
  randomizing over the larger range and should recommend that a
  mechanism exist by which specific ports can be excluded from being
  used for randomization. Section 3.2 of
  draft-ietf-tsvwg-port-randomization has some related text that may be
  a starting point.
2008-12-01
10 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2008-11-19
10 Mark Townsley [Ballot Position Update] New position, Yes, has been recorded for Mark Townsley
2008-11-19
10 Mark Townsley Ballot has been issued by Mark Townsley
2008-11-19
10 Mark Townsley Created "Approve" ballot
2008-11-19
10 Mark Townsley Note field has been cleared by Mark Townsley
2008-11-17
09 (System) New version available: draft-ietf-dnsext-forgery-resilience-09.txt
2008-11-17
08 (System) New version available: draft-ietf-dnsext-forgery-resilience-08.txt
2008-11-17
10 Mark Townsley Placed on agenda for telechat - 2008-12-04 by Mark Townsley
2008-11-17
10 Mark Townsley [Note]: 'Waiting on thumbs up from doc shepherd (olafur) before going on telechat.' added by Mark Townsley
2008-10-16
10 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-10-08
10 Amanda Baber IANA Last Call comments:

As described in the IANA Considerations section, we understand
this document to have NO IANA Actions.
2008-10-03
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Marcus Leech
2008-10-03
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Marcus Leech
2008-10-02
10 Amy Vezza Last call sent
2008-10-02
10 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-10-02
10 Mark Townsley Last Call was requested by Mark Townsley
2008-10-02
10 Mark Townsley State Changes to Last Call Requested from Publication Requested by Mark Townsley
2008-10-02
10 (System) Ballot writeup text was added
2008-10-02
10 (System) Last call text was added
2008-10-02
10 (System) Ballot approval text was added
2008-08-25
10 Cindy Morgan
Title : Measures for making DNS more resilient against forged answers
Author(s) : A. Hubert, R. van Mook
Filename : draft-ietf-dnsext-forgery-resilience-07.txt
Date : August 25 …
Title : Measures for making DNS more resilient against forged answers
Author(s) : A. Hubert, R. van Mook
Filename : draft-ietf-dnsext-forgery-resilience-07.txt
Date : August 25 2008
Document shepherd: Olafur Gudmundsson ogud@ogud.com


1) Have the chairs personally reviewed this version of the ID and do
they believe this ID is sufficiently baked to forward to the IESG
for publication?

There is one nit according to idnits 2.08.10 (via tools.ietf.org).
The nit is that Informational RFC 3833 is a normative reference.
RFC 3833 is about the DNS threat model, this document addresses one of the
treats identified in RFC 3833 and describes techniques to make it harder
to exploit that particular threat.
We are not sure the reference should be moved between sections or not.


2) Has the document had adequate review from both key WG members and
key non-WG members? Do you have any concerns about the depth or
breadth of the reviews that have been performed?


Yes during last-call this document has been reviewed in depth by
a large number of working group members.
This particular document and the recent DNS exploits that attempt to
poison DNS caches, have brought number of new people to the working group.
We have no issue with the extent of reviews.

There is strong consensus to advance the document.

3) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

We think this document has had sufficient review.

4) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For example,
perhaps you are uncomfortable with certain parts of the document,
or whether there really is a need for it, etc., but at the same
time these issues have been discussed in the WG and the WG has
indicated it wishes to advance the document anyway.


The only issues that people brought up are:
Standards track vs. BCP.
The TCP fallback

On the first one most people stated preference to one or the other but at
the same time said they could live with the other.
The requirement in section 9 that resolvers be capable of using
multiple source ports at once is arguably a new requirement, and could
have inter operation effects.
See:
http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00873.html

As for the TCP fallback there is some concern in the operating community
that extensive use of TCP by resolver may cause problems. The chairs and
editors point out that TCP is an allowed transport protocol thus recommending
its use in certain situations, in particular when under attack is justified.


5) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with
it?


The consensus is strong, on the document as whole.

6) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize what are they upset about.

No one has threatened an appeal.


7) Have the chairs verified that the document adheres to _all_ of the
ID nits? (see http://www.ietf.org/ID-nits.html).

Yes but see note #1 above.


8) For Standards Track and BCP documents, the IESG approval
announcement includes a write up section with the following
sections:

- Technical Summary

DNS uses UDP for most of its query resolution process, to protect against
forged UDP replies DNS has relied on a Query-ID field that is 16
bits long.
The size of this field was adequate when network connections
were slower than
is common today. The document documents measures to extend the effective
Query-ID by using all available UDP ports, different source address (when
possible) and using different authorative servers.


All of the measures documented in the document, have been in use
in certain
implementations for a long time, and recently been almost universally
deployed in all major implementations.

- Working Group Summary

There is a broad consensus that this important document be published.

- Protocol Quality

The techniques described in the document have been implemented
and are in use
use by number of implementations, with no interoperabilty
issues. The only issues
observed have been related to inability to allocate large number
of open ports on
certain operating systems, and firewalls/IDS not expecting the use of
random ports by DNS resolvers.
2008-08-25
10 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2008-08-14
07 (System) New version available: draft-ietf-dnsext-forgery-resilience-07.txt
2008-07-30
06 (System) New version available: draft-ietf-dnsext-forgery-resilience-06.txt
2008-06-26
05 (System) New version available: draft-ietf-dnsext-forgery-resilience-05.txt
2008-06-23
04 (System) New version available: draft-ietf-dnsext-forgery-resilience-04.txt
2008-03-24
03 (System) New version available: draft-ietf-dnsext-forgery-resilience-03.txt
2008-03-04
02 (System) New version available: draft-ietf-dnsext-forgery-resilience-02.txt
2008-02-15
10 (System) Document has expired
2007-08-07
01 (System) New version available: draft-ietf-dnsext-forgery-resilience-01.txt
2007-01-12
00 (System) New version available: draft-ietf-dnsext-forgery-resilience-00.txt