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

From: Stuart Cheshire <[email-masked]>
Date: Thu, 25 Aug 2005 18:53:12 -0700

>It is not typical for us to make statements in our standards 
>regarding what proprietary mechanisms our standards are or are not 
>intended to compete with, nor do we typically include statements that 
>compare the features of our standards to proprietary protocols.

Please stop calling it "proprietary". The mDNS specificiation is publicly 
available, and is the result of many years of open public discussion. 
There are multiple independent open source implementations. Just because 
a certain IETF inner circle decided to turn their backs on it doesn't 
make it proprietary.

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: Margaret Wasserman <[email-masked]>
Date: Fri, 26 Aug 2005 00:18:42 -0400

Hi Stuart,

I'm sorry.  I didn't mean to be insulting...

We don't typically include statements about how we compete or don't 
compete with any non-IETF protocols, including de-facto standards 
and/or standards from other standards groups, as that is more of a 
marketing discussion than a technical discussion.

If there is a technical concern regarding interoperability or 
compatibility with an existing de-facto/industry standard, that might 
be included.  But I don't think that is what you are asking for, is 
it?  If it is, could you let us know what the technical issues are 
that should be documented?

Margaret

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 26 Aug 2005 09:20:55 +0200

On Thu, Aug 25, 2005 at 06:53:12PM -0700,
 Stuart Cheshire <[email-masked]> wrote 
 a message of 20 lines which said:

> Please stop calling it "proprietary". 

"A proprietary solution by any other name would still be proprietary"
:-)

> The mDNS specificiation is publicly available, and is the result of
> many years of open public discussion.  There are multiple
> independent open source implementations.

It is not sufficient to make it an open standard (by your criteria,
Java or PDF would be non-proprietary). The most important criteria is
the fact that the specification is NOT controlled by any given private
entity.

---

From: Marc Manthey <[email-masked]>
Date: Fri, 26 Aug 2005 10:00:39 +0200

On Aug 26, 2005, at 9:20 AM, Stephane Bortzmeyer wrote:
>  The most important criteria is

is that enought  to show thats not "proprietary" ?

http://www.macdevcenter.com/pub/a/mac/2004/08/31/osx_java.html
http://www-unix.mcs.anl.gov/fl/research/accessgrid/bonjour-py/bonjour- 
py.html
http://sourceforge.net/projects/swig/
http://rubyforge.org/projects/dnssd/

cheers

have a great day

P.S. can you show me some free LLMNR implementations?

-- 
"Wer also allgemeine Aufklärung verbreitet, verschafft zugleich eben  
dadurch allgemeine wechselseitige Sicherheit, und allgemeine  
Aufklärung und Sicherheit machen Fürsten und Staaten entbehrlich.  
Oder wozu braucht man sie sodann?"

Les Enfants Terribles
www.let.de

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 26 Aug 2005 10:17:07 +0200

On Fri, Aug 26, 2005 at 10:00:39AM +0200,
 Marc Manthey <[email-masked]> wrote 

> is that enought  to show thats not "proprietary" ?

It has nothing to do with the criterium I expressed. You just said
that Bonjour / Rendez-vous has several free (as in free speech, not as
in free beer) implementations, something that Stuart Cheshire already
said several times.

> http://sourceforge.net/projects/swig/

Why this one?

> P.S. can you show me some free LLMNR implementations?

I do not think there is one yet.

---

From: Russ Allbery <[email-masked]>
Date: Fri, 26 Aug 2005 02:08:21 -0700

Stephane Bortzmeyer <[email-masked]> writes:

> It is not sufficient to make it an open standard (by your criteria, Java
> or PDF would be non-proprietary). The most important criteria is the
> fact that the specification is NOT controlled by any given private
> entity.

If you go look at the documents that Stuart posted references to, you will
find:

| 21. Copyright Notice
| 
|    Copyright (C) The Internet Society (2005).
| 
|    This document is subject to the rights, licenses and restrictions
|    contained in BCP 78, and except as set forth therein, the authors
|    retain all their rights. For the purposes of this document,
|    the term "BCP 78" refers exclusively to RFC 3978, "IETF Rights
|    in Contributions", published March 2005.

In other words, they're exactly as controlled by a given private entity as
any other IETF work.  Is the IETF a private entity?  Is SMTP controlled by
the IETF?

I think your criteria doesn't survive logical scrutiny.  If other people
have access to the standard, can implement the standard, and can build on
the standard to create a newer revision of it, I can't imagine what
definition of "proprietary" you're using that would apply.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Aug 2005 13:29:03 +0200

Russ Allbery wrote:
...
> definition of "proprietary" you're using that would apply.

But mDNS is not on the standards track and LLMNR is proposed to be
on the standards track. That, I think, is why Stuart has raised the issue.

As long as they are Internet-Drafts they all have the same status, work
in progress, except that LLMNR has gained WG consensus.

    Brian

---

From: Bill Manning <[email-masked]>
Date: Fri, 26 Aug 2005 06:54:57 -0700

there is a fairly extensive history of multicast DNS...
in 1998/1999, along w/ this draft:

Woodcock, B., Manning, B., "Multicast Domain Name Service",
	draft-manning-dnsext-mdns-02.txt,  August 2000.  Revied twice now 
Expired.

was this one:

Vixie, P., Manning, B., "Supporting unicast replies to multicast 
queries in the DNS",
	draft-manning-opcode-discover-01.txt,  First submitted as an ID July 
2000 - Active

With this abstract.

0. Abstract:

    The QUERY opcode in the DNS is designed for unicast. With the
    development of multicast capabilities in the DNS, it is desireable
    to have a more robust opcode for server interactions since a single
    request may result in replies from multiple responders. So DISCOVER
    is defined to deal with replies from multiple responders.

    As such, this document extend the core DNS specifications to allow
    clients to have a method for coping with replies from multiple
    responders. Use of this new opcode may facilitate DNS operations in
    modern networking topologies. A prototype of the DISCOVER opcode
    was developed as part of the TBDS project, funded under DARPA grant
    F30602-99-1-0523.

... so multicast DNS has been around, with various implementations over 
the years.
the Apple mDNS spec is not an IETF work product, in part because the 
IETF rejected
it.  Same w/ the DARPA mDNS work I did six years ago.  I believe that 
Bernard and
his team are where they are because they had the patience and money to 
wait out a
multi year IETF standardization effort.   I ran out of money, Apple 
wanted to ship solutions.
(i think)...   the Apple specs are available as are the mDNS specs.  
neither is proprietary.

that said, i think it is reasonable for the IETF to provide its 
imprinture on LLMNR as an IETF
standards track activitiy for naming on a link-local environment.  The 
work has not violated the
processes, has met all the IETF criteria and should proceed. Pretty 
much a clear case of a protocol
designed by committee.  And its not like anyone will use it of course.
Even Microsoft appears to have abandon it.

--bill

---

From: "Marshall Eubanks" <[email-masked]>
Date: Fri, 26 Aug 2005 11:05:27 -0400

On Fri, 26 Aug 2005 06:54:57 -0700
> in 1998/1999, along w/ this draft:
<snip>
> Even Microsoft appears to have abandon it.

I am perhaps just being slow and dim-witted after minor surgery, but why
should a protocol that no-one will use be standards track ?

This discussion is beginning to remind me of the scientific standards processes involving the Soviet
bloc that I was involved with during the Cold War. That is not a good sign...

Regards
Marshall Eubanks

---

From: Keith Moore <[email-masked]>
Date: Fri, 26 Aug 2005 11:21:06 -0400

> should a protocol that no-one will use be standards track ?

Why should we accept a few (mostly axe-grinding) peoples' assertions 
that no-one will use it?

Keith

---

From: Ian Jackson <[email-masked]>
Date: Fri, 26 Aug 2005 16:50:48 +0100

> on the standards track. That, I think, is why Stuart has raised the issue.

I'm finding this discussion quite disturbing.  It seems that the
proposal is that the IETF should bless LLMNR because LLMNR is on the
Blessing Track.

Surely the reasons for the IETF to bless LLMNR as opposed to mDNS
should be based on technical details and deployment experience ?  In
which case it seems clear that mDNS is far superior.  It's more widely
deployed, more widely implemented, and not COMPLETELY INSANE !

Sorry to be pejorative, but as a DNS implementor[1] I'm amazed to find
senior IETF/IESG people seriously contemplating the kind of namespace
confusion which is fundamental in the LLMNR protocol design.

The mDNS approach at least isolates the damage (if you consider it
damage) to a specific subregion of the DNS, which you can choose to
have on your search path or in your configuration - or not.

It's a shame they chose `.local' (which was previously thought to be
reserved for local system administrators) but that's too late to
change now.  This mistake has happened in part because the relevant
IETF WG failed to properly engage with the mDNS authors !

I'm in general not a big fan of zeroconf, multicast, or anything else
you might think of as weirdo DNS extensions.  I'm something of a
luddite.  But if we're going to have an IETF-standardised protocol to
address this problem area, surely we should choose the protocol that's
(a) widely deployed, (b) technically superior and (c) less weird ?

I haven't read the drafts in detail, but I have read the LLMNR FAQ,
expecting to find a biased account of the differences which would lead
me to want to read the other side of the story.  But in nearly all of
the cases, I found myself disagreeing with the LLMNR way of doing
things, despite the best efforts of the text I was reading !

>From what I can see it might be more accurate to say that the DNSEXT
WG has been captured by people who have a bee in their bonnet about
killing mDNS, or who are at the very least badly misguided.

Ian.
(not usually a fan of people making wild-sounding statements about
 IETF WG conspiracies, either!)

[1] GNU adns, http://www.chiark.greenend.org.uk/~ian/adns/

---

From: Russ Allbery <[email-masked]>
Date: Fri, 26 Aug 2005 10:36:54 -0700

Ian Jackson <[email-masked]> writes:

> I'm finding this discussion quite disturbing.

You're not the only one, and I'm not even directly affected by this
decision.

> It seems that the proposal is that the IETF should bless LLMNR because
> LLMNR is on the Blessing Track.

> should be based on technical details and deployment experience ?

Amen.

I recognize that apparently a lot of DNS working group members are
apparently not fond of mDNS for some reason.  That's an important opinion
and should be respected.  However, widespread, existing *successful*
deployment is also a very strong argument and should also be respected.  I
personally tend to give it somewhat more weight than theoretical
arguments, unless the theoretical arguments are *very* strong.

At the very least, I would find it extremely disappointing and contrary to
the needs of the consumers of IETF standards if LLMNR were approved
without attention to interoperability with the existing mDNS deployed base
(which doesn't mean necessarily having interoperability, but it does mean
explaining how existing mDNS installations should deal with LLMNR) and
without a very clear explanation of why the already widely deployed
solution was not standardized instead of standardizing a different
protocol.

Presumably the DNS working group has some incredibly strong arguments that
trump running code or they wouldn't have made the choices that they have.
Let's see them, and furthermore, let's see them *in the document* or at
least in a supporting informational document, since those of us on the
IETF mailing list are certainly not the only people who are going to have
that question.  Implementors are going to have to choose which protocols
to use, and right now they're being given very little useful guidance and
justification by the DNS working group as near as I can tell.

---

From: Bill Manning <[email-masked]>
Date: Fri, 26 Aug 2005 11:28:44 -0700

> justification by the DNS working group as near as I can tell.

	to be fair, the mdns work was work looking for a home in the
	IETF.  DNSEXT at the time had a couple dozen work items at
	the time and was not prepared to take on something this radical.
	There were a couple of BOFs to see if we could spin up a new WG
	for this .... which in my feeble memory turned into zeroconf WG.

	then there was the debate over if this was DNS or something else...
	Stewart & I took the stance, yes it was/is.  Bernard/LLMNR bowed
	to the pressure to not call it DNS - (hence the goofy name) ....
	My grant over and Stewart ready to ship, we kind of let this IETF
	thing slide....

	only after all this did the LLMNR work get "grafted back" into the
	DNSEXT wg...  even tho it was not really DNS by then.

	So i don't think it is fair to dump on the DNSEXT wg members.  This
	stuff was pretty much gell'ed before it got to them.

--bill

---

From: Rob Austein <[email-masked]>
Date: Fri, 26 Aug 2005 15:36:36 -0400

At Fri, 26 Aug 2005 11:28:44 -0700, Bill Manning wrote:
> 	Stewart & I took the stance, yes it was/is.

Yep, this was the original sticking point.  In particular, there were
folks (myself among them) who felt strongly that:

1) Whatever this thing was, it should not run on the same port as
   normal DNS; and

2) Whatever this thing was, cached answers from it should not be
   mingled with cached answers from normal DNS.

The usage model for this multicast thing is very different from normal
DNS (every node for itself vs hierarchical, totally different models
for what constitutes authoritative data, totally different security
models, etc).  To me, this is enough to make it a different protocol
that happens to reuse some DNS data formats.

Unfortunately, even getting agreement on that much (that it was a
different protocol) was hard, in part because some participants
believed this whole thing should be as simple as putting a multicast
address into their /etc/resolv.conf files.  Sigh.  By the time we
achieved rough consensus that DNS and this other thing were different
protocols to be run on different ports with separate caches,
discussion had already become fairly polarized.

I happen to think that both mDNS and LLMNR crippled themselves by
attempting to wedge a totally different protocol into a DNS-like
framework (a lot of the DNS semantics make no sense in this different
usage model, so the developers of these protocols had to figure out
what to do for all the cases where the packet format expressed
something that had no analogue in the new protocol), but that's what
the proponants chose to do.  Their call, and hey, I could be wrong.

What I did care about was preventing leaks between normal DNS and this
other stuff.  Unless something changed since the last time I checked,
both mDNS and LLMNR use different ports and different caches from
normal DNS, so I have no problem with either one on this score.

Subsequent parallel development of LLMNR and mDNS was just weird, and
I mostly stayed out of it because my main concerns had already been
addressed.  There have been several attempts to reconcile the two
protocols, but in the end neither camp seems willing to budge.  The
differences between the two protocols have been discussed, several
times, in mind-numbing detail, all of which is available in the
namedroppers archives and the LLMNR issue tracker for anybody with the
intestinal fortitude to wade through it.

So, like Stuart, I find this mess sad and disturbing, but, unlike
Stuart, I don't see major harm (either way) with LLMNR.  It would have
been nice to have one protocol, but the people involved couldn't
settle their differences.  That happens sometimes.  Vendors who think
LLMNR is a better idea than mDNS are going to implement it anyway,
whether the IETF blesses it or not.  If the network effect (economic
sense) is going to make mDNS win no matter what happens with LLMNR, it
won't matter whether the IETF has blessed LLMNR or not.

So the only thing I see left for the IETF to decide is whether we're
going to continue arguing about this for another N years.

Let's not.

--Rob

["Little-Endians are Little-Endians and Big-Endians are Big-Endians
  and never the twain shall meet.

 "We would like to see some Gulliver standing up between the two
  islands, forcing a unified communication regime on all of us.  I do
  hope that my way will be chosen, but I believe that, after all,
  which way is chosen does not make too much difference.  It is more
  important to agree upon an order than which order is agreed upon.

 "How about tossing a coin?"

  --Danny Cohen, IEN 137, "On Holy Wars and a Plea for Peace"]

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 26 Aug 2005 17:59:14 -0400

In message <[email-masked]>, Ian Jackson writes

>confusion which is fundamental in the LLMNR protocol design.

What I find amusing is so many people asking the IESG to overrule a 
WG's judgment, given how many people have complained about the IESG's 
power to do exactly that.  I haven't checked for overlap between the 
two groups...

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Pete Resnick <[email-masked]>
Date: Fri, 26 Aug 2005 19:38:12 -0500

On 8/26/05 at 5:59 PM -0400, Steven M. Bellovin wrote:

>WG's judgment, given how many people have complained about the 
>IESG's power to do exactly that.  I haven't checked for overlap 
>between the two groups...

I have never heard anyone complain about the IESG overruling a WG's 
judgement *based on IETF Last Call comments*. That's the IESG 
determining that there is lack of consensus in the IETF as a whole 
for the document to go forward. Now, that probably indicates a 
different sort of failure (not enough early outside review during the 
WG process), but I don't think there's any complaining about the IESG 
making that sort of determination.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated

---

From: [email-masked]
Date: Fri, 26 Aug 2005 15:41:08 +0000

> Why should we accept a few (mostly axe-grinding) peoples' assertions 

	we shouldn't.  LLMNR has waded through the lengthy IETF standardization
	process to get to where it is.  That Microsoft has been patient and spent
	the money needed to keep people on this task long enough to get it here
	should be rewarded with the IETF imprinture.  Of course even Microsoft has
	hedged its bets (even they are aware of the need to ship products) wrt
	LLMNR.  But that is no reason for the IETF to not sanction this work.
	
--bill

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Aug 2005 14:53:45 +0200

> proposal is that the IETF should bless LLMNR because LLMNR is on the

It's been duly submitted by a WG and Last Called, so we *must*
consider it for the standards track. I can't tell you what the result
of that consideration will be; my crystal ball is down.

> should be based on technical details

Yes, except that we don't "bless", we approve publication (or not).

> and deployment experience ? 

Strictly speaking, no - not for Proposed Standard status. But
implementation and deployment experience is always valuable input.

> In

Can you spell that out please? Since it uses a different port number,
where does the confusion occur?

     Brian

---

From: Peter Dambier <[email-masked]>
Date: Mon, 29 Aug 2005 17:48:10 +0200

[email-masked] wrote:
> 
> 	LLMNR has waded through the lengthy IETF standardization

How about a protocol to remotely control the explosion of bombs. It could
even be built on top of LLMNR. It is not necessaryly more harmful than
LLMNR. Nobody intends to build bombs anyhow not to mention remotely explode
them. So would you consider publishing this protocol harmful?

Terrorists - I am sorry, weapons researches have spent a lot ...

We should really reward them by publishing this parodicol :)

Is that what you meant?

Regards
Peter

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

---

From: Russ Allbery <[email-masked]>
Date: Mon, 29 Aug 2005 11:27:39 -0700

bmanning <[email-masked]> writes:

> 	we shouldn't.  LLMNR has waded through the lengthy IETF
> 	standardization process to get to where it is.  That Microsoft has
> 	been patient and spent the money needed to keep people on this
> 	task long enough to get it here should be rewarded with the IETF
> 	imprinture.

I completely disagree with this.  The purpose of the IETF approval process
is to ensure that the result is a good standard, not to reward people for
being patient.  People can and have been very patient about *bad ideas*;
they still shouldn't be published.

If LLMNR is a good protocol with solid reasons for not going with the
existing de facto standard, then by all means it should be published.
However, it absolutely should not be published simply because Microsoft
(or any other company or organization) has been patient and spent money.

---

From: Ian Jackson <[email-masked]>
Date: Tue, 30 Aug 2005 11:33:41 +0100

> where does the confusion occur?

What does the port number have to do with it ?  That's an
implementation detail (from the point of view of this complaint; many
other complaints might well be about these kind of details).

The LLMNR model supposes that when an application asks for data of a
certain type associated with a certain name (ie, when the application
thinks it's asking for a DNS query) answers may come from either the
real DNS system or, even if the real DNS is authoritative for the
relevant name but denies that it exists, from LLMNR.

See draft-ietf-dnsext-mdns-42 s2 bullet point [2].

It is not true that separating LLMNR out on a different port, and
introducing other incompatibilities, prevents confusion between LLMNR
and the real DNS.  Applications will still see a bizarre mix of real
and LLMNR data.

On the other hand, mDNS has a much better scheme: the mDNS
specification defines the tree under `.local' for mDNS use.  Names in
.local are looked up with mDNS and names elsewhere via the real DNS.
This means that applications always either see the data intended for
them, or (transient) failure if the relevant mechanism isn't
available.

Stuart Cheshire makes IMO a very cogent argument in
<[email-masked]>, where he says:
] What's weird about LLMNR is that it blurs what's global and what's local.
] With LLMNR you can call your television "tv.ietf.org" if you want, and as
] long as the IETF's name server returns NXDOMAIN (which it does today)
] then a LLMNR-compliant host will fail over to local multicast and resolve
] that name to your television's address. This sends a very strange message
] to end users -- it suggests they can use any name they want in any domain
] they want without having to communicate with any registry. It also means
] that every failed DNS query will result in a LLMNR multicast on the local
] network, and (worse) every intentional LLMNR query needs to be preceded
] by a failed DNS query to some unsuspecting DNS server somewhere.
] 
] mDNS says that "local" is a free-for-all playground where anyone can use
] any name and no one has any more right to a particular name than anyone
] else. LLMNR didn't want to do that, but what they've effectively ended up
] doing instead is saying that the root of the DNS namespace (and
] everything below it) is a free-for-all playground where anyone can use
] any name they want.

In addition, mDNS's limitation to `.local' means that deliberate
additional incompatibilities to avoid cache pollution in the real DNS
is not necessary; since mDNS is only used for names in `.local',
normal precuations against unsolicited DNS replies will prevent the
main DNS namespace being polluted with mDNS data.

If we are to so strongly fear pollution, mDNS's wide deployment ought
to provide some evidence for this from operational experience !  Where
is that evidence ?

Ian.

---

From: Peter Dambier <[email-masked]>
Date: Tue, 30 Aug 2005 16:08:43 +0200

>>where does the confusion occur?

The confusion occurs on the root servers.

I dont really know if it was some LLMNR enabled windows machine, but
they definitely asked DNS first and on port 53. If we supply a dummy
zone like we do for localhost then those boxes do break.

> relevant name but denies that it exists, from LLMNR.

You name it: The implementation asks DNS for garbadge.local and if we
say 127.0.0.1 then windows breaks.

If we dont supply the krutch then 25% of our root server traffic is
for .local because they repeat their question again and again on all
13 if the root servers.

> to provide some evidence for this from operational experience !  Where

mDNS is mostly free of bugs. The dont ask DNS for garbage.local . That is
why we dont see them.

Regards,
Peter Dambier

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Aug 2005 17:01:26 +0200

Peter,

I'm afraid I don't understand. As far as I can understand,
mDNS uses the .local pseudo-domain and LLMNR does not.
So how can LLMNR be blamed for bogus queries for *.local?

I can easily configure my Windows box to default to *.local.
But why would I want to?

    Brian

Peter Dambier wrote:
> Ian Jackson wrote:
> 
>> Brian E Carpenter writes ("Re: Last Call: 'Linklocal Multicast Name 
>> Resolution (LLMNR)' to    Proposed  Standard"):
>>
>>> Ian Jackson wrote:
>>>
>> ] ] mDNS says that "local" is a free-for-all playground where anyone 
>> can use

---

From: Peter Dambier <[email-masked]>
Date: Tue, 30 Aug 2005 18:42:52 +0200

> So how can LLMNR be blamed for bogus queries for *.local?

I cannot garantie it was LLMNR. I was told these are windows boxes
using the default enabled LLMNR and it defaults to ".local". I know
that newer windows boxes do have LLMNR but it is not normally used.
Nevertheless it comes up.

MAC systems with mDNS may use ".local" too but they never ask for
".local" via DNS. They stay with mDNS on the direct link.

It was only windows boxes who complained when we returned 127.0.0.1
for *.local

> I can easily configure my Windows box to default to *.local.

The problem is that windows users plug their box in and cry if it does
not work. They dont know how to configure or why.

Well, if you do not use ".local" on your box why not try ".com" ?
It might be fun. :)

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 30 Aug 2005 13:48:42 -0400

Hi Brian,

>So how can LLMNR be blamed for bogus queries for *.local?

The .local doesn't come from either mDNS or LLMNR...  The user types 
it and/or an application includes it in the domain name look-up.  So, 
if the user tries to look up "twiki.local", what happens?  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

---

From: Ian Jackson <[email-masked]>
Date: Wed, 31 Aug 2005 18:49:15 +0100

> specially, so this just goes out as a link-local request.

This is fine and as intended, of course.

> lookup for "twiki.local", which will fail.  Then, a link-local name 

This is not fine, as Peter Dambier's experience shows.  Firstly, it
generates unwanted queries up towards the DNS root (apparently in
large numbers, too!).  Secondly, if measures are taken to get rid of
that unwanted root server traffic, by having (for example) an ISP's
caching DNS proxies return 127.0.0.1 or some other answer that the
querier will accept, the querier breaks.

Why does the querier break ?  Well precisely because of the namespace
confusion I was just talking about.  The querier assumes - without any
kind of justification - that queries for .local (or whatever other
domain the LLMNR administrator has chosen) will always be happily
answered with NXDOMAIN by the `real' DNS as seen from the end system.

> DNS query if I did a DNS lookup for "isoc.frog".

LLMNR _insists_ on you picking _some_ part of the DNS space and then
abusing it this way.

Think broader than just the exact effect of the resolution protocol.
With any kind of resolution protocol - even with normal DNS - there
are decisions to be made about which names to configure in hosts.
Those names will then be used for DNS (or DNS-like) lookups.

It is true that all of these systems - full DNS, mDNS and LLMNR - will
generate bogus DNS queries if systems are configured with bogus names.

Part of the mDNS protocol is the expectation that you will configure
your hosts to expect certain services to be provided at names in
`.local'.  If mDNS were an IETF protocol then the RFC would come with
an IANA action to allocate mDNS the `.local' TLD - and, de facto, the
deployment of mDNS has meant that any other use of `.local' is now
difficult or impossible.  You may argue that this was wrong, but the
mDNS authors did try to get their very sensible protocol put through
the IETF process and were told where to go.  That's a failure of the
whole IETF, not just of the mDNS authors.

But only LLMNR _encourages_ (maybe even requires) you to configure
your systems with bogus names !  LLMNR hosts will _always_ generate
bogus DNS queries for these nonexistent names, and they will always
break if and when the real DNS suddenly provides data for those names
(either because the relevant nameserver operators are fed up of the
query traffic, or because in their wisdom - the namespace belongs to
them after all - they've decided to publish some data they themselves
want to use).

The bogosity of the names in LLMNR is quite different from the problem
(if there is a problem) with mDNS.  With mDNS the functionality - or
the brokenness, if you prefer to look at it like that - is confined to
.local.  It neither affects mDNS hosts' view of `normal' internet DNS
names, nor generates queries to normal internet DNS servers.

Ian.