Subject: Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

From: Stuart Cheshire <[email-masked]>
Date: Tue, 30 Aug 2005 11:18:17 -0700

>As I understand it, one of three things will happen:
>
>(1) If the system implements mDNS, the .local domain is treated 
>specially, so this just goes out as a link-local request.
>
>(2) If the system implements LLMNR, there will first be a global DNS 
>lookup for "twiki.local", which will fail.  Then, a link-local name 
>request will be tried.
>
>(3) If the system doesn't implement any link-local name resolution, 
>there will be a global lookup for "twiki.local" which will fail.
>
>So, if people use .local domains on systems that implement LLMNR 
>instead of mDNS, this can result in lookups for .local in the global 
>DNS.
>
>But, given that choices (2) and (3) involve the same interaction with 
>the DNS, I'm not sure how one can argue that LLMNR makes things any 
>worse than things would be without it.  Perhaps you could argue that 
>mDNS makes things better, but that is only true for this one 
>non-existent TLD -- all three systems would generate a bogus global 
>DNS query if I did a DNS lookup for "isoc.frog".
>
>Margaret

There's one other relevant difference to note here: If you do a DNS 
lookup for "isoc.frog" you generate a bogus global DNS query. This is 
true. But... do you habitually do DNS lookups for "isoc.frog"?

Well, in case 1 (mDNS), no, because it won't return a useful result, so 
why keep doing it?

In case 3 (conventional DNS), no, because it won't return a useful 
result, so why keep doing it?

In case 2 (LLMNR) the answer is yes, all the time, if you chose to call 
your printer "isoc.frog", which LLMNR allows and encourages.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Peter Dambier <[email-masked]>
Date: Tue, 30 Aug 2005 23:12:58 +0200

Yes, that is exactly what our unvolontary experiment has shown.
And it makes 25% of our root server traffic. It is stealing resources
from us. That is why we consider this protocol harmful to the
internet society.

Kind regards,
Peter and Karin

-- 
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
mail: [email-masked]
http://iason.site.voila.fr
http://www.kokoom.com/iason

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 31 Aug 2005 11:51:41 -0400

> your printer "isoc.frog", which LLMNR allows and encourages.

What part of the specification requires LLMNR names to be processed
through Internet DNS?

There are lots of similar-looking naming services out there (DNS, NIS,
NetBIOS, AppleTalk, ...), and there is a significant amount of experience
in keeping the names and resolution paths separate. Just because an LLMNR
name "looks like" a DNS name doesn't make it one (just as an AppleTalk
name that "looks like" a DNS name doesn't make it one).

People who mix the resolution paths (and/or the caches) deserve what they
get. Unless you can point out where this is mandatory, I'd say the correct
response is "don't do that"

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

---

From: Ned Freed <[email-masked]>
Date: Wed, 31 Aug 2005 09:36:41 -0700 (PDT)

> What part of the specification requires LLMNR names to be processed

Section 2 states:

  An LLMNR sender may send a request for any name.  However, by
  default, LLMNR requests SHOULD be sent only when one of the following
  conditions are met:

  [1] No manual or automatic DNS configuration has been performed.
      If DNS server address(es) have been configured, then LLMNR
      SHOULD NOT be used as the primary name resolution mechanism,
      although it MAY be used as a secondary name resolution
      mechanism.  For dual stack hosts configured with DNS server
      address(es) for one protocol but not another, this implies
      that DNS queries SHOULD be sent over the protocol configured
      with a DNS server, prior to sending LLMNR queries.

  [2] All attempts to resolve the name via DNS on all interfaces
      have failed after exhausting the searchlist.  This can occur
      because DNS servers did not respond, or because they
      responded to DNS queries with RCODE=3 (Authoritative Name
      Error) or RCODE=0, and an empty answer section.  A dual
      stack host SHOULD attempt to reach DNS servers over all
      protocols on which DNS server address(es) are configured,
      prior to use of LLMNR.

In other words, if I have a name to resolve and I have both LLMNR and DNS
access, I'm supposed to try DNS first, and if that fails, then LLMNR.

> in keeping the names and resolution paths separate.

My experience has been that people generally do a lousy job of keeping
these things separate.

> Just because an LLMNR

THat would be true if LLMNR was indeed designed to offer a disjoint service.
But it isn't. Rather, it appears to be designed to be able to offer both a
disjoint service as well as a sort of backup service to DNS. And that's the
source of the trouble.

Another way of fixing the overlapping namespace problem would be to  require
LLMNR to be truly disjoint from the DNS: Remove all this stuff about using the
DNS as the primary service when available. However, my guess is that such a
service would not be terribly interesting, and that much of the supposed value
opf LLMNR comes from its lashup to the DNS.

				Ned

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 31 Aug 2005 13:28:14 -0400

> Section 2 states:

that's unfortunate

LLMNR clients need to make a distinction between the different kinds of
networks and then process the names accordingly.

The whole argument behind the original distinction between LLMNR and DNS
is that ad-hoc names aren't self-authoritative, the namespaces are
therefore different, and so forth. Having clients try both namespaces is
really missing the point.

> opf LLMNR comes from its lashup to the DNS.

I was under the impression that LLMNR value was from ad-hoc networks and
naming. Surely that's the right place to flag the distinction too.

NB: I consider ".local" to be a crutch that's needed to make a hack work,
and the right place to deal with these problems is at the interface map,
not inside the namespace. Nevermind the fact that .local is overloaded
with massive historical and experimental context already too.

---

From: Ned Freed <[email-masked]>
Date: Wed, 31 Aug 2005 10:49:23 -0700 (PDT)

> networks and then process the names accordingly.

Agreed. And there are various ways to accomplish this.

> really missing the point.

Agreed as well.

> naming. Surely that's the right place to flag the distinction too.

You'd think that, wouldn't you? But the draft really only mentions this stuff
in passing.

Indeed, as I commented before, the whole tone of the document seems off kilter
to me. It really feels like a document meant to block rather than facilitate.

> with massive historical and experimental context already too.

I can argue this point either way. I haven't looked at mDNS closely enough to
have an opinion about it. OTOH, I'm pretty sure LLMNR has missed the mark
rather badly, irrespective of whether the right solution is separation by
interface or separation by naming convention.

				Ned