DNS Proxy Implementation Guidelines
draft-ietf-dnsext-dnsproxy-06
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.
Alexey Melnikov Former IESG member
Yes
Yes
()
Unknown
Jari Arkko Former IESG member
(was Discuss)
Yes
Yes
()
Unknown
Lars Eggert Former IESG member
(was Discuss, Yes)
Yes
Yes
(2009-06-03)
Unknown
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?
Ralph Droms Former IESG member
Yes
Yes
()
Unknown
Ron Bonica Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2009-06-03)
Unknown
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
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
(2009-06-04)
Unknown
I support Lars's DISCUSS.
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
No Objection
No Objection
(2009-06-04)
Unknown
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)
Unknown
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
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was No Record, Discuss, No Record, No Objection)
No Objection
No Objection
()
Unknown