DNS Proxy Implementation Guidelines
RFC 5625

[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.

[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.

[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.

[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?

[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?

[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?

[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.

(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