Subject: Other mechanisms for DNS server discovery.

From: Peter Tattam <[email-masked]>
Date: Wed, 23 Jun 1999 13:11:09 +1000 (EST)

As a developer of client TCP/IP stack software, we experience a very common
issue relating to automatic configuration of the client, and that is defining
the DNS server.

While BOOTP/DHCP is the defined protocol for conveying such information, in our
experience it is not the most reliable of solutions as it interacts with other
items such as the IP address and the leasing concept of DHCP sometimes breaks
things.

In light of the fact that DNS is absolutely essential for a working stack these
days and that there are mechanisms built in to IPv6 for automatic address and
network configuration, is there any merit in providing some sure fire way of
seeding a DNS server list for a host with a mechanism that is different from
DHCP?   Perhaps including it in Router advertisements.

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

--------------------------------------------------------------------
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: Craig Metz <[email-masked]>
Date: Tue, 22 Jun 1999 23:34:04 -0400

In message <[email-masked]>, you
 write:
>In light of the fact that DNS is absolutely essential for a working stack thes

  Sending this sort of information in router advertisements is bad. What about
locating printers, file servers, mail servers, web servers, authentication
servers... eventually, the size of "router advertisements" explodes due to all
the baggage.

  There is a service location protocol on the standards track. That sort of
approach -- client goes and looks for services it needs and the network
provides some mechanism for finding the service -- seems to be a better overall
approach.

  There was some talk of using anycasting for this purpose, but I think that a
multicast approach would be better.

									-Craig

---

From: Peter Tattam <[email-masked]>
Date: Wed, 23 Jun 1999 13:39:31 +1000 (EST)

> multicast approach would be better.

I'm open to ideas.  I just felt that DNS was such a special case that it needs
individual treatment.

Peter

---

From: [email-masked]
Date: Wed, 23 Jun 1999 14:22:03 +0900

>multicast approach would be better.

	Some of my folks wished to use anycast address for DNS server (you'll
	write anycast address into /etc/resolv.conf and nearest DNS srever
	will give you the reply).
	But it has been impossible because DNS server cannot reply using
	anycast address in the source...

itojun

---

From: [email-masked]
Date: Wed, 23 Jun 1999 14:50:45 +0900

>Why can't the DNS server send the reply from (one of) its unicast
>address?

	many of the resolvers don't like that (due to security reasons,
	obviously).  also, tcp-based query/reply is impossible.

itojun

---

From: Assar Westerlund <[email-masked]>
Date: 23 Jun 1999 07:49:08 +0200

/assar

---

From: Assar Westerlund <[email-masked]>
Date: 23 Jun 1999 07:58:14 +0200

[email-masked] writes:
> 	obviously).

fix the resolver(s).

>  also, tcp-based query/reply is impossible.

The resolver usually tries first with a udp-based query, getting back
an error if the reply is too large to fit.  Then it knows the
(unicast) address of the name server and can do a TCP query-reply.

/assar

---

From: Masahiro =Rhythm Drive= Ishiyama <[email-masked]>
Date: Wed, 23 Jun 1999 16:15:42 +0900

>>>>> On 23 Jun 1999 07:49:08 +0200, Assar Westerlund <[email-masked]> said:

	That seems to be reasonable, but I think that the querying host
	might want to know that the replying host is really the one that
	the host asked.  The problem is that there is no way to know
	that the source unicast address in the reply is associated with
	the anycast address(the replying host really has the anycast
	address).

masahiro

---

From: Assar Westerlund <[email-masked]>
Date: 23 Jun 1999 09:30:36 +0200

> 	the anycast address(the replying host really has the anycast

Make sure you have the correct data by verifying the SIG records in
the data or with TSIG.  In the first case you can verify that you have
the correct data and you don't care very much about where it came
from.  In the second case you know it's the correct server because it
has the correct key.

/assar

---

From: Peter Tattam <[email-masked]>
Date: Wed, 23 Jun 1999 19:59:09 +1000 (EST)

Interestingly the discussion of this thread heads in the security direction for
later messages.

Also a comment has been made to me privately that DNS is not a special case so
why should it be treated specially.

The implication of the thread delving into the security aspects of DNS
indicates that DNS may actually still be a special case and could well benefit
from having such information conveyed via directly connected routers,  i.e. 
only the next known router can be trusted as having the desired information.
The similarity to ND concepts may not be coincidental to the drive to make sure
that DNS transactions have a level of security attached to them.  Hence my
suggestion that something akin to ND or RA may still be the right place to look
for a solution.

This does not mean that DNS servers should be directly connected, but rather
that the nearest router should be trusted to know where the nearest one is.  It
in turn could use the same mechanism to query it's neighboring routers and so
forth.  Conveyance of reliable and accurate information on DNS servers is
essential to so many higher layer protocols, and I believe that it does deserve
some special treatment.

Peter

---

From: Peter Tattam <[email-masked]>
Date: Wed, 23 Jun 1999 20:18:27 +1000 (EST)

> DHCP?   Perhaps including it in Router advertisements.

As an addendum to this, could I make a gentle hint that some consideration
be given in relation to setting up first time users of the Internet.

Many of us have had years of experience with computers and find many setup
tasks trivial, but the number of people experiencing a computer for the first
time by connecting to the Internet is becoming a more common occurence daily.
You just have to ask my tech support team and they could rattle out story after
story.

I would say that the lion's share of these users would be using the Windows
platform but the representation of developers on this list for that platform is
relatively low.  If you sideline some of the key developers in the process the
only result will be the establishment of proprietary protocols and nobody wants
that to happen. 

Please try to keep this in mind in the design process.  Remember Murphy's Law
works *really* well in the actual ISP world  :)

Peter

---

From: Bill Manning <[email-masked]>
Date: Wed, 23 Jun 1999 10:24:31 -0700 (PDT)

> I'm open to ideas.  I just felt that DNS was such a special case that it needs

	draft-manning-multicast-dns-01.txt

It has a couple of problems and a revison is in the works.

--bill