Skip to main content

DNS Proxy Implementation Guidelines
RFC 5625

Yes

(Alexey Melnikov)
(Jari Arkko)
(Ralph Droms)
(Ron Bonica)

No Objection

(Cullen Jennings)
(Lisa Dusseault)
(Ross Callon)
(Russ Housley)
(Tim Polk)

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

Lars Eggert
(was Discuss, Yes) Yes
Comment (2009-06-03)
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 Former IESG member
Yes
Yes ()

                            
Jari Arkko Former IESG member
(was Discuss) Yes
Yes ()

                            
Ralph Droms Former IESG member
Yes
Yes ()

                            
Ron Bonica Former IESG member
Yes
Yes ()

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2009-06-03)
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.
Cullen Jennings Former IESG member
No Objection
No Objection ()

                            
Dan Romascanu Former IESG member
No Objection
No Objection (2009-06-04)
I support Lars's DISCUSS.
Lisa Dusseault Former IESG member
No Objection
No Objection ()

                            
Pasi Eronen Former IESG member
No Objection
No Objection (2009-06-04)
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.
Robert Sparks Former IESG member
No Objection
No Objection (2009-06-03)
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?
Ross Callon Former IESG member
No Objection
No Objection ()

                            
Russ Housley Former IESG member
No Objection
No Objection ()

                            
Tim Polk Former IESG member
(was No Record, Discuss, No Record, No Objection) No Objection
No Objection ()