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

From: Bernard Aboba <[email-masked]>
Date: Tue, 25 Sep 2001 11:30:41 -0700 (PDT)

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. 

Assuming that you could use mDNS to query for *any* name, is there a
reason for continuing to include ".local.arpa" in the draft? 

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

---

From: Erik Guttman <[email-masked]>
Date: Wed, 26 Sep 2001 08:44:58 +0200 (MET DST)

> reason for continuing to include ".local.arpa" in the draft? 

There are very good reasons not to include it:  There would have
to be special handling of this arpa domain (by the arpa TLD servers)
which we have not come to any resolution about.  Further, there will
still be a prolonged discussion about whether this particular use
of the arpa TLD is appropriate.  

If there is a desire to create an administratively local namespace
for specific use (say, only link-local, or link-local and admin
scope) this should be defined in a separate document.  

Erik

---

From: [email-masked]
Date: Wed, 26 Sep 2001 17:58:24 +0900

>scope) this should be defined in a separate document.  

	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".  I don't care if it is defined in a separate draft,
	or in a single draft, but I would like to see it kept in some way,
	to protect normal DNS namespace from getting contaminated with mDNS
	results.

itojun

---

From: Erik Guttman <[email-masked]>
Date: Wed, 26 Sep 2001 12:51:59 +0200 (MET DST)

> 	to protect normal DNS namespace from getting contaminated with mDNS

Itojun,

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

I submit that this will be present regardless of whether mdns,
and whether '.local.arpa' is used as currently defined, or not.

Consider that on a LAN, any host can respond to DNS requests
as if they were the DNS server by evesdropping and generating
the appropriate IP packet reply.  DNSsec or IPsec or some other
measure would be needed to prevent this.  This threat is independent 
of whether multicast DNS is used, or which namespace.

A larger multicast scope would ease an attacker's job - as he/she
could be anywhere within the extent of multicast routing rather
than on the forwarding path of the DNS request.  We are
not currently discussing mDNS using larger than link-local scope
and even so, this is only worsens the problem a bit by degree but
not by kind.

Also, using .local.arpa (as discussed by previous drafts of
draft-ietf-dnsext-mdns) does not reduce the risk of masquerade
attacks or even unwanted aliasing behavior.  'foo.itojun.org' would
be resolved as 'foo.itojun.org.local.arpa', and the mdns server on 
the host with authority for 'foo.itojun.org' would respond to
'foo.itojun.org.local.arpa'.  This aliasing buys one nothing.

Last, any host besides the one you assigned the name 'foo.itojun.org'
responding to that name would be doing so in violation of the
protocol which prevents duplicate name assignment.

This brings up an interesting questions I think:

Shouldn't a host H1 with an administratively assigned name defend
it against another host H2 which is using the same name, even if
H1 discovers this fact after H2 has already claimed the name?
I distinguish between two kinds of names - those assigned and those 
'invented.' In this case shouldn't the latter category should be 
prepared to relinquish the name, the former not?   This is not an
arbitrary nor philosophical distinction (assigned names vs. zeroconf 
generated names).

Regards,

Erik

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Sep 2001 07:11:26 -0700 (PDT)

> > 	to protect normal DNS namespace from getting contaminated with mDNS

The main thing that ".local.arpa" provides is
the ability of two hosts with different searchlists to resolve the name
non-fully qualified domain names, such as "foo". 

> and whether '.local.arpa' is used as currently defined, or not.

Indeed, the current draft doesn't prohibit an mDNS-enabled node from
answering a query for foo.itojun.org, foo.itojun.org.local.arpa, etc.

> protocol which prevents duplicate name assignment.

Actually what is prohibited is not duplicate name assignment, but
duplicate name usage. 

> H1 discovers this fact after H2 has already claimed the name?

This occurred to me today as I encountered a name conflict on our
corporate network. Apparently lots of people like to name their computers
based on the manufacturer and model # (e.g. dell8100). I had registered my
machine, but someone else also picked the name, and I had to change mine
(not a trivial procedure, by the way, since I had to obtain new machine
certs for use with IPsec, IEEE 802.1X, etc.). Took me about 15 minutes to
complete the name change and make sure everything was working again. 

> arbitrary nor philosophical distinction (assigned names vs. zeroconf 

Indeed.