Subject: Re: revised mDNS configuration language

From: Robert Elz <[email-masked]>
Date: Tue, 18 Sep 2001 08:13:05 +0700

There's another method that could be used for deciding when to use
mDNS (in the presence of some kind of configuration of course, the
decision when there has been no configuration at all has to have
been made by the software vendor - and while the suggestion for what
vendors should do in that case might be an interesting issue, nothing
else about it is).

When there's any configuration, which is always needed (currently
anyway) to do regular DNS, the one thing that must be told to the
end-nodes is where to find the back end resolver.

mDNS is essentially a method to allow that configuration to be
avoided, by defining a static address that vendors can install,
rather than requiring use of a particular local address that
necessarily has to be configured locally.    That mDNS also
allows nodes to be their own servers isn't relevant to this
message.

Earlier we discussed the possibility of simply having mDNS on
when there was no other DNS configuration, and off when there was,
but that didn't seem flexible enough (sites might want both in
some cases, with the lookups done in a particular order).

I know this is a bad idea, but I wanted to get it into the archives
anyway, so it will be there for future reference ... what could be
done, would be to simply allow the mDNS multicast address to be
configured as one of the local back end resolver addresses, if mDNS
is to be enabled.

That is, if the DNS server (really back end resolver) address configuration
is 192.168.1.9 224.0.0.99 172.29.28.27 (and assuming 224.0.0.99 was a
rational multicast address for mDNS to use) then that would be saying
to try 192.168.1.9 first, using DNS, then use mDNS, then try ...

The multicast address configured would just be the "base" address, in
which the part formed from the name hash (assuming that's how the protocol
ends up) would be included.   But it would give the multicast scope to use.

If we were starting from scratch, I can almost convince myself that this
would be  workable approach, and much simpler than anything else suggested.

Of course, current DNS configuration mechanisms supply data to current
DNS clients, which don't have a clue about use of mDNS, so actually doing
this would most likely cause far more problems than it could ever solve.

So, now everyone can just ignore this message...

kre

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

---

From: Aidan Williams <[email-masked]>
Date: Wed, 19 Sep 2001 17:13:51 +1000

> this would most likely cause far more problems than it could ever solve.

Such as?

  - There isn't anything I know of *requiring* those back-end resolvers
    to be consulted in the order that the addresses are provided.

  - If you got a "name does not exist" from a DNS server,
    the resolver would not bother to try the next address
    (ie the mDNS one)

  - DNS over TCP would be broken.

Looks pretty infeasible to me.

> So, now everyone can just ignore this message...

I'm trying, but I know a couple of people who have tried this,
and it seemed to work OK.  Of course, "works" is a relative term.

regards
	aidan
____
:wq!

Communications and Networks Lab         [email-masked]
Motorola Australian Research Centre          phone: +61 2 9666 0649
Locked Bag 5028, Botany NSW 1455              phax: +61 2 9666 0501
Australia                            http://cnlab.arc.corp.mot.com/