[email protected] wrote: > Hi James, > > 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. 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). But, ok, I see the motivation. > Additionally collecting information required for multi-homing configuration > into one place (DHCPv6) seemed useful: this option, DHCPv6 Route Option > (draft-ietf-mif-dhcpv6-route-option), and Distributing Address Selection > Policy using DHCPv6 (draft-ietf-6man-addr-select-opt). I.e. single point of > control but different point than what you propose below. DHCPv6 can also > support node specific configurations. > > Addition of information refreshing considerations is a good proposal. The > RFC4242, "Information Refresh Time Option", can be utilized for this purpose. > Well include considerations of this. OK. 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? It still seems quite a bit more complex to use in practice than the alternative I suggested. 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. 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. I suppose the one positive attribute of the DHCPv6 scheme I can see is that (in many implementations) the data would be forced into a configuration file or database somewhere, and that would promote caching and reuse. (Though with the usual concerns about timeliness of the information, RFC4242 notwithstanding.) > About packet integrity protection.. I have thought the same level of > integrity protection we have for other DHCPv6 configuration options would > suffice. 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. > 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. The name search problems in the two cases appear to me to be essentially the same. But I do understand the lack of interest in v4, although that's how this whole conversation's been held. ;-} -- James Carlson 42.703N 71.076W <[email protected]> _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
