Subject: Stepping back on the DNS discovery discussion

From: Alain Durand <[email-masked]>
Date: Tue, 15 Jul 2003 00:40:06 -0700

During yesterday's discussion on DNS discovery
we somehow jumped the gun a bit quickly and moved
to solution space without really understanding the requirements.
Let me step back a little and try to reverse engineer those!

A)  Rob, in his introduction, pointed at a number a functions a node 
could
do when we talk about DNS autoconfiguration. Basically those are:
1- finding a recursive name server
2- finding a search list
3- updating the forward DNS tree
4- updating the reverse DNS tree
5- finding a NTP source for DNSsec signature verification

 From this list, it seems to me that 1- is critical, 5- is important
and we could leave without 2, 3, and 5, at least for now.
Those are important (except maybe 2) but can be taken care of 
separately.
However, it is not clear to me that 1- and 5- need to be addressed by 
the same
mechanism. That is, if there is already a mechanism to broadcast NTP
timestamp on the local network, this may be a good enough solution.

B) The second major element to study is the desired/required mode of 
operation.
This autoconfiguration is happening mostly at boot time. I'm a bit 
concerned
about the effects of self synchronization in the network and what happen
when a very large flat L2 network power cycle.
In IPv6 neighbor discovery, there is provision for that, with 
unsolicited router advertisements
that are multicast to all nodes on the link.
If we think that DNS discovery (for lack of a better term) is a 
critical part of stateless autoconfiguration,
it may makes sense for it to have the same properties as  the rest  of 
the story, e.g. prefix discovery.

C) A third element in this discussion is the compatibility with the 
IPv4 model.
I agree it is highly desirable to have the same conceptual 
_administration_ model in IPv6, that
is the information is configured by the network manager in a 
centralized repository and it
then gets propagated to the nodes. This can actually be achieved 
regardless of the
format of the bit pattern on the wire.

	- Alain.

#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Tim Chown <[email-masked]>
Date: Tue, 15 Jul 2003 10:19:06 +0100

> timestamp on the local network, this may be a good enough solution.

Agreed.  I think Mat and Pekka's points are also well made.

> the story, e.g. prefix discovery.

There was certainly a significant hum in this direction in the meeting.
Both DNS Lite and RA discovery methods can exist; each has an application 
domain/scope.

> C) A third element in this discussion is the compatibility with the 

This also links back to the SFO meeting where the WG discussed how answers 
from (potentially) different DHCP and DHCPv6 servers would be handled in a 
dual stack environment.   

But that's the point now - IPv6 stateless DNS discovery is not perceived as 
"missing" because most people use IPv6 in a dual-stack network where IPv4 
DNS resolver info is issued over IPv4 transport by DHCP(v4).  As Mat says,
in new LCNA devices, isn't DHCP(Lite) client support merely for DNS discovery
a little unecessary?   Sure, not all LCNA's will need to resolve DNS, but 
many will.

Tim

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 15 Jul 2003 20:32:51 +0859 ()

Alain;

> to solution space without really understanding the requirements.

OK. What's wrong if microsoft run DNS servers at

	yourdomain.microsoft.com

and preconfigure keys in their OS for dynamic update?

>  From this list, it seems to me that 1- is critical,

Well known anycast addresses are more than enough for 1.

> 5- is important

You should be joking. Where is security?

						Masataka Ohta

---

From: Alain Durand <[email-masked]>
Date: Tue, 15 Jul 2003 05:16:41 -0700

> and preconfigure keys in their OS for dynamic update?

Not sure I understand how your comment is related to this discussion....
could you please clarify?

> Well known anycast addresses are more than enough for 1.

I agree it works (I wrote the draft ;-). The other suggested solution 
works too.

> You should be joking. Where is security?

You need a reasonable clock to verify DNSsec signature.

	- Alain.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 15 Jul 2003 22:39:24 +0859 ()

Alain;

> could you please clarify?

If the requirement is to be registered under some domain, let
vendors provide it.

> I agree it works (I wrote the draft ;-).

And, it needs no new protocol.

> You need a reasonable clock to verify DNSsec signature.

How can you verify the clock reasonable?

							Masataka Ohta

---

From: Brad Knowles <[email-masked]>
Date: Tue, 15 Jul 2003 23:53:57 +0200

At 12:40 AM -0700 2003/07/15, Alain Durand wrote:

>             That is, if there is already a mechanism to broadcast NTP

	NTP can be spoofed.  How can you know whether or not to trust it? 
IMO, that requires some configuration -- either automatic, or manual. 
If the latter, you look in a file that tells you which servers to 
trust.  Even that can be spoofed, unless you use cryptographic 
authentication.  If automatic, then you have to have a way to get 
authoritative configuration information that can be trusted.

	This can be a bit of a chicken-vs-egg problem.  DHCP may or may 
not be the best way to hand out NTP configuration information, but it 
would seem to be one reasonable approach.  I'm sure there are others.

	However, before going too far down the NTP rathole in a WG 
supposedly devoted to the DNS, I would encourage involving other 
contributors from ntp.org in this discussion, especially Harlan 
Stenn.  I'm a contributor myself, but I just run the mail system and 
the mailing lists, and I'm not that intimate with the internals of 
NTP itself.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Bob Hinden <[email-masked]>
Date: Fri, 18 Jul 2003 03:02:03 -0700

Tim,

>Both DNS Lite and RA discovery methods can exist; each has an application

I agree with this view.  I think we should proceed with the RA approach for 
learning the address(es) of the recursive DNS servers and optionally a 
search list.

I think the RA approach has advantages in environments where a DNS (-lite) 
two packet exchanges would be a problem.  I suspect that in many cases the 
addresses of the recursive DNS servers could be in the same RA message that 
prefixes and other link information were contained.  This would be 
significant reduction in traffic as it would avoid any extra packets.

Bob

---

From: Doug Barton <[email-masked]>
Date: Fri, 18 Jul 2003 09:42:27 -0700

Bob Hinden wrote:
> I agree with this view.  I think we should proceed with the RA approach 
> for learning the address(es) of the recursive DNS servers and optionally 
> a search list.

This is exactly the kind of feature creep that bothers me about the RA 
dns discovery approach. The proponents' argument boils down to, "Well we 
have 3 things, so it'll be easy to add a 4th (resolver[s])." The logical 
progression of that is that if you're going to add the 4th anyway, it's 
not really useful without the 5th (search list), and now I've got 
everything else I need, can't I please have the 6th (widget) too? 
Please? Pretty please?

Speaking as a client system implementor, I can almost see situations 
where the RA approach for stateless autoconfiguration of IP mask and 
gateway would be useful. However, by feature creeping RA you're 
basically forcing me to implement two autoconfiguration methods for 
every client, because if RA becomes "just robust enough" there are going 
to be networks where there is no dhcp.

Speaking as a resolving name server/dhcp configurator, I can easily 
imagine situations where the routers are pointed at one set of resolving 
name servers, and I want the clients pointed at a different set. This 
increases the complexity of the RA approach one notch already, and I'm 
just shooting from the hip here. I'm sure others can think of more 
complex problems.

The dhcp(lite) mechanism already exists to do everything that the RA DNS 
discovery could ever imagine doing, plus lots more. It's a scalable 
solution with a known implementation path. I fear that further muddying 
of the water is detrimental to both the long term goal of robust IPv6 
networking, and the short term goal of encouraging IPv6 adoption and 
deployment.

Doug

-- 
Angel:  We need you to distract the vampires.
Buffy:  Right.
Xander: What are you going to do?
Buffy:  I'm going to kill them all. (Walking away)
	That oughta distract them.
   "When She Was Bad" - Buffy the Vampire Slayer, Season Two Episode One

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Jul 2003 13:04:57 +0200

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Bob" == Bob Hinden <[email-masked]> writes:
    Bob> I think the RA approach has advantages in environments where a DNS
    Bob> (-lite) two packet exchanges would be a problem.  I suspect that in
    Bob> many cases the addresses of the recursive DNS servers could be in
    Bob> the same RA message that prefixes and other link information were
    Bob> contained.  This would be significant reduction in traffic as it
    Bob> would avoid any extra packets.

  okay, so we have decided that DNS is *so* much more important than any
other services, that we will put it into the RA.
  Hardly surprising for dnsop :-)

  Do other services out there get space in the RA? 

  Since we have explicitely, no state established, there will be no update
to the reverse - unless one of several other proposal is also accepted. 

]                   At IETF57 in Wien, Austria                  |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] printk("Just another Debian GNU/Linux using, kernel hacking, security guy");[