DNS Proxy Implementation Guidelines
RFC 5625

Note: This ballot was opened for revision 06 and is now closed.

(Jari Arkko) (was Discuss) Yes

(Ron Bonica) Yes

(Ralph Droms) Yes

(Lars Eggert) (was Discuss, Yes) Yes

Comment (2009-06-03)
No email
send info
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?

Alexey Melnikov Yes

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Pasi Eronen) No Objection

Comment (2009-06-04 for -)
No email
send info
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.

(Adrian Farrel) No Objection

Comment (2009-06-03 for -)
No email
send info
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.

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Tim Polk) (was No Record, Discuss, No Record, No Objection) No Objection

(Dan Romascanu) No Objection

Comment (2009-06-04 for -)
No email
send info
I support Lars's DISCUSS.

(Robert Sparks) No Objection

Comment (2009-06-03 for -)
No email
send info
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?