Subject: dns server discovery using mdns

From: Erik Guttman <[email-masked]>
Date: Wed, 25 Apr 2001 11:53:51 +0200 (MET DST)

mdns-00> Discovery of the services in general as well as discovery 
mdns-00> of the DNS servers in particular using multicast DNS is 
mdns-00> left outside of the scope of this document.

Why shouldn't the mdns resolver first send a request of type NS or 
SOA for a particular domain?  This was suggested by Manning & Woodcock
and seems right to me.  This allows a DNS resolver to bootstrap in
the absence of DHCP.  This is even explicitely allowed in RFC 1123,
section 6.1.3.2, page 76:

            A server MAY support a UDP query that is delivered using an
            IP broadcast or multicast address.  However, the Recursion
            Desired bit MUST NOT be set in a query that is multicast,
            and MUST be ignored by name servers receiving queries via a
            broadcast or multicast address.  A host that sends broadcast
            or multicast DNS queries SHOULD send them only as occasional
            probes, caching the IP address(es) it obtains from the
            response(s) so it can normally send unicast queries.
 
            DISCUSSION:
                 Broadcast or (especially) IP multicast can provide a
                 way to locate nearby name servers without knowing their
                 IP addresses in advance.  However, general broadcasting
                 of recursive queries can result in excessive and
                 unnecessary load on both network and servers.

Since we are presently only discussing the use of link-local multicast,
the concern over excessive load on network and servers is unnecessary.

If multicast is used to discover DNS servers *which are 
present,* this will lighten the load on servers subsequently,
as resolvers will then begin to unicast their requests. '

The load on the network will be analogous (whether unicast or 
multicast is used) since both unicast and multicast requests 
have to traverse the same link.  Multicast requests could be 
slightly more expensive since requests which fail to receive
a response will be retransmitted (a limited number of times).

Erik

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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 25 Apr 2001 11:02:19 -0700 (PDT)

> the absence of DHCP.  

Well, given that mDNS is linklocal only, at best you'd only be able to
find a DNS server on a local link. I would think that a useful DNS
discovery mechanism would need to be able to find DNS servers anywhere in
the administrative domain.

---

From: Erik Guttman <[email-masked]>
Date: Wed, 25 Apr 2001 21:50:24 +0200 (MET DST)

> the administrative domain. 

Any way a host can discover a DNS server is better than none.
A static configuration file is one way, DHCP is another.  Why
not allow hosts to discover DNS servers on their local link,
too?

mDNS as it is defined today is link-local only.  This doesn't mean
that in the future we won't define mDNS to use admin-local
scope.  This could occur, say, when admin-local scope has been 
deployed to contain multicast reasonably in enterprise networks
and we have some (cheery) experience with mdns deployment.

What I am reacting to is the text in the mdns-00 draft which
explicitely excludes DNS server discovery - which seems to me
(and to RFC 1123) to be multicast DNS's primary function.  At
any rate, as I argued elsewhere, it wouldn't hurt to attempt
to find a DNS server on the local link before attempting to
do mdns based resolution.  (This additional discovery step would
not lead to excessive bandwidth consumption).

Erik

---

From: Randy Bush <[email-masked]>
Date: Wed, 25 Apr 2001 14:05:14 -0700

> Any way a host can discover a DNS server is better than none.

possibly, though i can postulate many that might not be.

but nine ways is not better than one.  and don't we already have dhcp?

randy

---

From: Erik Guttman <[email-masked]>
Date: Thu, 26 Apr 2001 09:32:48 +0200 (MET DST)

> but nine ways is not better than one.  and don't we already have dhcp?

Randy,

In the case where are no DNS servers and we can benefit from
mdns resolution.  But what if this is transient?  We should
really be able to use a DNS server if one becomes available.
Do we really want to assume/require that a (correctly
configured) DHCP server will be available whenever DNS is?

Resist the urge to count '0,1,infinity.'  We have DHCP and
resolv.conf.  But we also have DNS resolution, too (mDNS 
being only a slight modification to the DNS client).  Why
not allow *2* dynamic mechanisms for finding the DNS server?

Unlike DHCP, this mDNS mechanism is decentralized and requires
no administration.  Available DNS servers simply respond. 

SLP faces a similar problem:  One can configure services via
DHCP or by requesting DNS SRV RRs - but these are not dynamic
services, that is, they may be inconsistent with the actual 
state of the network.  SLP allows multicast based service 
discovery.  This does not scale up very well - so we have
'directory agents' (DAs).

  (a) DAs are discovered via SLP
  (b) services are registered (soft state) with DAs
  (c) service discovery requests are unicasted to DAs

This allows SLP to scale up.  Why can't DNS operate in the
same manner?

  (a) DNS servers are discovered mDNS
  (b) names are registered with DNS servers via dynamic update
  (c) name resolution requests are unicasted to DNS servers

I do not believe we have all the pieces together to do this yet.
I submit it is the right solution in the long run.  I am concerned 
we are precluding this from  happening by excluding DNS server 
discovery from mDNS.

Erik

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Apr 2001 05:02:54 -0700

> configured) DHCP server will be available whenever DNS is?

i suspect that's not the exactly right question.  can we expect a dhcp
server will be available wherever a client wakes up and wants to find
a dns server?  as i suspect that my wristwatch has a dhcp server these
days, i think so.

> not allow *2* dynamic mechanisms for finding the DNS server?

because we will soon be asked to support both everywhere.  because
we already have one that works.  all those types of arguments.

> no administration.  Available DNS servers simply respond.

it's cute.  it's tempting.  but ...

if the lan is multicast enabled, and the overwhelming success of
global multicast has not driven this well.  i don't want to explain
to a site admin, who is clue-light enough to have an crippled switch
among the 42 on her lan, why roamers in the boardroom are unable to
find a dns server.

randy

---

From: Erik Guttman <[email-masked]>
Date: Thu, 26 Apr 2001 15:00:49 +0200 (MET DST)

> a dns server?  as i suspect that my wristwatch has a dhcp server these

Are we really willing to accept this 'fate sharing'?

> among the 42 on her lan, why roamers in the boardroom are unable to

Naive question:  Would this crippled switch fail to transmit a 
datagram with a multicast destination address but succeed in 
transmitting one with a broadcast destination address?  If 
broadcast doesn't work, then DHCP won't either & those in the
boardroom are out of luck.

Erik

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Apr 2001 06:09:00 -0700

> Are we really willing to accept this 'fate sharing'?

are we willing to accept that both routers and circuits are working at the
same time?

> transmitting one with a broadcast destination address?

a prudent site admin checks for igmp capability.  and prudent site admins
seem as common as helpful it departments.

randy

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Apr 2001 07:47:57 -0700 (PDT)

> configured) DHCP server will be available whenever DNS is?

It's not necessarily a bad assumption because almost all home gateway
routers now include both a DHCP server and a DNS proxy. This is one of the
basic assumptions of the mDNS draft.

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 26 Apr 2001 08:25:05 -0700

> no administration.  Available DNS servers simply respond.

I should read drafts before commenting, but... Clients have specific
needs, such as finding a server that performs recursion, and discovering
the search base domain name which should be applied to unqualified
lookups. These require specific operational mechanisms within the
protocol, such as providing a weighted set of responses from the eligible
servers, and then having the client choose from those accordingly. These
aren't difficult, but they need to be defined.

I certainly agree that mDNS for clients is very useful for a variety of
situations and it should absolutely be done (routers/switches that need
DNS for various functions but which cannot use DHCP, is one obvious
example). I also think there are a bunch of issues that have to be taken
into consideration, and that it is probably a standalone effort.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Paul A Vixie <[email-masked]>
Date: Thu, 26 Apr 2001 10:39:57 -0700

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.  There
is a need for stateless peer-to-peer autoconfiguration with no DHCP servers,
no DNS servers, no default gateway.  mDNS is part of that.  Saying "why don't
we just use DHCP" entirely misses the thrust of the argument.

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Apr 2001 13:15:47 -0700

> to each other but use IP-over-IRDA rather than something proprietary.
> There is a need for stateless peer-to-peer autoconfiguration with no DHCP
> servers, no DNS servers, no default gateway.  mDNS is part of that.
> Saying "why don't we just use DHCP" entirely misses the thrust of the
> argument.

what is being questioned is the belief that there are significant [0]
scenarios where actual dns resolution is needed and yet it is not
reasonable to expect dhcp service.

i.e. why would two isolated pdas wanting to beam stuff to eachother,
regardless of transport mechanism, need to resolve lcs.mit.edu?  as they
beam stuff now, what about a change at the transport level causes dns
requirements?

and, before someone tries to construct the situation why it is needed,
maybe for the sake of simplicty in life, they should try and construct the
situation where it is not.

randy

---

[0] - where 'significant' means, among other things, worth the cruft of
      yet another solution to the same problems.