On 01/14/11 07:06, [email protected] wrote:
>> 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.
Possibly. I believe that when the DNS resolver portion of this was
being designed, it was assumed that choice of a default domain for
unqualified names was a local matter -- one system administrator might
choose one, and another might choose a different one. So, it was just a
local configuration option rather than a part of the DNS server.
As yet another local configuration option that could be centralized, it
got swept up into a DHCP option, and there we are.
I believe these two -- search lists and served domain lists -- are
qualitatively different. Having hints that a particular DNS server is
good for particular queries is quite different from knowing that the
simple name "foobar" should be resolved as "foobar.example.com."
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.
> 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).
I don't think that's generally true, though I can see how it might be
true in some cases.
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.
>> 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..).
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.
This new information is quite different, because it's *per* DNS server.
Each server has a different string that specifies what it will resolve.
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.
>> 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?
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.
At least with the large networks where I have some experience, the folks
handling routing are completely separate from the ones handling name
services. In fact, they're even employed by different companies.
> 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.
I don't think I follow that, because I'm not sure I see how priority
works into the prefix/suffix lists used for DNS server selection.
>> 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.
Indeed; it's not difficult. But is it operationally necessary?
>> 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.
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. ;-})
> 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.
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.
>> 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?
I don't think that's complete.
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.
In that case, it doesn't matter whether there are any malicious DNS
servers. In fact, there might not be any at all.
And my malicious DHCPv6 server won't bother with the refresh option, so
the client is nailed until he manually restarts.
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?
Or should the resolver somehow "know" whether the DHCPv6 information is
"secure," for whatever "secure" means? And how would it know that the
information is as valid as the DNSSEC information?
>>> 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.
Nah, the main reason is that my favorite handset is a plain old phone.
It barely does SMS, let alone fancy data. ;-}
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.
--
James Carlson 42.703N 71.076W <[email protected]>
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
