Subject: Re: dns server discovery using mdns

From: Bill Woodcock <[email-masked]>
Date: Tue, 1 May 2001 03:06:18 -0700 (PDT)

> > Woody's example of why mDNS was needed was if two PDA's want to beam stuff
    > > to each other but use IP-over-IRDA rather than something proprietary.

    > Why would two isolated pdas wanting to beam stuff to eachother,
    > regardless of transport mechanism, need to resolve lcs.mit.edu?

Sorry. Like Kibo, I'm ill-advisedly jumping in mid-thread without having
gone back and read everything that led up to it, but...

Yes, I think that PDA or laptop users need to be able to talk to each
other in an ad-hoc environment, their users saying "Hi, my machine is
palm.fooco.com, go ahead and ftp to me."  What I _really don't like_ is
the idea that this should use a substantially _different mechanism_ than
looking up lcs.mit.edu.  I don't like the idea that a host should have
different name resolution mechanisms, and have to be constantly deciding
which to use, based on external environmental changes.

I'll shut up and read the rest of the thread now.

                                -Bill

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Randy Bush <[email-masked]>
Date: Tue, 01 May 2001 12:09:46 +0200

> which to use, based on external environmental changes.

then parallel logic says you should have great sympathy with my not wanting
to creatr a substantially different mechanism for finding the dns server
than we already have, dhcp.  <giggle>

randy

---

From: Robert Elz <[email-masked]>
Date: Tue, 01 May 2001 17:32:59 +0700

Date:        Tue, 01 May 2001 12:09:46 +0200
    From:        Randy Bush <[email-masked]>
    Message-ID:  <[email-masked]>

  | then parallel logic says you should have great sympathy with my not wanting
  | to creatr a substantially different mechanism for finding the dns server
  | than we already have, dhcp.  <giggle>

The problem is that we currently have two mechanisms for finding the DNS
server.   One is DHCP.   The other is manual configuration.

The first only works if you have a local "number czar" who controls the
DHCP configuration, knows everything, and lists all of the correct numbers
to hand out to clients.   Otherwise you have the problem of how does the
DHCP server discover where the DNS server is to be found?

So, what is left is just manual configuration, and that one is looking less
and less attractive as a configuration mechanism into the future.

Whether the scheme proposed is really the right solution to the problem
I'm not sure yet, but I am fairly convinced that we do need something new.

kre

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 01 May 2001 14:12:52 +0200

--On 01-05-01 03.06 -0700 Bill Woodcock <[email-masked]> wrote:

> looking up lcs.mit.edu.

I don't know if I as a layer 7 person want to jump in and tell people I
read things on this list, BUT...

I think Bill is having a wish for a client which want to use a service want
to find the service on an IP based network without any pre-configuration at
all.

This has nothing to do with DNS, more than Bill saying that "I don't want
this service to be different than looking up foo.example.com".

When talking with Bill, it sounded like he want to do an IP-based version
of the NBPLookup call in AppleTalk, which could be done over multicast of
course, and it doesn't have to be a DNS query, and it doesn't have to be a
DNS response.

Am I right Bill?

What have the zeroconf guys been doing lately?

Is querying over multicast for available services a bad thing?

I don't think so, but I ask myself whether this is DNS. I don't think it is.

   paf

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 1 May 2001 07:08:36 -0700 (PDT)

> course, and it doesn't have to be a DNS query, and it doesn't have to be a

Yes.  That idea has been proposed a few times, just reimplementing
NBP-over-IP, but that winds up being a whole new protocol, and then you
don't pick up the zillion ancillary benefits of using actual DNS.

Yes, I want to get rid of AppleTalk.  But no, I don't want to get rid of
it so badly that I'm willing to give up on being able to use real DNS
instead.

                                -Bill

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 1 May 2001 07:42:17 -0700 (PDT)

> than we already have, dhcp. 

I see your point, however finding the nameserver has really never been my
interest.  I'm interest in finding resources generically: laser printers,
file-sharing peers, et cetera.  I think we'd all agree that DHCP isn't the
way to find a laser printer, nor an ad-hoc file-sharing peer.  And I think
one would be hard-pressed to find a clear justification for not using DNS
for that purpose.  Given that DNS is the appropriate means of finding
resources, the question is whether we want to have divergent versions of
DNS, or one way of using DNS, and I'm very much for the latter.

                                -Bill

---

From: Robert Elz <[email-masked]>
Date: Tue, 01 May 2001 22:48:21 +0700

Date:        Tue, 1 May 2001 07:42:17 -0700 (PDT)
    From:        Bill Woodcock <[email-masked]>
    Message-ID:  <[email-masked]>

  | I think we'd all agree that DHCP isn't the
  | way to find a laser printer,

Probably not, but it does have the impress printer location option...

  | And I think
  | one would be hard-pressed to find a clear justification for not using DNS
  | for that purpose.

Actually, not even slightly pressed.   That isn't what the DNS is useful
for at all.   If you know what your printer (or file server) is called,
then the DNS is great for translating that into an address so you can
reach it.   But for the appletalk like "what laserwriters are out there
that I might be able to print on?   Oh yes, that's the one I should use"
it is totally useless.

Svrloc is (was?) supposed to be the protocol for that kind of function.

  | Given that DNS is the appropriate means of finding resources,

It isn't.

However, that doesn't negate the problem of locating a DNS server given
no configuration (anywhere).   Or more likely in a case like this (the
thing the node is more likely to want to find) - a DNS back end resolver.
That is, something that will do DNS lookups for me.   Given that, and
some way to figure out my own domain name, then I can find the actual DNS
servers using the DNS (on the off chance I should happen to need to know
them).

kre

---

From: "Richard Barr Hibbs" <[email-masked]>
Date: Tue, 1 May 2001 09:34:50 -0700

Robert--

(with tongue firmly planted in cheek) I just knew that someday someone (like
yourself) would find a reason to use this option, thus shooting down in
flames my proposal to sunset it.....

> Probably not, but it does have the impress printer location option...
...but I do agree completely that DHCP was not really intended to answer the
generic question of what resources are available to a client, while SRVLOC
really was....

>   | And I think one would be hard-pressed to find
>   | a clear justification for not using DNS
>   | for that purpose.
>
> Actually, not even slightly pressed.  That isn't what
> the DNS is useful for at all.   If you know what your
> printer (or file server) is called, then the DNS is
> great for translating that into an address so you can
> reach it.   But for the appletalk like "what
> laserwriters are out there that I might be able to
> print on?   Oh yes, that's the one I should use"
> it is totally useless.
>

...this presupposes the existence of several different types of servers
(DHCP, DNS, SRVLOC, and maybe some TFTP servers for things like PXE
configuration) when what is needed is closer to ZEROCONF.  My own bias is to
simplify rather than increase the number and types of data stored by
different servers to answer client requests, and to develop a robust
mechanism for self-configuration in the absence of these servers.

--Barr Hibbs
  UltraDNS Corporation

---

From: Randy Bush <[email-masked]>
Date: Sat, 05 May 2001 08:16:52 -0700

> I think we'd all agree that DHCP isn't the way to find a laser printer

i suspect the dhcp wg folk would not agree with thats tatement.

> Given that DNS is the appropriate means of finding resources

and i thought it was the means to map identifiers to addresses.

randy

---

From: "Richard Barr Hibbs" <[email-masked]>
Date: Sat, 5 May 2001 11:19:29 -0700

I speak just for myself, not the entire DHC Working Group, but I do not
support the generic use of DHCP to locate services and resources on the
network that are not specific to configuring the DHCP client for
communicating with other network elements.  Part of my reason is because of
the scalability issue, and the general difficulty in an administrator
knowing all the resources that might be needed to satisfy client needs.

While DHCP can definitely be used to pass a great deal of information from a
server to a client, and does provide a mechanism for defining and using
vendor-specific options, that still puts too much of a burden on the
administrator in my opinion.  For example, the vendor-specific options
(129-254) could incorporate three printer choices for the client:
high-speed, medium resolution letter-size paper for drafts, medium-speed,
high-resolution color printer with legal and letter-size paper for most
"final" printing, and a high-speed, high-resolution color printer with
collator and stapler, multiple paper sizes (8-1/2 x 11 letterhead, 8-1/2 x
11 second sheet, 8-1/2 x 14, 11 x 17) plus envelopes.  Consider for a
moment, however, what an administrator must do to make this workable.
First, she would need a complete inventory of shared printers matched to the
subnets under her purview:  unless each was the same manufacturer and model,
there would likely be some individual configuration information that would
be required to be inventoried as well.  Then she needs a DHCP client that
understands the options chosen to pass configuration data, and that client
must be capable of setting all printer configuration parameters in the
client system.  That probably requires either a custom DHCP client and
server, or an extremely knowledgeable administrator with all the resources
to gather, maintain, and manage the printers, DHCP clients, and
peculiarities of the client's operating system.

Seems to me that this is what Services Location was intended to solve.
Maybe Erik will wade in here with an opinion?

While DNS could be part of the solution to locating resources (for example,
mapping a name such as "hp870cse.192.168.244" to the actual IP address of
the H-P 870Cse DeskJet printer for the 192.168.244.x subnet) all of the
other configuration information necessary to make printing (to use just one
example) successful is not handled very well using DNS (again, scaling and
administration more than the lack of capability for responding to a query.)

--Barr Hibbs
  UltraDNS Corporation

> -----Original Message-----
> From: Randy Bush
> Sent: Saturday, May 05, 2001 8:17 AM
> To: Bill Woodcock
> Cc: [email-masked]
>
> I suspect the dhcp wg folk would not agree with that statement.
>

---

From: Erik Guttman <[email-masked]>
Date: Mon, 7 May 2001 16:31:18 +0200 (MET DST)

Richard,

It is precisely because of the issues you raise that the service location
working group arrived at SLP.  I want to briefly contrast the problem
statements you make with the solutions provided by SLP.

> 11 second sheet, 8-1/2 x 14, 11 x 17) plus envelopes.  

SLP allows client systems to request services using attributes - so the
client can find the *right* server.  Right in individual cases may be 
determined by speed, color capabilities, resolution, page size, etc.

> Consider for a
> be required to be inventoried as well.  

Another possibility:  The printer *advertises itself.*  The printer
can easily provide its model type, capabilities, paper sizes, etc.

> Then she needs a DHCP client that

SLP client libraries allow LDAPv3 search filter queries to be sent.
URLs (the service's location) are retrieved - as well as attributes
and configuration information specific to the service.  Specific
code to support different types of service is not needed.

> administration more than the lack of capability for responding to a query.)

For automatic service discovery, we need a default, well known namespace.  
That is true whether we use DHCP, SLP or DNS.  That way, no matter what
network a client is present in, it can discover services.  Implication: no
matter what network the service is advertised in, it has to be advertised
the same way (using the same namespace conventions).

DHCP has a simple namespace for services: option #s.  SLP is richer - 
services are specified by a service type and a set of attributes associated 
with each service instance.  In DNS SRV RRS, services are specified by a 
service name, a transport name and a domain name.  But what would the 
'default DNS name' be, to use for looking up services?

One possibility would be to use the 'local.arpa.' domain which is discussed 
in draft-ietf-dnsext-mdns-00.txt.  Clients could request IPP based printers
by issuing an mdns request with qname='_ipp._tcp.local.arpa.', qtype=SRV.  
IPP based printers could respond to these requests.  If the client had
a configured domain name, the same request could be sent replacing 
'local.arpa.' with the client's domain name.  If the client had a DNS
server address in addition - the same request could be sent using (non-
multicast) DNS.

I do not think this is a bad idea - for discovering services which are
*indistinct*.  Unlike printers, described above, many services really 
are functionally identical.  SMTP relays, DNS servers and web proxies, 
are examples of services for which *any* will do.

There are problems with using this approach though:

 1. We are considering standardizing mdns for use with link-local
    multicast.  The mechanism will enable discovery of services only
    on a single link.

 2. In the absence of deployed DNS dynamic update, services on the 
    network would be unable to update DNS with SRV RRs.  This implies
    it would be unlikely that clients would get the same result by
    using mDNS and DNS - as it is difficult (impossible?) to keep
    DNS zone files up to date with respect to which servers are up
    or down at any given time.

---

My recommendation is to that the DNSEXT WG not consider or further
discuss service discovery using mDNS.  

We can discuss issues surrounding this application of mDNS in the 
upcoming ZEROCONF WG 'Zeroconf host requirements and recommendations'
document.

Erik