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 |