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

From: "Nicolae, Dan" <[email-masked]>
Date: Wed, 30 May 2001 14:14:19 -0400

> 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.

What is characteristic to mDNS is not only that it uses multicast. A
'normal' DNS server could as well listen on the multicast address and
respond from its own zone data or provide recursive services, with no other
changes to the DNS protocol. mDNS however goes beyond this simple change and
allows for extra, self-configured, authoritative name servers. This
effectively changes the partitioning of the DNS namespace in different
zones. 

Rerooting the mDNS data tree at "local.arpa" alleviates these authority
conflicts. From a 'normal' DNS admin perspective anything that ends with
"local.arpa" doesn't exist in DNS and it should be ignored, or, a response
meant to contain the query traffic in the local area should be sent
(ideally, a query for such an RR should not even be received). The "default"
zones "localhost", "0.0.127.in-addr.arpa", "255.in-addr.arpa" and
"0.in-addr.arpa" work like that (RFC1912).

I think it makes sense to separate the selfconfigured mDNS data from the
managed data in the DNS namespace. Preventing hosts to multicast is
different than preventing hosts to act as authoritative name servers and
provide (potentially) bogus data.

"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.

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".

>  I'm also not sure that simply doing a query for the name I want to claim,
> and grabbing it if there's no response (or the response identifies me) is
> adequate.  I think I'd prefer to have the node send a dynamic DNS "add me
> if I don't exist" type transaction.  Then, if anyone else out there has
> the name, they'd respond, and return an error (name already exists).  If
> no-one has the name, no response, just as before, and things continue.

I think that using DDNS to handle name registration/conflicts is a very good
idea. Standard DNS and mDNS should behave the same unless there are
compelling reasons not to. The addresses (unicast or multicast) and the
namespaces (DNS/mDNS) may differ but the resolver algorithm should be
similar. 

dan

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, 30 May 2001 14:09:48 -0700 (PDT)

> namespaces (DNS/mDNS) may differ but the resolver algorithm should be

How is DDNS to be secured in an adhoc environment?

---

From: Robert Elz <[email-masked]>
Date: Thu, 31 May 2001 13:34:26 +0700

Date:        Wed, 30 May 2001 14:09:48 -0700 (PDT)
    From:        Bernard Aboba <[email-masked]>
    Message-ID:  <[email-masked]>

  | How is DDNS to be secured in an adhoc environment? 

mDNS is all DDNS - any node creates its own name, and then answers
about that name are sent to others - that is exactly DDNS.  The only
difference is that the node creates its name within itself, and
answers queries itself, rather than designating some other server to
do that (and that's almost an irrelevant difference).

Whether this mDNS created DDNS data is ever exported to the global
DNS is a separate question, and if so, what kind of authentication is
used .. but to keep things rational, when "creating its own name", the
node probably should be using DDNS type packet formatting (ie: DDNS
opcodes) rather than queries for some data which one hopes might
exist, but just as easily might not (DDNS has extra options to make
all of those problems vanish).

kre