Comments on draft-ietf-ipv6-dns-discovery-05.txt
The mechanism described here is to be used as a last resort, when no
other configuration information is available.
Does this mean that implementations of this mechanism MUST also
implement another mechanism, such as DHCP, for discovering the DNS
servers?
If not, the above words have little practical meaning since an
implementation which only supported this mechanism would be compliant;
the mechanism would be the "only" resort i.e. both the first and last resort.
-a) Using a site local prefix will ensure that the traffic to the
DNS resolver stays local to the site. This will prevent the DNS
requests from accidentally leaking out of the site. However, the
local resolver can implement a policy to forward DNS resolution of
non-local addresses to an external DNS resolver.
This assumes that the site boudary is (correctly) configured.
My understanding from the scoped addressing architecture is that
by default all interfaces on a node are considered to be part of
the same site. Therefor some explicit configuration is needed to
make a node be at a site boundary.
Is the assumptions that vendors of e.g. "home gateways" will by default
treat the "home" as a separate site? Or is the assumption that the
user will configure this boundary?
The customer router CPE could be configured on its internal interface
with one of the reserved site local addresses and listen for DNS
queries. It would be configured to use one (or several) of the well
known site local unicast addresses within the ISP's site to send its
own queries to. It would act as a DNS forwarder, forwarding queries
received on its internal interface to the ISP's DNS resolver.
I assume this "forwarder" (a term which might be in common use but not
well-defined, hence my stated assumption) merely receives DNS queries
on one address and sends the identical queries to another address,
and likewise for responses. Presumably such a box needs to track
the pending queries in order to be able to return the responses to
the correct address.
If such a box doesn't do anything more than the above, this has implications
on the trust model for DNSSEC. For instance, it might make some sense
to have hosts trust a local DNS resolver to verify DNSSEC signatures,
use a secure channel between the host and the resolver, and look
at the DNS "AD" bit to determine that trusted resolver accepted
the signatures on the data (see draft-ietf-dnsext-ad-is-secure).
However, such a host might not trust the resolver external to the site.
And the use of a "forwarder" here seems to imply that the host thinks
it is talking to a resolver inside the site, when in fact it is using
a resolver outside the site. This trust issue is not discussed in
the draft and it clearly requires more thinking.
Perhaps a result will be that any host using this DNS discovery mechanism
MUST perform full verification of DNSSEC signatures and not rely
on the recursive resolver to do the signature verification.
Erik
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
