Subject: mDNS/LLMNR and "local.arpa"

From: [email-masked]
Date: Fri, 13 Sep 2002 22:58:33 +0900

(thread from zeroconf mailing list.  see
	http://www.merit.edu/mail.archives/zeroconf/msg00604.html
	and emails before that)

>if there's no intent to support use of DNS names or DNS-like names,          
>and the group is willing to NOT overload existing name lookup APIs,           
>I'd like that to be stated explicitly and up-front.  it simplifies            
>a number of problems, but it also makes zeroconf incompatible with
>existing programs - so I have my doubts that this is the intent.

	then why "local.arpa" was removed from mDNS/LLMNR document?  indicators
	like "local.arpa" or "local" (used by Apple Rendezvous) is a good
	indication of different name space.

itojun

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Robert Elz <[email-masked]>
Date: Sun, 15 Sep 2002 13:22:27 +0700

Date:        Fri, 13 Sep 2002 22:58:33 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	then why "local.arpa" was removed from mDNS/LLMNR document?  indicators
  | 	like "local.arpa" or "local" (used by Apple Rendezvous) is a good
  | 	indication of different name space.

No, mangling the names is a poor way to indicate different name spaces.

And that's for much the same reasons that my suggestion to stick the
scope id of IPv6 limited scope addresses (LL & SL) inside the address
itself (as part of the API) was rejected (and I agree now, rightly so).

kre

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 16 Sep 2002 03:23:57 +0900

>No, mangling the names is a poor way to indicate different name spaces.

	then how can we differentiate mDNS/LLMNR name and DNS name under
	the same API (getaddrinfo/getnameinfo)?

itojun

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 15 Sep 2002 14:19:16 -0500

> 	the same API (getaddrinfo/getnameinfo)?

LLMNR names are not DNS names. They are not authoritative for the same
namespaces, and they shouldn't be mixed.

How do you already multiplex DNS/NetBIOS/NIS/etc under a single API? Why
should this be different?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 16 Sep 2002 13:27:04 +0900

>should this be different?

	i don't quite parse it.  are you against the use of local.arpa, or
	are you for the use of local.arpa?
	DNS and NIS names (and /etc/hosts) are accessed via single API
	(gethostby*, getaddrinfo/getnameinfo), so it makes sense to use
	the same API.

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 16 Sep 2002 17:01:53 +0200 (CEST)

> 	the same API (getaddrinfo/getnameinfo)?

One could envision new flags (such as AI_LLMNR) for lookups in the local
name space.

  Erik

---

From: [email-masked]
Date: Tue, 17 Sep 2002 00:18:36 +0900

>One could envision new flags (such as AI_LLMNR) for lookups in the local

	that is certainly one possibility, but why do we need it when we don't
	have AI_NIS?  AI_LLMNR removes transparency (of LLMNR) to the
	application.

itojun

---

From: Derek Atkins <[email-masked]>
Date: 16 Sep 2002 12:25:13 -0400

Note that applications try the various naming services until it finds
a match (using some locally-defined ordering).  The fact that there
may be name overlaps is irrelevant.  If I'm searching NIS before DNS
and there is a NIS-MAP that provides a response for host.foo.com, my
application will use that response rather than searching DNS.

I don't see why LLMNR should behave any differently.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Robert Elz <[email-masked]>
Date: Tue, 17 Sep 2002 15:43:33 +0700

Date:        Tue, 17 Sep 2002 00:18:36 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	that is certainly one possibility, but why do we need it when we don't
  | 	have AI_NIS?  AI_LLMNR removes transparency (of LLMNR) to the
  | 	application.

We don't really.   We also don't need .local.arpa (or .local or whatever)
just as we don't have .nis.arpa or .nis (or whatever) (nor do we have a
hosts.arpa or a .hosts or anything else for any other kind of hostname
lookup that might exist).

We already have disjointed namespaces, all considered equal, where a
name lookup gets satisfied by one (seemingly at random, but actually as
configured for the node's lookup order).   Adding one more name lookup
mechanism changes nothing.   Most nodes are going to do DNS lookups first
(or attempt them), and then if there is no DNS server, or it fails, fall
back to whatever lookup mechanism suits (some sites prefer to insert some
locally configured names ahead of the DNS - I doubt doing that for
a local multicast lookup would ever make sense).

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 17 Sep 2002 20:07:25 +0700

Date:        Tue, 17 Sep 2002 22:16:54 +1000
    From:        Aidan Williams <[email-masked]>
    Message-ID:  <[email-masked]>

  | So you would be happy with a LLMNR lookup succeeding
  | for "www.ietf.org"?

Yes, of course, in fact, that might often be exactly what I'd want
to happen, any time it actually succeeded.

Note, that unless I'm insane (in which case you probably should ignore
this opinion), that won't even get a chance to succeed unless the DNS
isn't available at all.

If there's no DNS, and I'm expecting www.ietf.org to work, then I think
I would want it to...

And where that might be useful, is where I make a local mirror of the
IETF site, then if my net connection is missing, or similar, and the DNS
isn't working, I'd want to get to my local mirror, and being able to find
it using LLMNR (or something) sounds like a win to me.   That also has the
advantage that I use the real site when it is available, avoid possible
staleness with my slow update mirror (which is still better than nothing
if necessary).

Yes, there are security issues to be handled, but if we assume that we
start using dnssec sometime this century, then multicast lookups will likely
be distinguished as not being properly signed.

Sticking a funny domain on the end won't solve anything - I'd configure my
search list to include it anyway (so I can refer to "foo") and that means
that (unless I happen to do "www.ietf.org.") the resolver is eventually
likely to try www.ietf.org.local.arpa. as the lookup for me, and then it
would go find the multicast version anyway (a hacker would just be pretending
to be that, instead of www.oetf.org - the A record that comes back to my
browser works the same either way).

If we had to have a restriction, "names with no dots" would be the only
reasonable one - but I really believe that's unnecessarily limiting, for
no real gain that matters.

kre

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 17 Sep 2002 13:27:51 +0200 (CEST)

> 	have AI_NIS?  AI_LLMNR removes transparency (of LLMNR) to the

That is a different question than the one I chose to answer.
You seemed to initially be concerned that there wasn't an easy way to
add such support to the getaddrinfo/getnameinfo APIs, and hopefully
I managed to dispell that concern.

The reason I think AI_NIS (or AI_LDAP, etc) is that the intent is that they
all be managed with the intent of providing a consistent appearance.
So if a name exists in NIS and the same name exists in DNS, the intent
of the common adminstration is that those name refer to the same device.

This is very different than the LLMNR vs. DNS case, where the intent
is that nodes be able to create there own names in the LLMNR name space.

  Erik

---

From: Aidan Williams <[email-masked]>
Date: Tue, 17 Sep 2002 22:16:54 +1000

Robert Elz wrote:
[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

> a local multicast lookup would ever make sense).

So far so good.

So you would be happy with a LLMNR lookup succeeding
for "www.ietf.org"?

Should what is returned bear any relationship at all to
what might be returned by a DNS lookup of the same name?
(without some magic, I can't see how)

Should an application be able to tell the difference
between something answered by the DNS and something
answered by LLMNR?
(unless there a different API, or something like a
  well known domain suffix, I can't see how)

One of the differences between the DNS/NIS/whatever
name service examples and LLMNR is that there is a server
that is "more trusted" than "just any old host that happens
to be within earshot of the requester".  The use of a well
known suffix could prevent www.ietf.org from being resolved
using an LLMNR-like protocol (by ensuring that only
things that are in a particular domain suffix get resolved).

Another approach may be to stipulate that things looked up
using LLMNR don't have any dots in them (that would match
the kind of behaviour that is seen currently with NetBIOS
naming today).

Personally, I think it would be prudent to do something
to prevent security problems that may result from looking
up what are supposed to be DNS names in LLMNR.

It is true that unicast DNS responses to requests could
be forged, but the multicast nature of LLMNR makes the
task a whole lot easier.

-- 

regards
	aidan
____
:wq!

Sydney Network Research 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://marc.labs.mot.com/snrl/

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 17 Sep 2002 16:07:37 -0500

> So you would be happy with a LLMNR lookup succeeding

An LLMNR response for that name would be authoritative. An LLMNR response
for www.ietf.org.local.arpa would also be authoritative. Both of them
would be non-authoritative for the DNS names, however, for multiple
reasons (RRs have expired and/or changed, for example).

Ergo, applying the LLMNR names, data, and authority to the DNS namespace
would be dangerous in all cases. Therefore, LLMNR data MUST BE HANDLED
SEPARATELY from DNS data in those cases where the data will be reused.
Note that once the minimum responsible effort is taken, then the presence
or lack of any specific label is moot.

In those cases where it is not reused beyond the context of a single
application, who cares?

---

From: Aidan Williams <[email-masked]>
Date: Wed, 18 Sep 2002 11:16:06 +1000

> If there's no DNS, and I'm expecting www.ietf.org to work, then I think

OK.  I understand your position.

 > be distinguished as not being properly signed.

That is not an "if" I would use to justify not bothering to
differentiate LLMNR and DNS names in some other way.

 > browser works the same either way).

That would be what a *DNS* resolver would do with the name, and is
beside the point.  Some resolvers count the number of dots too.

[ I'm assuming in all this that the DNS resolver and the LLMNR
   resolver software are two seperate pieces of code (ie that the DNS
   resolver isn't going to try multicast for DNS request it is passed,
   or use a "funny suffix" as a trigger for doing multicast lookups.  I
   though we had decided that overloading the search list as a trigger
   for mDNS lookups was a bad idea..) ]

There seems to be a confusion here between how something like
nsswitch.conf operates and how a DNS resolver library operates.
My understanding is that code dealing with different name systems
(eg code for nsswitch.conf) will pass just the name through
to each underlying name service.

For an /etc/nsswitch.conf hosts entry like

     hosts: files dns llmnr

1) www.ietf.org gets looked up in /etc/hosts

2) www.ietf.org gets passed to the DNS resolver library,
		which may subsequently try the name with various
		domain suffixes tacked on the end

3) www.ietf.org gets passed to the LLMNR resolver code
		which could choose not to do a multicast request
		because the name has dots in it, or because the name
		does not have the local.arpa suffix

So a known suffix and/or no-dots would be a simple prescription that
could work to ensure that DNS names like www.ietf.org are not resolved
using LLMNR.  One could even put llmnr before DNS with this approach.

I understand that you are saying that would would like to be able to
resolve "www.ietf.org" via LLMNR.  I have an open mind on that.

 > no real gain that matters.

The gain is perceived to be a guarantee that LLMNR won't have any
negative security implications for applications that think they are
looking up DNS-like names.

If the DNS mostly always gets to resolve the name first, then you are
pretty unlikely to use LLMNR to resolve www.ietf.org anyway, so there
is no great loss in imposing the restriction?

--

regards
	aidan
____
:wq!