I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-dprive-dns-over-tls-07.txt Reviewer: Brian Carpenter Review Date: 2016-03-08 IETF LC End Date: 2016-03-15 IESG Telechat date: 2016-03-17 Summary: Almost ready -------- Minor Issues: ------------- "3.1. Session Initiation A DNS server that supports DNS-over-TLS MUST listen for and accept TCP connections on port 853. By mutual agreement with its clients, the server MAY, instead, use a port other than 853 for DNS-over-TLS. DNS clients desiring privacy from DNS-over-TLS from a particular server MUST establish a TCP connection to port 853 on the server. By mutual agreement with its server, the client MAY, instead, use a port other than port 853 for DNS-over-TLS." Well, that makes my head hurt. I think the only way to relieve the pain is if both of those MUSTs are replaced by "MUST by default". However, that means that both clients and servers need a configuration option to use a different port, and I think that needs to be stated too. "4.1. Opportunistic Privacy Profile ... With opportunistic privacy, a client might learn of a TLS-enabled recursive DNS resolver from an untrusted source (such as DHCP while roaming), it might or might not validate the resolver." This seems rather underspecified to me. How would a TLS-enabled resolver be identified in DHCP? How would it be described in an IPv6 RA (RFC6106)? I would have thought that the natural thing would have been to simply try TLS on port 853, and be happy if it worked. "9. Security Considerations" I hoped to find a comment on interaction between DNS/TLS and DNSSEC, even if the comment is only that there is no issue.