Date: Wed, 16 Oct 2002 13:59:59 -0400
From: Margaret Wasserman <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| I think that it should be required (a MUST) that nodes that
| implement this specification provide a method to override the
| default values manually.
If the doc is to remain at all, then yes, and as Brian hinted, "manually"
is not important there.
| The document should also specify whether the default DNS addresses
| will or won't be considered part of the DNS server list when DNS
| server addresses are configured via other means. For example, if
| a host receives a single DNS server address via DHCP, will it
| fall-back to using these well-known addresses if the DNS server
| at the DCHP-configured address fails to respond?
This all boils down to what is "last resort" which the doc doesn't
really go into.
I'm not absolutely convinced this is crucial, that is, that it doesn't
necessarily matter if everyone does this the same way or not.
What's clearly in issue here is how a new out of the box IPv6 node finds
some back end resolver to handle its DNS queries, as without that, it is
useless.
After having found some way to make DNS queries, the question is really
no longer important - if we get a list of DNS resolvers via DHCPv6 (say)
and they're used, then the node is now operable. If those servers all
go away/fail (and DHCPv6 hasn't, yet anyway, told us of new ones) then
whether the node falls back to trying the well known addresses or not,
is really just a question of user desire. Some users will just see packets
being sent to nowhere, and increased timeouts while the app waits for the
reply that will never come. They won't want the well known addresses used.
Others would see the resolver giving up after its DHCPv6 address(es) have
failed, and wonder why the node didn't just go on and try the well known
addresses which have been carefully set up to provide the service. Those
people will want the well known addresses retained. (If it really was
DHCPv6 in that case then one could argue the DHCP server should have just
included the well known addresses, but the "normal" back end resolver may
have been learned via some other mechanism which cannot as easily just
supply many addresses that way).
| Listing anything as a "last resort" is problematic, because there
| may be something that comes along later that should only be
| used if this fails.
I think this is partly a lack of defining "last resort of what".
That is, I didn't think it was really intended to be "last resort of
doing a name resolution" but "last resort of configuring addresses
of back end resolvers that could be used to do name resolution".
That is, this "last resort" is used at boot time only, when some
initial configuration must be found.
Or that's my impression of what it means. But it isn't very precise.
| Instead, I would like to see this document
| explicitly define how this mechanism does/doesn't interoperate
| with other mechanisms (DHCP, SLP, manual configuration).
That would be a reasonable idea.
| In my opinion, this section points out one major weakness with
| this approach. We _still_ need some way to configure the location
| of DNS servers in the network...
Yes. This scheme isn't really all that useful.
| Today, we do that on hosts (often
| using DHCP to provide the information, effectively moving the
| configuration to the DHCP server). This draft proposes moving
| that knowledge off of hosts and DHCP servers, and into the routing
| system, but it doesn't actually specify how the routing system
| will get the information.
I don't think that's a serious problem either. Clearly something needs
to be configured somewhere (unless the model is that every node is to be
its own back end resolver, and will come pre-set with the root server
addresses as a place to start - and I certainly hope that's never what
happens).
At the very least, some node needs to be configured as the back end
(recursive) resolver. A little extra config to inform routing where that
node lives isn't too much to expect really. It's still config on the
order of the number of DNS back end resolvers (1, 2, or 3 or so), not of
the order of the number of nodes connected to the network.
The truly big problem with this draft is that it is usurping address
assignments that have already been made elsewhere (I'll reply to a
different message and make that point - once more).
kre
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
