Hi, > -----Original Message----- > From: ext James Carlson [mailto:[email protected]] > Sent: 13. tammikuuta 2011 17:53 > To: Savolainen Teemu (Nokia-MS/Tampere) > Cc: [email protected]; [email protected] > Subject: Re: draft-savolainen-mif-dns-server-selection-06.txt > > > My thinking evolved from DNS search list option defined in RFC3646, > hence using DHCPv6 seemed like a logical choice. > > The two seem quite distinct to me. The existing search list option > provides a global setting for the client, and is intended to affect how > unqualified (or partially-qualified) names are resolved.
Right, but the same information could originally have been designed to be configured through DNS servers. But for some historical reasons, which I am not aware of, DHCP was chosen. In the deployment scenario I could be on right now, the DNS search list option content might almost equal the content of what the DNS server selection option would contain (see Appendix A.2 of our draft). > The new > option > proposed in this draft isn't global; it specifies what domains are > known > or expected to resolve properly with the given server (and/or network > and/or interface; that detail is somewhat unclear to me). Well, DHCP is used to configure both local and global information (and conflicts with "other global information" learned via other interfaces need to be resolved..). > So, operationally, how do I get the DHCPv6 refresh time to line up > usefully with the DNS cache limits, so that I can make changes when I > need to? This is typically easy when modifying the usual sort of SOA > entry, but it's less clear to me when DHCPv6 is in the mix. Is the > administrator for the DHCPv6 server assumed to be the same as for the > DNS system? At least for the deployment scenarios we are looking at you would anyway have to update DHCPv6 with corresponding IPv6 routing information delivery. I.e. if one deploys private names the chances are that those names map to non-globally reachable IP-addresses. I mean if a name maps to a globally reachable IP address, why the name would not be globally resolvable via DNS? About lining up times.. I don't have much experience on network operations, but maybe you could do something like adding the entries to DHCPv6 some time before making changes to DNS, hence decreasing set of hosts that will end up have old information. Hosts that attach through VPN or cellular connections probably do information refreshes quite often. In case of common changes you can also ensure your DNS server is the highest priority default server. > What about nodes that don't use DHCPv6 but do have DNS? It seems to me > that providing information directly to the DNS client about what > domains > ought to resolve is a bit more flexible and independent than vectoring > it through DHCPv6 first. Maybe such nodes would not need advanced multihoming feature at first place, as in that case they would also miss e.g. the routing information option and distributed address selection policies:) Stateless DHCPv6 is fairly simple protocol to implement. > And, though I agree it's a bit out of scope for the IETF, what about > implementation considerations? There'll need to be a new way of > getting > this data from the DHCPv6 client over to the DNS resolver. It seems > simpler if this were just an integrated behavior of the resolver. You mean each time a new DNS server address would be learned by some means (DHCPv6, RA, "well-known", provisioning, manual configuration, L2 means) the DNS resolver would contact said DNS server(s) to fetch new information. Well, either way the DNS resolver must do the DNS server selection based on the information it has obtained by some means. We prefer delivering that information via DHCPv6 at the same time with other configuration information required for multihoming. Btw in the demos we've shown to people at IETF#78 and IETF#79 we used ISC's unmodified BIND running on a host with a small tool creating named.conf dynamically based on the information delivered via DHCPv6. However, it is not possible to have all the features currently described in the draft done with such a setup. For full function the used resolver has to be really modified. > Except that they're distinct, I suppose that's true. DNSSEC protects > the name resolution information, and that's exactly what's at risk if > the list of "official" domains supported is compromised. I didn't follow. If the suffix list is compromised the node may end up sending questions to malicious DNS servers, but as the responses from there will not validate, the node will retry with other DNS servers and should end up talking to someone who does not lie. Or do you refer to a case where only the suffix list would be validated with DNSSEC, but DNSSEC would not be used for actual DNS resolution queries? > > About IPv4 and IPv6. Generally multi-homing for IPv4 is a lost cause > due serious problems caused by overlapping private addresses and > subnets. I will consider IPv4 multi-homing only if really really > necessary. (This reminds me of v6ops discussion about whether IPv4 > should be declared historic and hence no new work (save security fixes) > would need to be done for IPv4 in IETF:) > > I'm not sure I see how names and subnets are so inextricably linked. With that comment I stepped out our of DNS discussion and went to general discussions:) Sorry for confusion. One of the significant reasons (but not the main one) why your favorite handset does not usually do WLAN and cellular at the same time is the fact that it may get same NATted IP address from both network interfaces. That complicates things quite a lot. Also getting this solution into market will take some time, and by that time (at least in cellular domain) IPv4 usage ought to be in the decline. Hence I think we do not necessarily need feature parity between address families for all new features:) This is of course for MIF WG to decide. > The name search problems in the two cases appear to me to be > essentially the same. Yes. > But I do understand the lack of interest in v4, although that's how > this whole conversation's been held. ;-} :) Design of the new technologies is often done with old tools:-) Teemu _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
