> To put it another way, if I hear through this new mechanism that some > DNS server will handle requests for "example.com.", that does *NOT* > imply in any way that I want bare names to be resolved by that server > preferentially. Perhaps I do -- but perhaps I don't. That's what the > search list is for.
You can ignore the option and talk to the DNS server of your preference. You can also choose to listen for the option only from one or more trusted sources. > One of the things this draft addresses is the problem that when a > multi-homed client receives multiple DNS server addresses, it doesn't > know where to send the queries. This solution fixes that problem by > providing clues about direction. But merely knowing where to send a > full query does _not_ tell the client what domains it should assume > when only a simple name is given. A bare name would unlikely find match from the suffix list. You could ask resolution for the bare name from your favorite default. After appending the bare name with some suffix from your search list you could look for match from DNS server selection list. Of course there could be multiple search list from different interfaces. In such case you could prioritize the search lists by some means and start walking through the suffixes when resolving bare name. > > 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..). > > I don't know of any information provided by DHCP that's "local" in the > sense that you're saying. > > The DHCP information concerning the IP addresses of DNS servers is > "global" in the sense that the client system's resolver can use it to > form a list of servers to query. There's just one list required. >From my viewpoint DNS server address is a perfect example of local >information, which is valid only on the interface it was learnt on (rarely you >can contact DNS server via other interfaces). The host of course may put these >pieces of local information in a form of global list to go through, but that >list then easily becomes an interface preference list and *essentially* host >chooses first the interface to use and then DNS server from there (assuming IP >packets to DNS server are sent over the interface DNS server address was >learnt). > A case that illustrates how different these things are would be one > where the DHCPv6 server provides the IP addresses of two different DNS > servers. > > There'd still be just one search list to contend with. And one list of > IP addresses for the DNS servers. But you'd need to have two of these > selection lists -- one for each of the DNS servers to describe what > domains each server is able to resolve. Would you rather prefer DHCPv6 option that does not specify DNS server addresses, only suffix list? I.e. in that case the suffix list would be interface specific? That is something we could discuss about. > Any of a number of situations can cause that. Some networks have areas > that don't resolve "outside" the area for testing or security-related > reasons. But the IP addresses of the services pointed by names remain globally reachable? > The algorithm used by the resolver might be something like: > > resolve_name(name): > if "name" is cached and unexpired: > just return that > for each known server address: > if server has unexpired domain-list and "name" matches: > try this server; return on success > for each known server address: > if no cached domain-list entry or entry is expired: > query server for domain-list and cache result > for each known server address in priority order: > if no domain-list or if "name" matches list: > try this server; return on success > > It's similar to the algorithm required for this draft, except that it > has logic to refresh the domain lists when necessary. (That's off the > cuff; I'm sure a good designer with more time could do a better job. > ;-}) This sounds quite like what we have, except that domain-list is fetched with DHCPv6 and not on-demand as shown above (and also DNSSEC to validate before declaring success). > Sure; both my suggestion and yours require resolver modifications. And > neither one actually requires changes in the DNS server. > > The draft, though, does require DHCP changes. Well, trouble to add new option to DHCP config files is not a big challenge. I used ISC's DHCPv6 server and it supported custom options - the option content was easy to write to dhcp config. On the client side, be it resolver or dhc client, they need to modify asking of the information. In the case of DHC that was easy as well. > If I have a malicious DHCPv6 server, I can set up a prefix/suffix list > for one of the valid DNS servers that says that server doesn't handle > any domain I want, including the default "." domain. If this is done, > then the resolver will never attempt to query the "right" server. You mean attacker could use DHCPv6 on one interface to remove/disturbing DNS information learnt on other interfaces? That is part of conflict resolution: more trusted interfaces should take precedence (and e.g. on WLAN hotspot filled with hacker you might not even want to query this option). > Or are you saying that there are cases where the resolver should just > ignore the prefix/suffix list from DHCPv6, and should send out queries > to servers it doesn't think can answer them, just in case the list is > wrong? The draft talks about walking through available DNS servers and trust levels of interfaces. The host may always ask other servers if the one preferred does not yield answer. After all, many IETF people seem to be happy for sending queries to all DNS servers of all interfaces always:-) Anyway, we could have it also so that if the most preferred DNS server does not give positive validatable reply in half a second the node resends the query out on all interfaces to all DNS servers like a lightning storm. That would ensure the common case does not require DNS storming, but in case of trouble the user experience would remain good. > I understand that problem. I think what you're really saying is that > you want nothing to do with NATs (and the implications of them), and > since NATs are common with v4 and not with v6, you're doing v6-only. That's mostly true, but I do fancy properties made possible by the large address space that are not possible in public IPv4 (or were, if people were given large chunks of IPv4 addresses:). Best regards, Teemu _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
