IPv6 Host Configuration of DNS Server Information Approaches
Note: This ballot was opened for revision 06 and is now closed.
(Harald Alvestrand) Discuss
Discuss (2004-11-17 for -)
I think this document should have pointers to various other docs describing work we have done with anycast addresses. An IESG note may be appropriate; I've suggested one on the IESG list.
Comment (2004-11-17 for -)
A number of sentences are missing a "the" according to my sense of English, but are nonetheless clear. I found the explanation of the anycast option difficult to follow. Reviewed by Joel Halpern, Gen-ART. His review: This draft is basically ready for publication as an Informational RFC, but has nits that should be fixed before publication. There is one item that I think needs clarification before publication. Specifically, I found one aspect of this document confusing. In discussing the use of well known anycast addresses for the recursive DNS server, several things are stated. One is that the Host can be pre-configured, possibly by the factory, with the suitable address. The other is that multiple servers may have distinct anycast addresses. "Redundancy by multiple RDNSSes is better provided by multiple servers having different anycast addresses than multiple servers sharing same anycast address... I do not follow how the hsot can be pre-configured with the anycast address when there different anycast addresses in use. Can this really be describes as "a well known anycast address"?
(David Kessens) Yes
Comment (2005-03-30 for -)
Comments from David Kessens: The WLAN discussion is problematic. First problem is that there is no definition of what WLAN actually is (802.11a/b/g perhaps ?) and secondly because the problems that 802.11a/b/g supposedly has in the RA context can be considered as a general RA issue that is not related at all to adding the DNS option. Specifically, if one already uses route advertisements over a WLAN anyways, I cannot see why adding a DNS option would really make things worse. More appropriate wording would be something like: 'The RA option solution might not work very well on a congested medium that uses reliable multicast for RA'. actices, but provides no analysis of the security implications of multihoming. Comments received from Iljitsch van Beijnum <email@example.com> (13 Oct 2004 10:45:15 +0200): This message is mostly the same as one I posted to the wg list yesterday. See that one for an additional list of smaller nits. First a side issue. Under the ND approach there are remarks about multicast difficulties in wireless environments. There is some additional talk about multicast in wireless environments in an appendix, but this discussion doesn't capture the real-world complexities that exist here (and that DHCP also uses multicast but the issue is very different there). The pertinent information has been discussed on the list so including it shouldn't be too hard, or maybe a spin-off informational RFC would be appropriate. Also note that there isn't much of a real-world issue: ARP in IPv4 also works, while it suffers from the same broadcast/multicast problems as IPv6 neighbor discovery. More to the point, two very important issues are missing. The first is that we are living in 2004. If this were 2001, we could simply identify the best approach and standardize it. However, IPv6 is already widely implemented in hosts and deployment is growing. The lack of a recursive resolver configuration mechanism is felt every day. If we select an approach that needs considerable implementation effort, it can be as much as two years before this approach is actually available to users. The worst choice in this regard would be the RA approach. While in itself this is a very good approach, it suffers from the fact that both routers and hosts must support it before it can be used. Implementation cycles vary widely throughout the industry, but it's safe to say that anyone who doesn't use both routers AND hosts with the shortest implementation cycle will have to wait at least until 2006 before an RA approach could conceivably be available. The DHCP approach has the advantage that it can be implemented on special purpose servers rather than having to be implemented in routers. Some systems use a very simple mechanism to configure recursive resolver addresses, and on those systems it's very easy to add a userland DHCP client daemon that handles this task. However, on widely used systems such as Windows and MacOS X reconfiguring recursive resolvers isn't something that can be easily done by a userland program. Realistically, users will have to wait until Microsoft or Apple bundle support for DHCPv6 in their products. Again, this is likely to take a significant amount of time. The well-known address approach on the other hand, can be deployed pretty much immediately. The only thing that's needed is for IANA to register a set of addresses and within weeks these addresses would be usable by any IPv6 implementation that supports DNS queries over IPv6 transport. The second issue is security. One thing that bothers me about a DHCP-only approach is that it requires networks that have otherwise no interest in DHCPv6 to run DHCPv6 servers and clients. Past experience shows that complex UDP-based protocols are often implemented insecurely. So an approach that doesn't require additional protocols would be preferable from a security standpoint. (And from management and debugging standpoints as well.) Both DHCPv6 and RA have an inherent security problem because the host is supposed to trust information that comes in from unknown sources. This makes it very easy for an on-link attacker to present itself as a legitimate DHCP server or router and provide clandestine configuration information. I believe efforts are underway to remedy this situation, but again, it will be some time before most clients will be able to use these new mechanisms in practice. In the mean time having recursive resolver information be available over insecure DHCP or RA means that attackers gain an additional attack vector. (And heavy crypto doesn't exactly go hand in hand with autoconfiguration, it remains to be seen how well this is going to work in practice for nomadic users.) Last but not least, not about the draft but about the decision that needs to be made: it worries me that this issue hasn't been resolved earlier. I believe one of the main reasons for this is that the DHCP proponents are blocking consensus on the other approaches in order to arrive at the situation where everyone implements DHCP and the issue becomes moot. Note that there are several IPR claims on parts of DHCP that may or may not apply here, adding insult to injury for those who don't want to run DHCP in the first place. The only way to overcome this abuse of the IETF process is for the IESG to recognize the lack of consensus and decide on the issue itself. Iljitsch van Beijnum --- Comments from the ops directorate (Mar 30 17:21:11 PST 2005): 1. The document would benefit from a grammar edit. Rather than requiring the RFC Editor to do this work, I would prefer to see documents correct grammatical mistakes prior to submission to the IESG. 2. The security considerations section (6) does not describe the security implications of each approach. This is important because the approaches have different security implications. For example, the RDNSS approach would utilize SEND for security, which implies that the client has a trust anchor configured, and the server signs RA messages. On the other hand, the DHCPv6 approach would utilize DHCPv6 security, which has a different trust model. The anycast approach does not require configuration security, since there is no protocol. 3. This document does not address the implications of DNS configuration approaches on the use of link-local DNS resolution, such as mDNS and LLMNR. For example, where a DNS server is not available, in the RDNSS or DHCPv6 case no DNS server is configured, and link local name resolution will be used exclusively without DNS queries being sent. However, in the anycast case, DNS queries will be sent, and if not answered, DNS clients may agressively retransmit. Linklocal name resolution will only take place once they time out. The difference is particularly important for dual stack hosts residing on IPv4 native networks, where the anycast approach could result in persistent (and unnecessary) DNS traffic.
(Steven Bellovin) No Objection
Comment (2004-10-26 for -)
The Security Considerations section should be updated to mention DNSsec; if it is used -- and the signatures verified on the client host -- misconfiguration of a DNS server is simply denial of service.
(Brian Carpenter) No Objection
Comment (2005-03-27 for -)
Removing Harald's discuss - fixed by new version
(Margaret Cullen) (was Discuss, No Objection) No Objection
(Ted Hardie) (was Discuss) No Objection
(Sam Hartman) No Objection
Comment (2004-11-12 for -)
I'd like to echo Steve's comments about dnssec. This document should discuss it in the security considerations section. Also, the text in that section about autoconfiguration is misleading in the far long-term. Configuration of root keys might be acceptable in many environments where configuration of other state would be unacceptable. I realize this is not an option today. I disagree with Iljitsch van Beijnum that the anycast approach is more secure. It seems that it would suffer from the same sort of on-link attacks as the RA and DHCP approaches.
(Scott Hollenbeck) No Objection
(Russ Housley) No Objection
(Mark Townsley) No Objection
(Bert Wijnen) No Objection
Comment (2004-11-18 for -)
$ findref draft-ietf-dnsop-ipv6-dns-configuration-04.txt !! Missing citation for Normative reference: P020 L013:  S. Bradner, "Intellectual Property Rights in IETF Technology", !! Missing citation for Normative reference: P020 L016:  S. Bradner, "IETF Rights in Contributions", RFC 3667, February $ idnits-v1.47 draft-ietf-dnsop-ipv6-dns-configuration-04.txt idnits 1.47 (02 Nov 2004) draft-ietf-dnsop-ipv6-dns-configuration-04.txt: The document seems to lack an IANA Considerations section Checking conformance with RFC 3667/3668 boilerplate... The document seems to lack an RFC 3667 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Warnings: There are 18 instances of lines with hyphenated line breaks in the document.
(Allison Mankin) No Record
Comment (2004-11-18 for -)
This is a ridiculous form of rhetorical argument: Therefore, if ND supports the configuration of some additional services, such as DNS, NTP and SIP servers, ND should be extended in kernel part, and complemented by a user-land process. There would be immediate architectural and SIP pushback against adding SIP to ND, so using this as a whipping boy is ridiculous, and probably shows a negative technique under way here.