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

[Peter Dambier <[e-mail]>]

Keith Moore wrote:
>>What is this document for? No one has implemented this LLMNR protocol. No 
>>one has any plans to implement this protocol. No company plans to ship 
>>products using this protocol. Even Microsoft has not even hinted at plans 
>>to use LLMNR in Longhorn/Vista. 
> 
> 
> I don't see anything in RFC 2026 criteria that hinges on whether
> Microsoft intends to implement a protocol.
> 

I have seen windows boxes use it. They left traces on our root servers
and they cried when we hit them treating ".local" like "localhost"

It was windows users who complained not Macintoshes.

> Local name lookup is useful, but trying to overload DNS names to serve
> two different purposes, without breaking apps and/or making DNS appear
> to be inconsistent, is fairly difficult.  There's an inherent conflict
> between wanting local name lookup to be transparent to apps
> (perhaps even by changing the semantics of existing and well-established
> APIs to do local lookup in addition to DNS lookup), and having the two
> lookup services produce inconsistent results (thus confusing apps that
> quite reasonably expect that they should be consistent).  If you try
> to make the two kinds of names look different you risk breaking apps
> that expect everything to look like a DNS name.  And if you overload
> DNS syntax then you subject DNS servers to bogus queries.  
> 

Bogus queries do sabotage our root servers. They make 90% of our traffic.
That is what "root-servers.net" say. I have seen traffic reduced on
"a.public-root.net" by some 25% when we showed them a dummy for ".local".

> The primary reason IETF exists is to try to sort out those kinds of
> conflict in an open, neutral setting. 
> 
> For whatever reason, you chose to ship code without waiting for IETF to
> finish its deliberations on how to resolve those conflicts. Maybe you
> were right to do so.  I wish I could say that IETF always produces
> superior results, but we all know that it desn't always succeed.  And
> yet, by doing so you were essentially disregarding others' legitimate
> concerns about the problems associated with your approach, and/or
> unilaterally deciding, on behalf of not only your customers but
> everyone who might be affected by deployment of your protocol, that you
> are in a better position to know what is good for them than everyone
> else who participated in IETF.

They are restricted to their local LANs. I have never seen them in the
wide, wild internet.

> 
> Now you are arguing  that people who attempted to consider a wide range
> of input, and to do a responsible job of engineering a DNS-compatible
> name lookup solution should abandon the results of their efforts in
> favor of your ad hoc solution, merely because you were irresponsible
> enough to ship it in product before the issues were widely understood
> and the conflicts resolved in an open forum.
> 
> Well, maybe you're right, and maybe mDNS is better than LLMNR.  Or
> maybe mDNS is only slightly worse, and not enough worse to make it
> worth the confusion that standardizing LLMNR will create.  But you're
> not going to convince anybody of that with your current line of
> argument.
> 
> IMHO, if you can't provide a thorough analysis indicating that mDNS
> works better than LLMNR,  that mDNS resolves those conflicts in a
> superior way to LLMNR, and that your solution will do less harm to
> applications and DNS consistency than LLMNR, and that mDNS conforms to
> 2026 criteria, you don't have much of a gripe, and you certainly don't
> have justification for saying that LLMNR should be abandoned.
> 
> You ask about running code.  Running code is useful.  A single
> impelmentation serves as a proof of concept.  Multiple implementations
> derived from a single spec and tested against each other serve as a
> clarity check on the specification.  But mere existence of running code
> is not a reliable indicator of sound design.  In the ARPAnet days, when
> there were only a few dozen hosts, a few interoperability tests were
> generally enough to give a reliable indication of full-scale behavior.
> In an Internet with a billion hosts, producing an implementation is
> just a baby step.  These days, there's no substitute for thorough
> analysis of the effect of a protocol based on a large number of use
> cases.  So mDNS's running code and deployment do not trump LLMNR, and a
> comparison of mDNS and LLMNR implementations would not yield much
> useful data unless one were grossly more inefficient than the other.
> 

I'd say 25% of traffic on root servers is grossly inefficient and it does
violate a couple of RFCs.

> 
> As for this Last Call - I think there are two questions that should be
> asked:
> 
> 1. does LLMNR meet 2026 criteria?  no known technical omissions,
> conflicts resolved, etc. 
> 
> 2. is LLMNR enough better than mDNS to make it worth approving it as a
> standard even though mDNS exists and has some limited deployment?   If
> the answer to #1 is yes, then I suspect the answer to #2 is also yes,
> but an explanation is needed.
> 
> Furthermore, if there is rough consensus, supported by analysis, that
> mDNS is harmful, then we ought to consider saying that.  But we
> shouldn't make this statement critical path for getting LLMNR out the
> door.
> 
> Keith
> 

Regards,
Peter and Karin

-- 
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
[phone] (Telekom)
[phone] (O2 Genion)
[phone] (VoIP: sipgate.de)
[phone] (VoIP: freeworldialup.com)
mail: [e-mail]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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