Subject: RE: [mDNS] Removal of ".local.arpa" namespace?

From: "Nicolae, Dan" <[email-masked]>
Date: Wed, 26 Sep 2001 12:40:54 -0400

> It has been pointed out that now that we are no longer using 
> the domain
> searchlist to configure mDNS, that continuing to use the
> ".local.arpa" namespace doesn't make sense

> 	I believe it is still useful to use ".local.arpa" for 
> mDNS.  It would
> 	be a disaster for various mDNS-enabled node to claim 
> authority for
> 	"foo.itojun.org".  

> 
> This active attack threat (masquerading) is indeed a concern.
> Thank you for bringing it up again for discussion.  
> 

Is mDNS ever going to coexist with standard DNS on the same client? Is a DNS
server ever going to respond to multicast queries? Is mDNS ever going to go
beyond linklocal? 

If yes, then this is not only a masquerading issue. This namespace
contamination, authority conflict, configured vs. zero-configured names, or
however we may call it, *may* become an administrative nightmare in the
future. Even when troubleshooting NetBIOS name resolution is useful to
distinguish between names resolved through broadcasts vs. names resolved
through name server (i.e. nbtstat -r).

On the other hand, if the answer to the questions above is no, then using
the NS/SOA records, DDNS and maybe even multicast to support mDNS is
overkill. So I assume that at least some people hope that the answer those
questions is yes. 

However, we may assume that an intelligent proxy would fill the gap between
mDNS and DNS and take care of any potential coexistence conflicts:
mdns-05: "...Propagation of multicast DNS packets within the local subnet is
considered sufficient to enable DNS name resolution in small adhoc
networks. The assumption is that if a network has a router, then the
network either has a DNS server or the router can function as a DNS
proxy, possibly implementing dynamic DNS..."

The fact that we restrict for now mDNS to linklocal does not mean that at
some point the mDNS traffic won't escape to the Internet, even if it is
repackaged as legitimate unicast traffic.

What if the network has that smart router that accepts DDNS registrations
from the linklocal hosts and also resolves names for hosts outside of
linklocal? A local host manually configured as "foo.itojun.org" would
register its name with the router and the real "foo.itojun.org" on the
Internet would never be found.

Also, are users expected to name their PC using a FQDN? I think most of them
would simply name it "mypc" and not worry about the rest. What is going to
happen then? The router would have to accept registrations for *any* FQDN
and become authoritative for *any* zone, including the root and top level
domains. How about the zillion of smart devices that will most likely do
mDNS and ship with a default name? What would be a good default domain? What
if a home user has the idea of naming his new printer with a name under the
printer's manufacturer's DNS domain?

Etc. It is hard to foresee all potential problems, but I *feel* that there
is something wrong with completely giving up control over the DNS authority.
There must be way to distinguish between administratively configured and the
selfconfigured/user configured data. 

"local.arpa" was a quick and dirty candidate for meeting this goal. Although
I personally don't like it, we can't afford to give up on it without a
replacement solution. A while ago I suggested using a different class to
flag the non-administratively configured DNS data. The need of a better
authority discovery mechanism was also pointed out. But, the way mDNS looks
today, and if it is to be extended tomorrow, I think we're stuck with
'local.arpa'

dan

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