Improved Recursive DNS Server Selection for Multi-Interfaced Nodes
Note: This ballot was opened for revision 09 and is now closed.
(Ralph Droms) Yes
(Ron Bonica) No Objection
Comment (2012-06-20 for -09)
Support Brian's DISCUSS. Please consider rewriting this document. I found it very difficult to parse.
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
Benoit Claise No Objection
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
(Stephen Farrell) (was Discuss) No Objection
Thanks for taking my discuss points into account.
(Brian Haberman) (was Discuss) No Objection
Comment (2012-06-29 for -10)
Thanks for addressing my DISCUSS points.
(Russ Housley) No Objection
Comment (2012-06-15 for -09)
Please consider the editorial comments from the Gen-ART Review by Christer Holmberg on 5-Jun-2012. The review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07482.html
(Barry Leiba) (was Discuss) No Objection
Comment (2012-06-29 for -10)
UPDATE: The -09 version fixes the IANA section and makes Section 4.1 much clearer. I know this took some back-and-forth and some bit of work, so thanks very much for taking the time to do it. I'm also satisfied with the resolution of my non-blocking comments, and thanks for that as well. Comments saved for posterity... ======== These were formerly DISCUSS comments, and have since been addressed; thanks. -- 4.1 -- The resolver MUST NOT prioritize less trusted RDNSSes higher than trusted But two paragraphs earlier, you say this: The RDNSSes of untrusted interfaces may be of highest priority only if trusted interfaces specifically configure low priority RDNSSes. The non- exhaustive list on figure 4 illustrates how the different trust levels of received RDNSS selection information SHOULD influence the RDNSS selection logic. You give a reason for violating that MUST NOT, and Figure 4 has two cases where the less trusted RDNSS is prioritized higher than the trusted one. -- IANA Considerations -- Perhaps this is clear enough for IANA, but I see registries specified without their proper names, so I worry: 1. It looks like the first option code is meant to go into the "BOOTP Vendor Extensions and DHCP Options" registry in the group "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters". 2. It looks like the second option code is meant to go into the "DHCP Option Codes" registry in the group "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)". Please either confirm or correct that and put the *exact* names of the registries in (you can look for them in http://www.iana.org/protocols/ ). That avoids problems for IANA later. ======== Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them: This comment is short of being a DISCUSS, because the document is generally OK and I think I've understood it. I have great respect for the work of the non-native-English editors; still, there are some significant bits that are in sufficiently fractured English as to be hard to read and possibly confusing. I'd like to see the native-English-speaking co-editor (or some other volunteer) go over the document and make sure the articles, tenses, plurals, and commas are right. There's a lot of fixing needed. -- 4.1 -- For security reasons the RDNSS selection information MUST be used only when it is safe to do so, see Section 4.4 for details. This phrasing is easy to misinterpret ("[x] MUST be used"). I suggest casting it more directly: For security reasons the RDNSS selection information MUST NOT be used unless it is safe to do so, see Section 4.4 for details. -- 4.1 -- Trustworthiness of an interface and configuration information received over the interface is implementation and/or node deployment dependent. ...and, I presume, the specification of that trust model is out of scope for this document. I suggest you explicitly say that, before you give the (very good) examples: Trustworthiness of an interface and configuration information received over the interface is implementation and/or node deployment dependent, and the details of determining that trust are beyond the scope of this specification. Trust might, for example, be based on the nature of the interface: an authenticated and encrypted VPN, or a layer 2 connection to a trusted home network, might be considered as trusted, while an unauthenticated and unencrypted connection to an unknown visited network would likely be considered as untrusted. In some situations, an interface might be considered trusted only if it has been explicitly configured to be. I remind you that "shall" is a 2119 keyword (synonymous with "must"), and you should be cautious in using it casually. If a DNS response is not proven to be unmolested using DNSSEC, then a node cannot make a decision to prefer data from any interface with any great assurance: any response could be forged, and there is no way to detect the forgery without DNSSEC. First, this is a convoluted sentence, with too many negatives; second, you're burying the lede. The important point here is that DNSSEC is necessary, so put it up front: DNSSEC is necessary to detect forged responses, and without it any DNS response could be forged or altered. Unless the DNS responses have been validated with DNSSEC, a node cannot make a decision to prefer data from any interface with any great assurance. -- Figures 5 and 6 -- Reserved: Field reserved for the future. MUST be set to zero. It would seem to be useful for those future applications if we made sure that implementations didn't barf on receipt of some future value here. Would this work?: Reserved: Field reserved for the future. MUST be set to zero; MUST be ignored on receipt. -- Figure 8 -- Does this diagram tell me anything useful? If so, I can't figure out what. The only interesting part is in the "black box". -- 10.2 -- An implementation may not be able to determine trust levels without explicit configuration provided by user or administrator. OK, if you're going to go there, I have to: do you really think there's any serious possibility of user configuration here, especially in the case of a home-network user? I think that if you mention user configuration, you have to mention that in many, if not most, scenarios, user configuration is not a realistic possibility, and administrator configuration and policy heuristics are usually the only viable mechanisms. ======== Other comments; no need to respond to these. Take them or modify them as you please: "timeout" should be one word, not two (but "timed out" is, correctly, two). -- 4.1 -- The resolver SHOULD avoid sending queries over different network interfaces in parallel as that wastes resources such as energy. The amount of wasted energy can be significant, for example when radio interfaces has to be started just for the queries. Maybe it's just an artifact of where the page break happened, but I wondered what the "energy" thing was until I saw "radio interfaces" (on the next page). I suggest using "power" rather than "energy", and specifically noting battery-powered and constrained environments. Perhaps this: The resolver SHOULD avoid sending queries over different network interfaces in parallel as that wastes resources such as power (in the case of battery powered and constrained environments). The wasted power can be significant: consider starting multiple radio interfaces just for parallel DNS queries.
(Robert Sparks) (was Discuss) No Objection
Thanks for addressing the majority of the points I raised. Please consider the one remaining (this is not blocking - if you choose to do nothing it's up to you): You added text discussing what the effect on a local cache would be when an interface was removed. Should you say something about what happens if the relative priority of interfaces change? (Or are you perhaps thinking that would be the same as removal of an interface and addition of a new one?)
(Martin Stiemerling) No Objection
(Sean Turner) (was Discuss) No Objection
Comment (2012-06-21 for -10)
I agree with Robert and Stepehen's discuss positions. 0) s1: Includes the following: The node ought to be able to ask right RDNSS for the information it needs. by "right" you mean the RDNSS that holds the data that's been asked for even if it's private. how about: The node ought to be able to query the RDNSS that can resolve the query regardless of whether the answer comes from the public DNS or a privte namespace. 1) s2.2: r/It is worth noting is that/It is worth noting that 2) s3.1: r/instead CPE should send/instead CPE need only send 3) s3.3: r/should be send/need to be sent r/network may be used./network may be used for all other traffic. 4) s4.1: I tend to agree with Stephen here. I think what you want to say is that the specific procedures here are non-normative but an implementation must end up wit h the same result. Pseudocode would help tremendously. Avoiding using lowercase may, shall, should, and must would also help. 5) s4.1: When you say precedence are you saying that the higher precedence should cause processing of lower precedence ones to be stopped or is this just about picking the next value to process? 6) s4.1: priority or precedence pick one ;) 7) s4.2: r/should be contacted/can be contacted 8) s4.2: r/MAY then/can then 9) s4.2: r/extent/extend 10) s4.2: OLD: In the case of conflicting RDNSS address is learned from less trusted interface, the node MUST ignore the option. NEW: When a conflicting RDNSS address is learned from less trusted interface, the node MUST ignore the option. 11) s4.4: Agree with Stephen's discuss #3.