Subject: Comments and questions on dns-discovery

From: Erik Nordmark <[email-masked]>
Date: Tue, 23 Jul 2002 20:57:41 +0200 (CEST)

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-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Wed, 24 Jul 2002 07:55:28 +0900

>on the recursive resolver to do the signature verification.

	i guess it a bit off-topic, i think it is more like AD-bit issue.

	as long as secure channel is maintained between host and resolver,
	it does not make difference, no?  do you think host would configure
	secure channel to untrustworthy resolver?

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 24 Jul 2002 02:16:30 +0200 (CEST)

> 	secure channel to untrustworthy resolver?

The document makes a reference to TKEY as a way to create keys for TSIG.
I certainly don't understand how this works in practice - does it
mean essentially an anonymous DH exchange? If so the host might think
it has a secure channel (using TSIG) with a trusted party when in fact
it has a secure channel with a recursive resolver that it shouldn't
trust.

Has anybody implemented this stuff with TKEY + TSIG?

  Erik