Subject: RE: summary/conclusion of discussion on mdns-00

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 02 Jun 2001 00:27:38 -0400

At 02:14 PM 5/30/2001, Nicolae, Dan wrote:
> > What's more, as soon as that "magic string in the search list" stuff is
> > gone, the whole "local.arpa" nonsense can go with it (which isn't to say
> > that people shouldn't use that necessarily, just that there's no reason at
> > all to compel it).  (ie: unlike some others on the list, I agree with
> > proposed change #1).
>Restricting mDNS to names rooted at "local.arpa" has another effect, besides
>the mDNS configuration. It isolates the mDNS data in the DNS namespace. I am
>not sure if this was one of the purposes for the "local.arpa" proposal, but
>I can see a potential value.

There are two reasons for local.arpa. , one is to make sure all devices are 
playing in the same name space and thus see each other.
The second reason is to have an easy way to filter these names.
The original suggestion was to use some top level domain, which does not
fly in current ICANN environment.

>"local.arpa" is a potential solution but I am not sure that it aligns with
>the original DNS design in RFC1034 (besides the problem that existing DNS
>servers are not configured to push back queries for ".local.arpa"). I
>believe that when dealing with parallel, separately managed namespaces the
>suggested solution is to use different classes. Different "zone cuts" for
>the same namespace are legal in different classes.

Yes a separate class is one way to go, but in April 2000 some company
wanted solution that could be shipped before the end of 2000.
IMHO this solution is well within the design in RFC1034, if there
had been more time a better discovery mechanism could have been built
in [Bill^2 where is the new draft ?]

>I know that classes other than IN have proved unuseful so far (except when
>used in the QCLASS field. However I am curious what would be the issues with
>defining a new class for mDNS (it could be e.g. ZC from zero configuration)
>instead of rerooting the DNS namespace at "local.arpa".

How can I say this politely, "local.arpa." gives implementors with little
clue all the flexibility they need, why give them more ?
I fought hard for requiring that every node that answers mDNS query acts like
a real DNS server for a real DNS zone, eg it must have SOA, NS records.
There where people that wanted only to be able to answer for single type.
As for issues with new class,
         - how do you populate the type space, inherit from IN or create new
         - how long before tools become available,
         - does ICANN control the namespace of all classes or only IN ?

         Olafur

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

---

From: Bill Manning <[email-masked]>
Date: Sat, 2 Jun 2001 12:54:01 -0700 (PDT)

since my posts to namedroppers are rejected by the moderator, 
and the current wg trhust seesm to be toward the microsoft
approach, I have less interest in active participation. The
idea is sound, even if it evolves on the way.

I do have a draft; "Discover" that needs to be revisted as well.
hopefully I'll have some time this week to work on them.

-- 
--bill

---

From: Robert Elz <[email-masked]>
Date: Sun, 03 Jun 2001 16:53:05 +0700

Date:        Sat, 02 Jun 2001 00:27:38 -0400
    From:        Olafur Gudmundsson <[email-masked]>
    Message-ID:  <5.1.0.14.0.20010602002339.022e87c0@localhost>

  | There are two reasons for local.arpa. , one is to make sure all devices are 
  | playing in the same name space and thus see each other.

I am confused.    What was this protocol supposed to be about again?

I thought it was to be the DNS for when there is no DNS server available.
That is, to be able to do just what the DNS would do, if only it was
in an environment where there was a configured DNS server available.

That is, the applications (users, whatever) need to know (or be able to
discover some other way - even guess) what the name to be found is, and
then the DNS is used (or mDNS in this environment) to obtain the data
that the DNS has available about that name.

How does "see each other" come into that at all?   There's no "give me a
list of all the names so I can pick one" type functionality here at all,
and as long as some kind of DNS emulation is being done, there cannot be.
Nor is this "service location done a different way".

What does local.arpa possibly have to offer that makes a difference here?

(That is, excluding any possible use of the name as a switch for when
mDNS type name resolution should be done - just concentrating on the
name itself).

  | The second reason is to have an easy way to filter these names.

This is even more confusing.    Filter the names from what?   By what?

I'm doing a lookup, if I am doing a lookup for olafur.local.arpa then
that's the name I want to find, and I doubt I am going to filter it.
On the other hand, if I am doing a lookup for munnari.oz.au then I am
not going to see olafur.local.arpa or anything-else.local.arpa at all,
to filter...

If you mean that some applications might not want to see any results from
mDNS lookups at all (real DNS for me or nothing) then this crude abuse of
the namespace seems like exactly the wrong way to achieve it.  Much more
sane would be for the API to simply have a "no mDNS" switch that the
application can turn on (like it is possible to disable use of domain name
searching and other stuff in most APIs now).

  | The original suggestion was to use some top level domain, which does not
  | fly in current ICANN environment.

The value of the name isn't the issue - it is simply that it looks
to be using the namespace to provide some functionality that has nothing
whatever to do with the DNS name tree.

  | Yes a separate class is one way to go, ...

I'm not sure why separate anything is needed?   Maybe I am just very
confused, but there are two orthogonal issues here - one is the name
to be found, and the other is the method by which that is done.

I thought that the intent here was all about the 2nd of those - providing
a method that can be used without lots of expert configuration, one that
will simply work out of the box.   That's a fine objective to want to
achieve.    Anything more than that seems bogus to me.

  | I fought hard for requiring that every node that answers mDNS query acts
  | like a real DNS server for a real DNS zone, eg it must have SOA, NS records.

I can see some justification for that, but for how this is likely to be
used, it seems like overkill.   That is, I certainly wouldn't object to
a mDNS "server" that actually did all of that, but I also wouldn't require
everything to implement all of that - especially given that the records
would all be very predictable anyway ... I am my own NS ("@ NS @").  My
SOA is "@ IN SOA @ root.@ 0 0 0 1 0".   The only part likely to ever
vary is the "root" part, but exactly what an implementation (without
configuration) would put there I'd hesitate to guess.

  | There where people that wanted only to be able to answer for single type.

I can understand that .. I have a name, I have an address, I know nothing
else at all, so that is all I am going to say.

This is why I also believe that DDNS type queries should be what is used
to "bind" my name to myself (check for duplicates).   Handling that would
complicate implementations a little, but not all that much - especially if
it is made clear just what DDNS transaction should be used (ie: don't just
allow everyone to do whatever seems OK to them - specify it).

Because there's no record type that a SERVER necessarily has available
(simple implementations won't be bothering with SOA, nor NS, and some nodes
will have A records only, while others A6 (or AAAA) only, so those queries
don't work either).   That is, it is entirely possible for any regular
query that is made to be quite correctly met with absolute silence, even
though the name being queried exists (with the possible exception of ANY
which has other potential problems).

On the other hand, a "add me (A, A6, whatever the node wants, the record
being added isn't important, it will be ignored mostly) if name doesn't
exist" DDNS type query will result in a YXDOMAIN error response from the
node that currently claims the name, if the name being sought actually
exists somewhere.

kre