DNS Proxy Implementation Guidelines
RFC 5625
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14
|
06 | (System) | Notify list changed from dnsext-chairs@ietf.org, draft-ietf-dnsext-dnsproxy@ietf.org to (None) |
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the Yes position for Jari Arkko |
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the Yes position for Lars Eggert |
2009-08-25
|
06 | Cindy Morgan | State Changes to RFC Published from RFC Ed Queue by Cindy Morgan |
2009-08-25
|
06 | Cindy Morgan | [Note]: 'RFC 5625; BCP 152' added by Cindy Morgan |
2009-08-24
|
06 | (System) | RFC published |
2009-07-07
|
06 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2009-07-06
|
06 | (System) | IANA Action state changed to No IC from In Progress |
2009-07-06
|
06 | (System) | IANA Action state changed to In Progress |
2009-07-06
|
06 | Amy Vezza | IESG state changed to Approved-announcement sent |
2009-07-06
|
06 | Amy Vezza | IESG has approved the document |
2009-07-06
|
06 | Amy Vezza | Closed "Approve" ballot |
2009-07-02
|
06 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss by Jari Arkko |
2009-07-02
|
06 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to Yes from Discuss by Lars Eggert |
2009-07-02
|
06 | (System) | New version available: draft-ietf-dnsext-dnsproxy-06.txt |
2009-06-05
|
06 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Alan DeKok. |
2009-06-05
|
06 | (System) | Removed from agenda for telechat - 2009-06-04 |
2009-06-04
|
06 | Cindy Morgan | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Cindy Morgan |
2009-06-04
|
06 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
2009-06-04
|
06 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk |
2009-06-04
|
06 | Tim Polk | [Ballot discuss] This is a good document and I support publication. Unfortunately, Alan DeKok's secdir review of this document black-holed due to a typo and … [Ballot discuss] This is a good document and I support publication. Unfortunately, Alan DeKok's secdir review of this document black-holed due to a typo and was never sent to the authors. His comments focused on the evils of DNS proxies as deployed in WiFi hotspots, and I would appreciate it if the authors could review his comments to see if additional text in the Security Considerations section is needed. (As I interpret the document, the behaviors he highlights are already forbidden by the specification.) The review is appended below, and my apologies about the last minute post. I will clear once the authors indicate whether they believe changes are needed. -- appended review from Alan DeKok ------ I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Over all, the document appears to be clear. I wonder about the following text in section 4.5, however: NB: any DNS proxy (such as those commonly found in WiFi hotspot "walled gardens") which transparently intercepts all DNS queries, and which returns unsigned responses to signed queries, will also cause TSIG authentication failures. The problem with WiFi hotspot DNS proxies is much, much, worse than this simple paragraph would suggest. There are issues found in in those deployments that are not discussed in this document. I will summarize them here: Issue: responding to all DNS requests with the IP of the hotspot Goal: to guide all client traffic to the hotspot Background: Many client machines have VPN software that checks for the existence of "internal" corporate DNS names. If the names resolve, the client is assumed to be "within" the corporate network. If the name does not resolve, the client is assumed to be elsewhere, and the VPN software behaves differently. DNS proxies that return an answer for all names result in the client erroneously believing it is in the "internal" network. Various things then fail in weird and wonderful ways. Even when VPN software doesn't exist, this practice can cause other problems. A commonly used web browser (I.E. from a major vendor) can cache the results of DNS queries at the application layer. This information is cached even across DHCP lease assignments from a new subnet, where DNS caches are usually flushed. The result is that the web browser cannot view the first web page that the user tries to visit. The captive portal page is always shown instead. Suggestion: DNS proxies MUST NOT respond with an answer if the name is not resolvable. DNS proxies MUST NOT synthesize an answer. Issue: responding to all DNS requests with a fake IP (commonly 1.1.1.1) Goal: to catch *different* kinds of traffic than the previous issue (this is no explanation, I've never had one explained to me in a way I understand) Background: Some proxies return synthetic responses with "fake" IP addresses. While 1.1.1.1 is not currently allocated, it may be in the future. Using it is a bad choice. In fact, this whole practice is completely wtong. Suggestion: Same as above. DNS proxies MUST NOT synthesize an answer. The above suggestions might be a little strong. There are valid cases where a proxy inside of a corporate network might need to synthesize incorrect answers. These situations are better described as "internal corporate policy". i.e. Notwithstanding the suggestions above, if you want to break your own network, there are often valid reasons for doing so. Alan DeKok. |
2009-06-04
|
06 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Discuss from Undefined by Tim Polk |
2009-06-04
|
06 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from No Objection by Tim Polk |
2009-06-04
|
06 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2009-06-04
|
06 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2009-06-04
|
06 | Dan Romascanu | [Ballot comment] I support Lars's DISCUSS. |
2009-06-04
|
06 | Jari Arkko | [Ballot discuss] This a long-overdue and very good document. Thanks! However, I would like to talk about the strength of the recommendations. We've already talked … [Ballot discuss] This a long-overdue and very good document. Thanks! However, I would like to talk about the strength of the recommendations. We've already talked TCP, but there's another case as well -- flags in Section 4.1, and how it affect EDNS0. I believe both this and the TCP case actually warrant a MUST statement. My argument for the appropriateness of a Discuss is as follows. First, the IETF specification should not just be a representation of the minimal functionality that vendors appear to implement; it should be the right functionality that is required to get the job done. While I think there is some chance of a MUST being ignored, I think the overall effect of saying MUST would be that more devices would support the functionality than otherwise. Second, without this MUST some functionality does break (as evidenced by Lars's home gateway example). The DNS proxy is not alone, what it does affects severely also on the clients and DNS servers. |
2009-06-04
|
06 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
2009-06-04
|
06 | Pasi Eronen | [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen |
2009-06-04
|
06 | Pasi Eronen | [Ballot comment] I support Lars's discuss -- we know that lack of TCP support in broadband gateways (etc.) is already causing problems (when zones deploy … [Ballot comment] I support Lars's discuss -- we know that lack of TCP support in broadband gateways (etc.) is already causing problems (when zones deploy DNSSEC), and we're expecting DNSSEC to become more widely used, not less. TCP might have been an optional capability in RFC 1123 (20 years ago), but it is required today. |
2009-06-04
|
06 | Lars Eggert | [Ballot discuss] (I'm temporarily updating this part of my original comment to a Discuss, to make sure we talk about this on the call. I … [Ballot discuss] (I'm temporarily updating this part of my original comment to a Discuss, to make sure we talk about this on the call. I expect to go back to a Yes afterwards.) Section 6.1.3.2, paragraph 1: > DNS proxies SHOULD therefore be prepared to receive and forward > queries over TCP. Shouldn't this be a MUST? Under which conditions is it OK to not do TCP? |
2009-06-04
|
06 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to Discuss from Yes by Lars Eggert |
2009-06-03
|
06 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2009-06-03
|
06 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2009-06-03
|
06 | Robert Sparks | [Ballot comment] 1) I had the same question as Lars (in the section on TCP Transport) - why does the document say proxies SHOULD be … [Ballot comment] 1) I had the same question as Lars (in the section on TCP Transport) - why does the document say proxies SHOULD be prepared to forward queries over TCP instead of MUST? 2) At the bottom of page 10, the document recommends responding to malformed requests rather than dropping them to avoid retransmissions of the request. In circumstances where there would be enough traffic for this to make a difference, would it also be useful to discuss the alternative of dropping packets if an attacker is (perhaps statelessly) sending a large number of malformed packets just to consume the processor? |
2009-06-03
|
06 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks |
2009-06-03
|
06 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2009-06-03
|
06 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded by Ron Bonica |
2009-06-03
|
06 | Lars Eggert | [Ballot Position Update] New position, Yes, has been recorded by Lars Eggert |
2009-06-03
|
06 | Lars Eggert | [Ballot comment] Great document overall. Two minor comments: Section 1., paragraph 3: > Note that to ensure full DNS protocol interoperability it is > … [Ballot comment] Great document overall. Two minor comments: Section 1., paragraph 3: > Note that to ensure full DNS protocol interoperability it is > preferred that client stub resolvers should communicate directly with > full-feature upstream recursive resolvers wherever possible. An uppercase SHOULD may be appropriate here to stress that direct communication is preferred. Section 6.1.3.2, paragraph 1: > DNS proxies SHOULD therefore be prepared to receive and forward > queries over TCP. Shouldn't this be a MUST? Under which conditions is it OK to not do TCP? |
2009-06-03
|
06 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel |
2009-06-03
|
06 | Adrian Farrel | [Ballot comment] Easy to read and helpful document. Thanks. Just a small 2119 issue that you should look at along the way. Section 4.1 … [Ballot comment] Easy to read and helpful document. Thanks. Just a small 2119 issue that you should look at along the way. Section 4.1 Therefore it is RECOMMENDED that proxies SHOULD ignore any unknown DNS flags and proxy those packets as usual. I think this is slightly tautological. Change to one of... Therefore it is RECOMMENDED that proxies ignore any unknown DNS flags and proxy those packets as usual. ...or... Therefore proxies SHOULD ignore any unknown DNS flags and proxy those packets as usual. However, subsequent sections use "MUST" to ensure that transparency is achieved, so I'd like to understand why you use "SHOULD". Is it because you do not want to pronounce existing implementations as non-conformant? The use of "SHOULD" begs the question of under what circumstances an implementation MAY drop the packets and what they MUST do when they do that. This pops up again in 4.4.2. |
2009-06-02
|
06 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2009-05-31
|
06 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded by Alexey Melnikov |
2009-05-28
|
06 | Ralph Droms | Placed on agenda for telechat - 2009-06-04 by Ralph Droms |
2009-05-28
|
06 | Ralph Droms | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Ralph Droms |
2009-05-28
|
06 | Ralph Droms | Ballot has been issued by Ralph Droms |
2009-05-23
|
06 | Ralph Droms | [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms |
2009-05-23
|
06 | Ralph Droms | Ballot has been issued by Ralph Droms |
2009-05-23
|
06 | Ralph Droms | Created "Approve" ballot |
2009-05-19
|
06 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2009-05-15
|
06 | Amanda Baber | IANA comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2009-05-13
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Alan DeKok |
2009-05-13
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Alan DeKok |
2009-05-05
|
06 | Amy Vezza | Last call sent |
2009-05-05
|
06 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2009-05-05
|
06 | Ralph Droms | State Changes to Last Call Requested from Publication Requested by Ralph Droms |
2009-05-05
|
06 | Ralph Droms | Last Call was requested by Ralph Droms |
2009-05-05
|
06 | (System) | Ballot writeup text was added |
2009-05-05
|
06 | (System) | Last call text was added |
2009-05-05
|
06 | (System) | Ballot approval text was added |
2009-04-24
|
06 | Cindy Morgan | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he … (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Olafur Gudmundsson DNSEXT co-chair. This version has addressed all issues raised in the working group last call and the document is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes it has. No concerns about quality of review. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? There is no community within the IETF that this document needs more review from. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No issues. (1.e) 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? Real strong (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. Yes, I have checked the document. There is one issues flagged by ID-nits: == There are 1 instance of lines with non-RFC3330-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. I think this is referring to the following text: 231 Should a UDP query fail because of truncation, the standard fail-over 232 mechanism is to retry the query using TCP, as described in section 233 6.1.3.2 of [RFC1123]. In this case the tool can not tell the difference between a section number in RFC1123 and an IPv4 address! (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes references are split. There are no downward references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The document does not require any IANA actions. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Does not apply. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document is aimed at a target audience that is outside the IETF but implement DNS protocol elements, frequently without much understanding of the DNS protocol. This document gives simple guidance to such people to avoid common mistakes, seen in the field, that cause major interoperabilty issues. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The consensus for this document is real strong. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? This is a high quality draft, that is addressing an important aspect for the interoperabilty of the DNS protocol. Number of vendors that purchase/test DNS gateways have stated that compliance with this document is going to be a purchasing requirement. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Document Shepherd is: Olafur Gudmundsson AD: Ralph Droms |
2009-04-24
|
06 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2009-04-23
|
05 | (System) | New version available: draft-ietf-dnsext-dnsproxy-05.txt |
2009-04-15
|
04 | (System) | New version available: draft-ietf-dnsext-dnsproxy-04.txt |
2009-03-03
|
03 | (System) | New version available: draft-ietf-dnsext-dnsproxy-03.txt |
2009-03-02
|
02 | (System) | New version available: draft-ietf-dnsext-dnsproxy-02.txt |
2009-01-06
|
01 | (System) | New version available: draft-ietf-dnsext-dnsproxy-01.txt |
2008-11-27
|
00 | (System) | New version available: draft-ietf-dnsext-dnsproxy-00.txt |