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

[Henrik Levkowetz]

on 2005-08-31 05:40 Jeffrey Hutzelman said the following:
> 
> On Tuesday, August 30, 2005 15:55:56 -0700 Ned Freed 
> <[EMAIL PROTECTED]> wrote:
> 
>> IMO this needs major work even before being approved as experimental. The
>> overlapped namespace approach in particular seems hugely problematic and
>> IMO needs to be replaced.
> 
> I've only read this document briefly, but based on what I've seen and on 
> the descriptions and explanations in the current discussion, I have to 
> agree.  The overlapped namespace approach has significant problems, which 
> have been mentioned here.  It generates load in the form of additional 
> queries on caching servers and on the global DNS roots for names those 
> servers are never expected to be able to resolve, and in the form of 
> multicast traffic on the local link for potentially every failed query 
> against the global DNS.
> 
> 
> It also creates massive ambiguities in the namespace, by allowing any host 
> on the local link to claim any global DNS name which happens not to resolve 
> at the moment (even if due to a temporary failure).  This means that names 
> which are intended to be part of the global DNS namespace may resolve 
> differently depending on one's location, or what hosts might be responding 
> to LLMNR requests on the local network.
> 
> This is a problem so egregious that the IAB wrote a document about it 
> (RFC2826).  While the majority of that document pertains specifically to 
> recurring "alternate root" proposals, much of it applies equally well here 
> -- "alternate roots" are a bad idea because they split what needs to be a 
> single global namespace into several alternate namespaces.  The use of the 
> overlapped-namespace approach with LLMNR does the same thing, only instead 
> of creating a few alternate roots, it creates millions.

Good summaries, good points.

I do not believe the LLMNR specification should be published in
its current form; the namespace confluence is extremely bothersome,
and should not be accepted even for publication as an experimental
RFC.

Even if the namespace confluence problem is corrected, it seems
more appropriate - given the deployment of mDNS - to publish both
mDNS and LLMNR as experimental RFCs.

Henrik.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I-D ACTION:draft-sanz-rfc1032-historic-00.txt

[Frank Ellermann]

Harald Tveit Alvestrand wrote:
 
> 3912 was published in order to make it clear that the IETF
> is not making policy requirements

Some people incl. me consider NICNAME as an essential asset
of "the Net" (whatever that might be), like mail.  Perfectly
okay if somebody doesn't support mail, but many do, and then
they follow "the rules" (RfCs).  Or ignore them.  That's the
idea of "rfc-ignorant.org" as I understand it.

Disclaimer:  I'm only a user / contributor, don't agree with
everything RFCI does, don't represent RFCI, etc.  (No special
disclaimer, also true for the IETF and other "communities")

> some people had been misinterpreting the status of RFC 954
> as saying that the IETF had made such policy statements.

The RFCI Web pages talk about RfCs, not the IETF.  Apparently
954 is older than the IETF (?).  It was promoted to DS in 1140,
and replaced by 3912 last year...  oops, a DS replaced a DS, I
didn't know that that's possible.

> Publishing RFC 3912 is definitely IETF business.

Sure, I forwarded the "last call" to the RFCI list last year
hoping that they'd do "something", propose a better draft or
whatever, unfortunately nothing happened.

> But I don't see where the "dubious" part comes in.

The I18N part is dubious, as demonstrated by whois.denic.de
it is possible to support UTF-8 and even more MIME compatible
charsets.

The last statement in the "security considerations" is also
dubious, there's nothing wrong with "whois", it's only simple.

But the really dubious part from my POV was the intent to get
rid of the critical X in "954 - X = 3912".  Some users want
this X, and fortunately it's also covered by 1032 (plus 1591).

 Bye, Frank



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I-D ACTION:draft-sanz-rfc1032-historic-00.txt

[Stephane Bortzmeyer]

On Wed, Aug 31, 2005 at 10:00:41AM +0200,
 Frank Ellermann <[EMAIL PROTECTED]> wrote 
 a message of 44 lines which said:

> But the really dubious part from my POV was the intent to get rid of
> the critical X in "954 - X = 3912".  Some users want this X,

Every TLD has its own X. X should not be provided by the IETF. It is
completely outside of its technical standards-setting mission.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Peter Dambier]

Russ Allbery wrote:

Margaret Wasserman <[EMAIL PROTECTED]> writes:



Other than a few minor issues that are being dealt with in a -43 update,
I don't think that anyone has raised a blocking technical issue with the
LLMNR specification during this IETF LC.  If you (or anyone else) has
intended to raise a blocking technical issue, either with LLMNR itself
or with its ability to coexist with mDNS, please make that clearer to
me.




Sorry I overlooked this:

I dont count 25% of the root server traffic a minor issue.
With 90% of root server traffic used to be for localhost and with
25% of root server traffic already for local, we are looking into
a major DoS attack. This might overload ISPs DNS servers it might
even bring the root servers down if they let it free!



I'm getting the impression from the IETF list discussion that several
people do consider the behavior of querying regular DNS first for names
that will be handled by LLMNR to be a blocking technical issue.  I'm not
sure that I've reached the point where I would say that personally, but
the descriptions here have at least been concerning.

I think it is very useful to have a clear distinction between DNS
namespaces, with one namespace clearly identified as being link-local so
that people are not under the impression that they can use arbitrary DNS
domains for link-local resolution and so that software knows not to try to
resolve link-local names against regular DNS servers.  It sounds like mDNS
does this as part of the protocol specification.



On the other hand, the DNSEXT WG has worked for several years to produce
the LLMNR specification, and I don't see anything fundamentally wrong
with the mechanism that we have produced (people should respond to the
IETF LC if they see blocking technical issues). The authors of that
specification gave change control to the IETF community, and they have
gone through 40+ document iterations, working towards a document that
would achieve DNSEXT consensus.  That process was not followed for mDNS
(because it was not the chosen solution), and we currently only have one
document (LLMNR) that has reached IETF WG consensus and has been
submitted for standards publication.



As near as I can tell, the authors of the mDNS specification also gave
change control to the IETF community, so I wouldn't raise that as a
distinction.  The only distinction appears to be working group consensus;
the protocols otherwise look to be in the same place legally and
process-wise.



It is possible, in an IETF LC, that we could learn that we do not have
IETF consensus to publish something that was produced by an IETF WG.



At the moment, based on the discussion in the IETF list, I don't believe
that LLMNR should be published on the standards track unless mDNS is also
being published on the standards track and we agree we really want to have
two standards for this (which I think everyone is agreed would be bad).
Publishing them both as experimental and then seeing which gains more
general acceptance and works better in practice sounds reasonable to me.



I agree.

Regards,
Peter and Karin Dambier


--
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 PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Is it necessary to go through Standards Track to Get to Historic?

[Brian E Carpenter]

Bruce Lilly wrote:
...

Aside from the label -- and that's not a clear benefit because Historic is
ambiguous -- I don't see much difference between Historic and an
Informational RFC with a suitable IESG note (a "warning label" if you will).



There's a difference. For example, imagine a media type called

  splat/illogical

that's been used for some years but is generally considered to be
illogically named, and a new media type has been defined to do the
same thing:

  splot/logical

It would then be reasonable to document splat/illogical as Historic
to explain its IANA registration, and to document splot/logical as
Informational.

But you're certainly correct that a health warning in the text of
the RFC is more important than a status marker in the index.

   Brian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I-D ACTION:draft-sanz-rfc1032-historic-00.txt

[Frank Ellermann]

Stephane Bortzmeyer wrote:

>> But the really dubious part from my POV was the intent to
>> get rid of the critical X in "954 - X = 3912".  Some users
>> want this X,

> Every TLD has its own X.

Not limited to TLDs, IIRC 1591 proposes to apply X recursively.
So when I type 'rxwhois fr' I get the lines (truncated):

whois -h whois.iana.org fr

IANA Whois Service
Domain: fr
ID: fr
[...]
URL for registration services: http://www.nic.fr/
Whois Server (port 43): whois.nic.fr
[...]

Tons of other useful info snipped:  There are mail addresses
if something doesn't work, even phone numbers, the names and
IPs of the nameservers, the age of the TLD, and the last
update.  Depending on what you want all important, it's THE
source to manage hard cases of net abuse.

With 'rxwhois nic.fr' I'd get a similar output:

whois -h WHOIS.NIC.FR nic.fr
%%
%% This is the AFNIC Whois server.
[...]

> X should not be provided by the IETF.

Sure, I asked whois.iana.org / whois.nic.fr, not whois.ietf.org
- there's no whois.ietf.org (that could answer questions like
'whois -h whois.ietf.org 1046-ticket' ;-)

But apparently IANA, NIC.FR, and I have similar ideas what "X"
should be for domains.  That has to be documented somewhere,
and what you get is defined (several RfCs, 1032, 1591, 2901).

Which part of it you publish, and how you do this, is a second
question, the usual "your server, your rules" (or in that case
"your domains, your rules").  The traditional way is a whois
server - and that has also to be documented.  It is wrong to
obsolete these RfCs without proper replacement.  They are used.

> It is completely outside of its technical standards-setting
> mission.

With that idea you could also claim that RfCs should not talk
about postmaster@ or [EMAIL PROTECTED]  This cannot work.  I don't care
who publishs / maintains these RfCs, maybe ICANN should do it.

Or each TLD publishs its own rules as RfC - but OTOH that would
be stupid if they are all essentially identical except from the
details reported by 'whois -h whois.iana.org '.

  Bye, Frank



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I-D ACTION:draft-sanz-rfc1032-historic-00.txt

[william(at)elan.net]

On Wed, 31 Aug 2005, Frank Ellermann wrote:


It is completely outside of its technical standards-setting
mission.


With that idea you could also claim that RfCs should not talk
about postmaster@ or [EMAIL PROTECTED]  This cannot work.  I don't care
who publishs / maintains these RfCs, maybe ICANN should do it.


I happen to agree with people who want to separate policy from
protocol specification. But I disagree that such policy-like 
recommendations as that its good to have "abuse@" mailbox have

no business with IETF. If I understand correctly IETF thinking is
that such recommendations should not go into STD track but into BCP.

As such if RFC1032 is being considered for moving to historic (which
may need to happen but I see no reason to do it right now and I think
it would be difficult because many other non-historic RFCs depend on
it), some of what is there that people think is relevant should be 
considered for new BCP RFC.


--
William Leibzon
Elan Networks
[EMAIL PROTECTED]

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I-D ACTION:draft-sanz-rfc1032-historic-00.txt

[Pekka Savola]

On Wed, 31 Aug 2005, Stephane Bortzmeyer wrote:

Every TLD has its own X. X should not be provided by the IETF. It is
completely outside of its technical standards-setting mission.


FWIW, the IETF mission statement (a BCP) (RFC3935) includes more than 
setting standards.  This was a very conscious wording choice when 
writing the document.


To quote:

   The mission of the IETF is to produce high quality, relevant
   technical and engineering documents that influence the way people
   design, use, and manage the Internet in such a way as to make the
   Internet work better.  These documents include protocol standards,
   best current practices, and informational documents of various
   kinds.

So, This "X" is not necessarily out of scope of the IETF mission, 
though it is a judgment call whether the criteria described above are 
met -- and whether it even makes sense to try to meet them.


--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Bill Manning]

On Aug 31, 2005, at 2:25, Peter Dambier wrote:


Russ Allbery wrote:

Margaret Wasserman <[EMAIL PROTECTED]> writes:
Other than a few minor issues that are being dealt with in a -43 
update,
I don't think that anyone has raised a blocking technical issue with 
the

LLMNR specification during this IETF LC.  If you (or anyone else) has
intended to raise a blocking technical issue, either with LLMNR 
itself

or with its ability to coexist with mDNS, please make that clearer to
me.


Sorry I overlooked this:

I dont count 25% of the root server traffic a minor issue.
With 90% of root server traffic used to be for localhost and with
25% of root server traffic already for local, we are looking into
a major DoS attack. This might overload ISPs DNS servers it might
even bring the root servers down if they let it free!



i'm going to have to raise the point that Peters "root-server" system
is his private "walled-garden" and not representative of the Internet's
authoritative root servers.   Just for clarification.

--bill


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Marc Manthey]

On Aug 31, 2005, at 12:50 PM, Bill Manning wrote:


On Aug 31, 2005, at 2:25, Peter Dambier wrote:

Russ Allbery wrote:


Margaret Wasserman <[EMAIL PROTECTED]> writes:

Other than a few minor issues that are being dealt with in a -43  
update,
I don't think that anyone has raised a blocking technical issue  
with the
LLMNR specification during this IETF LC.  If you (or anyone  
else) has
intended to raise a blocking technical issue, either with LLMNR  
itself
or with its ability to coexist with mDNS, please make that  
clearer to

me.



Sorry I overlooked this:

I dont count 25% of the root server traffic a minor issue.
With 90% of root server traffic used to be for localhost and with
25% of root server traffic already for local, we are looking into
a major DoS attack. This might overload ISPs DNS servers it might
even bring the root servers down if they let it free!




i'm going to have to raise the point that Peters "root-server"  
system
is his private "walled-garden" and not representative of the  
Internet's

authoritative root servers.   Just for clarification.

--bill



i want to correct  bills concern  that  , " peters public root server  
system" is

an alternative for  the existing ones  and there are several others .


-marc

http://www.public-root.com/


--
"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




smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Brian E Carpenter]

Peter,

Peter Dambier wrote:

Russ Allbery wrote:


Margaret Wasserman <[EMAIL PROTECTED]> writes:



Other than a few minor issues that are being dealt with in a -43 update,
I don't think that anyone has raised a blocking technical issue with the
LLMNR specification during this IETF LC.  If you (or anyone else) has
intended to raise a blocking technical issue, either with LLMNR itself
or with its ability to coexist with mDNS, please make that clearer to
me.





Sorry I overlooked this:

I dont count 25% of the root server traffic a minor issue.


Can you point to publicly available data about the rate of .local
queries to *all* the root servers (including the anycast servers)?

 Brian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I-D ACTION:draft-sanz-rfc1032-historic-00.txt

[Harald Tveit Alvestrand]

--On 31. august 2005 03:08 -0700 "william(at)elan.net" <[EMAIL PROTECTED]> 
wrote:



As such if RFC1032 is being considered for moving to historic (which
may need to happen but I see no reason to do it right now and I think
it would be difficult because many other non-historic RFCs depend on
it), some of what is there that people think is relevant should be
considered for new BCP RFC.


Just because I was curious, I used some time on this
Bill Fenner's tool  says 
(content descriptions mine, based on RFC index):


Documents that depend on: RFC1032

Depending document  Type of dependency
rfc1031 (Unknown)   rfc1032 (Unknown)   unknown MILNET ops
rfc1034 (Standard)  rfc1032 (Unknown)   unknown DNS spec
rfc1035 (Standard)  rfc1032 (Unknown)   unknown DNS spec
rfc1183 (Experimental)  rfc1032 (Unknown)   unknown DNS - more rectypes
rfc1348 (Experimental)  rfc1032 (Unknown)   unknown DNS NSAP RRs
rfc2052 (???)   rfc1032 (Unknown)   unknown DNS SRV
rfc1464 (Experimental)  rfc1032 (Unknown)   unknown DNS arbitary strings
rfc2053 (???)   rfc1032 (Unknown)   reference   AM domain ops
rfc1480 (???)   rfc1032 (Unknown)   reference   US domain ops
rfc1401 (Informational) rfc1032 (Unknown)   reference   Correspondence
rfc1386 (Informational) rfc1032 (Unknown)   reference   US domain ops
rfc1123 (Standard)  rfc1032 (Unknown)   reference   Host 
Requirements
rfc2065 (???)   rfc1032 (Unknown)   reference   DNSSEC original

Now if we agree that the operations documents and the corrspondence 
document are not critical, using the same logic as the logic used for 
dismissing RFC 1032, we have the following possibly interesting 
dependencies:


RFC 1034 - DNS base specs
 Reference: "Current policy for the top levels is discussed in [RFC-1032]."
 Reference: "While there are no particular technical constraints dealing 
with where in the tree this can be done, there are some administrative 
groupings discussed in [RFC-1032] which deal with top level organization, 
and middle level zones are free to create their own rules."


 Hardly a normative dependency.

RFC 1035 - DNS base specs
 Appears in reference list, but is not referenced in the text.
 Hardly normative.

RFC 1183 - DNS record types
 Appears in reference list, but is not referenced in the text.
 Hardly normative.

RFC 1348 - DNS NSAP RR
 Appears in reference list, but is not referenced in the text.
 This is getting to be familiar

RFC 2052 - DNS SRV
 Appears in

RFC 1123 - Host Requirements

6.1.4.1  DNS Administration

   This document is concerned with design and implementation
   issues in host software, not with administrative or
   operational issues.  However, administrative issues are of
   particular importance in the DNS, since errors in particular
   segments of this large distributed database can cause poor
   or erroneous performance for many sites.  These issues are
   discussed in [DNS:6] and [DNS:7].
  (DNS:6 is RFC 1032)

RFC 2065 - DNSSEC

  Appears in reference list, but is not referenced in text
   and of course this has been obsoleted by 2535, which is itself
  obsoleted.

(If the authors of draft-sanz want to, they are free to use the information 
above. it's all public info anyway.)


While I still don't see any reason to bother with changing "status UNKNOWN" 
to something else, I think the argument that "so many other RFCs depend on 
it" can be safely dismissed now - unless someone comes up with a real 
example of a NORMATIVE dependency on RFC 1032, of course. I could be wrong.


  Harald








pgpRj8EBBZ3OE.pgp
Description: PGP signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Marc Manthey writes:
>

>>
>> i'm going to have to raise the point that Peters "root-server" 
>> system
>> is his private "walled-garden" and not representative of the 
>> Internet's
>> authoritative root servers.   Just for clarification.
>>
>> --bill
>
>
>i want to correct  bills concern  that  , " peters public root server
>system" is
>an alternative for  the existing ones  and there are several others .
>
>
At the risk of starting down a tangent, the IETF does not, as a 
technical matter, accept the validity of so-called alternate roots.  
See RFC 2826.

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



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Jeroen Massar]

On Wed, 2005-08-31 at 13:14 +0200, Brian E Carpenter wrote:
> Peter,
> 
> Peter Dambier wrote:
> > Russ Allbery wrote:
> > 
> >> Margaret Wasserman <[EMAIL PROTECTED]> writes:
> >>
> >>
> >>> Other than a few minor issues that are being dealt with in a -43 update,
> >>> I don't think that anyone has raised a blocking technical issue with the
> >>> LLMNR specification during this IETF LC.  If you (or anyone else) has
> >>> intended to raise a blocking technical issue, either with LLMNR itself
> >>> or with its ability to coexist with mDNS, please make that clearer to
> >>> me.
> >>
> >>
> > 
> > Sorry I overlooked this:
> > 
> > I dont count 25% of the root server traffic a minor issue.
> 
> Can you point to publicly available data about the rate of .local
> queries to *all* the root servers (including the anycast servers)?

Check for only "K": http://k.root-servers.org/index.html#stats
Interresting one here is NXDOMAIN responses:
http://k.root-servers.org/stats/linx/xstats_SNXD-all.html
(note, that is only the LINX node)
It is a large part of the traffic and annoying, 0.763 k out of 2116 k
queries/sec. Interrestingly that since about June it started to decline
which could be because these real root-servers
(http://www.root-servers.org/) also have a project called AS112
(http://www.as112.net), which takes care of at least the reverse trees
for RFC1918 space.

For instance, the Italian node (http://frejus.itgate.net/as112/), run by
ITGate is seeing about 100 queries per second for their point of view.
The RIPE one (http://www.ripe.net/as112/) in Amsterdam does about 300
queries/s so it really depends on ones point of view.

For real details I suggest one to ask either Olaf Kolkman or Daniel
Karrenberg (both cc'd so they will not skip this message ;) or other
root-server operators who can shed way more light on this subject.

In short: having something query for known bogus domains is bad and
hurts the root-servers. It can be limited a bit, but not much.

Additional note: Making zones 'up' and making an 'alternate root' causes
that sometimes these zones leak into the real root, where they don't
exist. Eg this happens in misconfiguration cases or people publishing
the alternate root DNS names, which don't exist for the rest of the
world. That said having an alterante root is more disruptive than having
LLMNR.

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Brian E Carpenter]

Jeroen Massar wrote:

On Wed, 2005-08-31 at 13:14 +0200, Brian E Carpenter wrote:

...

Check for only "K": http://k.root-servers.org/index.html#stats
Interresting one here is NXDOMAIN responses:
http://k.root-servers.org/stats/linx/xstats_SNXD-all.html
(note, that is only the LINX node)
It is a large part of the traffic and annoying, 0.763 k out of 2116 k
queries/sec. 


That is about 1/3 of the total. It doesn't surprise me at all that
so many bogus queries arrive - everybody who mistypes a TLD or
misconfigures a default domain generates bogus queries, and this isn't
going to change. The question is whether .local is a *significant*
part of this load. The limited data I have suggest not, but I'd like
to see publicly available data: what fraction of those NXDOMAINs are
due to .local?

Brian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Peter Dambier]

Hi Bill,

I am speaking of this root-server system:

a.public-root.net.  900 IN  A   205.189.71.2
b.public-root.net.  900 IN  A   61.9.136.52
c.public-root.net.  900 IN  A   68.255.182.111
d.public-root.net.  900 IN  A   205.189.71.34
e.public-root.net.  900 IN  A   216.138.219.83
f.public-root.net.  900 IN  A   66.15.237.185
g.public-root.net.  900 IN  A   199.5.157.131
h.public-root.net.  900 IN  A   64.198.89.245
i.public-root.net.  900 IN  A   203.187.202.205
j.public-root.net.  900 IN  A   57.73.7.89
k.public-root.net.  900 IN  A   81.19.74.67
l.public-root.net.  900 IN  A   195.214.191.125
m.public-root.net.  900 IN  A   205.189.71.26

and I am beeing told by experts that there is no difference to
what other root-server operators have found on their servers.

ICANNed root-server operators look with interest into what
Public-Root has experienced because in the near future they will
have to support more domains than they do today. We do share
information.



I dont count 25% of the root server traffic a minor issue.
With 90% of root server traffic used to be for localhost and with
25% of root server traffic already for local, we are looking into
a major DoS attack. This might overload ISPs DNS servers it might
even bring the root servers down if they let it free!



i'm going to have to raise the point that Peters "root-server" system
is his private "walled-garden" and not representative of the Internet's
authoritative root servers.   Just for clarification.

--bill




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


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Peter Dambier]

Brian E Carpenter wrote:

Peter,

Peter Dambier wrote:


Russ Allbery wrote:


Margaret Wasserman <[EMAIL PROTECTED]> writes:


Other than a few minor issues that are being dealt with in a -43 
update,
I don't think that anyone has raised a blocking technical issue with 
the

LLMNR specification during this IETF LC.  If you (or anyone else) has
intended to raise a blocking technical issue, either with LLMNR itself
or with its ability to coexist with mDNS, please make that clearer to
me.






Sorry I overlooked this:

I dont count 25% of the root server traffic a minor issue.



Can you point to publicly available data about the rate of .local
queries to *all* the root servers (including the anycast servers)?

 Brian



Hi Brian,

I would really like to do.

We have been alarmed by ISPs that we did kill some customers applications
and we stopped publishing the ".local" immediately.

From the data gathered by our root-server operators at that moment we
estimate that the traffic for ".local" must have been some 25%

At this moment we have to sort out a couple of things but I promise
we will make our data publicly available soon.

Kind regards,
Peter and Karin Dambier

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


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Peter Dambier]

Steven M. Bellovin wrote:

In message <[EMAIL PROTECTED]>, Marc Manthey writes:


   i'm going to have to raise the point that Peters "root-server" 
system
   is his private "walled-garden" and not representative of the 
Internet's

   authoritative root servers.   Just for clarification.

--bill



i want to correct  bills concern  that  , " peters public root server
system" is
an alternative for  the existing ones  and there are several others .




At the risk of starting down a tangent, the IETF does not, as a 
technical matter, accept the validity of so-called alternate roots.  
See RFC 2826.


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



Dear Steven,

the Public-Root is not an alternative root but a solution.

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 PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Harald Tveit Alvestrand]

--On 31. august 2005 13:08 +0200 Marc Manthey <[EMAIL PROTECTED]> wrote:


i want to correct  bills concern  that  , " peters public root server
system" is
an alternative for  the existing ones  and there are several others .


Just being pedantic.

of course anyone can run any service he wants and call it anything he wants 
(modulo use of existing trademarks different rathole...)
But: Anyone who wishes to avail themselves of this service would be well 
advised to read RFC 2826 - "IAB Technical Comment on the Unique DNS Root".


When IETF documents refer to the DNS, I think it's a safe bet that they are 
intending to refer to the system under the single root that most people 
regard as "the root".


I don't think any of the fundamentals have changed in the last 5 years.

Harald

pgpZSQZleZ3Nm.pgp
Description: PGP signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Christian Huitema]

>  From the data gathered by our root-server operators at that moment we
> estimate that the traffic for ".local" must have been some 25%

A key technical difference between LLMNR and the initial MDNS proposal
is precisely that LLMNR has no concept of a ".local" top level domain.
Usage of LLMNR does not promote queries to this zone. 

This is indeed a key difference between LLMNR and MDNS. MDNS assumes
that there is a special zone for local names, which would be linked to
the topology. LLMNR assumes that names are independent of the topology,
that a host called "foo.example.net" retains the same name as it move to
different locations. There were ample debates of this point in the
working group, and the decisions to "not creating special names" and
"not linking names to topology" do reflect WG consensus.

-- Christian Huitema

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Paul Hoffman]

At 3:24 PM +0200 8/31/05, Peter Dambier wrote:

the Public-Root is not an alternative root but a solution.


 makes it very clear that this set 
of root-like servers intends to answer affirmatively and 
authoritatively for TLDs that the real/generally-accepted root 
servers would say do not exist. From the material on that page, it is 
also likely that, in the future, the NS records returned by these 
root-like servers for some TLDs will be different than those returned 
by the real/generally-accepted root servers.


In other words, the statement "the Public-Root is not an alternative 
root but a solution" seems dishonest  when one reads the material at 
the site describing the service.


--Paul Hoffman, Director
--VPN Consortium

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Paul Hoffman]

At 2:47 PM +0200 8/31/05, Brian E Carpenter wrote:

That is about 1/3 of the total. It doesn't surprise me at all that
so many bogus queries arrive - everybody who mistypes a TLD or
misconfigures a default domain generates bogus queries, and this isn't
going to change. The question is whether .local is a *significant*
part of this load. The limited data I have suggest not, but I'd like
to see publicly available data: what fraction of those NXDOMAINs are
due to .local?


The question maybe should be whether .local will become, not is, a 
significant part of this load. If you prevent mDNS, the main 
proponent of the .local namespace, from becoming a standard, the 
number of those names will remain low. If it becomes a standard and 
implementers use that namespace more, the load will of course 
increase.


--Paul Hoffman, Director
--VPN Consortium

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Christian de Larrinaga]

On Wed, 2005-08-31 at 15:24 +0200, Peter Dambier wrote:
>> Steve Bellovin wrote. 
> > At the risk of starting down a tangent, the IETF does not, as a 
> > technical matter, accept the validity of so-called alternate roots.  
> > See RFC 2826.
> > 
> > --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
> > 
> 
> Dear Steven,
> 
> the Public-Root is not an alternative root but a solution.
> 
> Kind regards,
> Peter and Karin
> 

not for everyone it isn't!
unless you think the solution is to sow confusion.


Christian de Larrinaga
Network Brokers Ltd



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Eric A. Hall]

On 8/30/2005 2:18 PM, Stuart Cheshire wrote:

> 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.

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. Hallhttp://www.ehsco.com/
Internet Core Protocols  http://www.oreilly.com/catalog/coreprot/

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Ned Freed]

> On 8/30/2005 2:18 PM, Stuart Cheshire wrote:

> > 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.

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

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.

> 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.

My experience has been that people generally do a lousy job of keeping
these things 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).

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

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Ned Freed]

At 2:47 PM +0200 8/31/05, Brian E Carpenter wrote:
>That is about 1/3 of the total. It doesn't surprise me at all that
>so many bogus queries arrive - everybody who mistypes a TLD or
>misconfigures a default domain generates bogus queries, and this isn't
>going to change. The question is whether .local is a *significant*
>part of this load. The limited data I have suggest not, but I'd like
>to see publicly available data: what fraction of those NXDOMAINs are
>due to .local?



The question maybe should be whether .local will become, not is, a
significant part of this load. If you prevent mDNS, the main
proponent of the .local namespace, from becoming a standard, the
number of those names will remain low. If it becomes a standard and
implementers use that namespace more, the load will of course
increase.


I have only skimmed the mDNS proposal, but I don't think this is correct. mDNS
defines .local as a local namespace and requires that queries in this namespace
not done in the DNS. An implementation that forwarded .local queries to the DNS
would not be compliant IMO.

LLMNR, on the other hand, effectively requires this behavior if you set up
something like .local (it could just as easily be .foo), because it says
that when you have both DNS and LLMNR access you try DNS first and if
that fails fall back to LLMNR.

Ned

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Eric A. Hall]

On 8/31/2005 12:36 PM, Ned Freed wrote:

> 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.

> 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.

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.

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

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Additional appeal against publication of draft-lyon-senderid-* in regards to its recommended use of Resent- header fields in the way that is inconsistant with RFC2822

[Tony Finch]

On Mon, 29 Aug 2005, Frank Ellermann wrote:
>
> > incompatible with RFC2822
>
> I'm still a bit lost how this could actually _break_ something.
> For obvious reasons the author can't say "updates 2822", how
> should he fix it ?  As you said the 822 issue is mentioned in
> the senderid-pra draft.

Regarding RFC 822, the S-ID draft doesn't mention the fact that a large
proportion of software which does something useful with Resent- headers
still implements the 822 syntax, not the 2822 syntax.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Ian Jackson]

Margaret Wasserman writes ("Re: Last Call: 'Linklocal Multicast Name Resolution 
(LLMNR)'  to  Proposed Standard"):
> 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.

This is fine and as intended, of course.

> (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.

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.

> 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".

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.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Peter Dambier]

Paul Hoffman wrote:

At 2:47 PM +0200 8/31/05, Brian E Carpenter wrote:


That is about 1/3 of the total. It doesn't surprise me at all that
so many bogus queries arrive - everybody who mistypes a TLD or
misconfigures a default domain generates bogus queries, and this isn't
going to change. The question is whether .local is a *significant*
part of this load. The limited data I have suggest not, but I'd like
to see publicly available data: what fraction of those NXDOMAINs are
due to .local?



The question maybe should be whether .local will become, not is, a 
significant part of this load. If you prevent mDNS, the main proponent 
of the .local namespace, from becoming a standard, the number of those 
names will remain low. If it becomes a standard and implementers use 
that namespace more, the load will of course increase.




Sorry it was not mDSN that provoced these lookups. It was some prerelease
of LLMNR.

There is no LLMNR on apples. The machines that complained were windows
only.


Regards,
Peter and Karin Dambier


--
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 PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Ian Jackson]

Margaret Wasserman writes ("Re: Last Call: 'Linklocal Multicast Name Resolution 
(LLMNR)' to  Proposed Standard"):
> Other than a few minor issues that are being dealt with in a -43 
> update, I don't think that anyone has raised a blocking technical 
> issue with the LLMNR specification during this IETF LC.  If you (or 
> anyone else) has intended to raise a blocking technical issue, either 
> with LLMNR itself or with its ability to coexist with mDNS, please 
> make that clearer to me.

Just to be clear, I am intending my contributions to this argument as
descriptions of what I see as blocking technical issues with LLMNR.

It seems to me from my reading of the specifications that:

 * LLMNR is a ghastly protocol which should not be on the IETF
   Standards Track.

 * mDNS is a superior protocol to LLMNR in nearly all relevant
   respects.

 * The IETF should abandon LLMNR and put mDNS on the Standards Track.

I'd like to reiterate that I entered this discussion with a strong
presupposition towards IETF processes as opposed to third-party
activities.  As I have read the specifications, and the arguments of
those we see reported here, I have become steadily more convinced that
Stuart is right about the politics and that LLMNR critics - such as I
now am - are right about the technical issues.

> I am somewhat concerned, for example, that someone could implement 
> LLMNR thinking that it is the same thing as mDNS and only later find 
> that the two do not interoperate.  Or that some vendors will ship 
> LLMNR while others ship mDNS, so that products from different vendors 
> will not interoperate.  Do others have any thoughts on whether the 
> publication of LLMNR is likely to cause confusion along these lines?

It seems to me that these kinds of confusion are almost what the LLMNR
proponents are _aiming_ for !

> On the other hand, the DNSEXT WG has worked for several years to 
> produce the LLMNR specification, and I don't see anything 
> fundamentally wrong with the mechanism that we have produced (people 
> should respond to the IETF LC if they see blocking technical issues). 

The LLMNR specification is _terrible_.

The issue with namespace ownership, that I've been hammering on about,
should in my opinion *of itself* be sufficient to block progress of
LLMNR on the Standards Track.

> The authors of that specification gave change control to the IETF 
> community, and they have gone through 40+ document iterations, 
> working towards a document that would achieve DNSEXT consensus.  That 
> process was not followed for mDNS (because it was not the chosen 
> solution), and we currently only have one document (LLMNR) that has 
> reached IETF WG consensus and has been submitted for standards 
> publication.

If we believe Stuart Cheshire's description of events, it is not the
case that the IETF has chosen LLMNR over mDNS.  Rather a subset of the
IETF (mainly associated with the DNSEXT WG) were so upset with mDNS as
a concept that they have sabotaged it.

Furthermore, the point of this exercise is not to measure how much
hard work the LLMNR authors have put into their draft.  The fact that
it has been through 40 document iterations should be a cause for
worry, not a cause for applause !

The point of this exercise is for the IETF, as a whole, to standardise
on the best protocols.

> It is possible, in an IETF LC, that we could learn that we do not 
> have IETF consensus to publish something that was produced by an IETF 
> WG.  That would be an exceptional and unpleasant situation, [...]

If this situation is considered exceptional then I can only think that
the mechanisms for detecting it are broken !

Surely it is obvious that it will often be the case that an IETF Last
Call will bring the attention of many more people to a situation - and
most of those people will not share a community background with the WG
members.  It is not surprising that in some subset of those cases, it
turns out that the WG have gone off in some undesirable direction
(either out of technical error or political machination).

The WG is a part of the whole IETF and should be subject to its
opinions.

Ian.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Ned Freed]

> On 8/31/2005 12:36 PM, Ned Freed wrote:

> > 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.

Agreed. And there are various ways to accomplish this.

> 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.

Agreed as well.

> > 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.

> 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.

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.

> 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.

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

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Ian Jackson]

Christian Huitema writes ("RE: Last Call: 'Linklocal Multicast Name Resolution 
(LLMNR)' to  Proposed Standard"):
> A key technical difference between LLMNR and the initial MDNS proposal
> is precisely that LLMNR has no concept of a ".local" top level domain.

While that is true, the next statement:

> Usage of LLMNR does not promote queries to this zone. 

is not.  LLMNR _requires_ the use of names which do not resolve in the
global DNS, and does a global DNS query for each lookup.  Although
LLMNR doesn't suggest the use of `.local', given that many people
don't have a suitable domain to use, they'll use `.local' or something
else.

> This is indeed a key difference between LLMNR and MDNS. MDNS assumes
> that there is a special zone for local names, which would be linked to
> the topology. LLMNR assumes that names are independent of the topology,
> that a host called "foo.example.net" retains the same name as it move to
> different locations. There were ample debates of this point in the
> working group, and the decisions to "not creating special names" and
> "not linking names to topology" do reflect WG consensus.

Even if that is so, this posistion doesn't seem to reflect IETF
consensus.

It is nonsense to say that a `link-local multicast name resolution
protocol' provides DNS data which is not linked to the topology !
To say that the _names_ are not linked to the topology is to miss the
point and thus to mislead.

Given that the _answers_ depend on the topology, wouldn't it be a good
idea to be able to indicate that this topology-dependent behaviour is
- or is not - desired ?

LLMNR only provides that switch - turning on and off topology-
dependent behaviour - on a per-host basis.  mDNS provides it on a
per-lookup basis in a nice easy-to-configure way: specify names in
.local and get topology-dependent answers; specify other names and get
consistent answers.

Ian.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Tony Finch]

On Tue, 30 Aug 2005, Margaret Wasserman wrote:
>
> The LLMNR document already includes an informative reference to
> draft-cheshire-dnsext-multicastdns-05.txt, but it does so rather obscurely
> (citing a need to use a TTL of 255 for "compatibility with Apple Bonjour").

That doesn't make sense. Why does LLNMR need to be compatible with a
separate protocol?

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Stuart Cheshire]

Christian Huitema wrote:

>Windows 98, Windows 2000 and Windows XP do not enable LLMNR by default.

Christian, could you please tell us, for each OS mentioned, how to enable 
LLMNR? That would enable everyone participating in this discussion to 
witness for themselves exactly how it works and what it does.

Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Christian Huitema]

> >Windows 98, Windows 2000 and Windows XP do not enable LLMNR by
default.
> 
> Christian, could you please tell us, for each OS mentioned, how to
enable
> LLMNR? That would enable everyone participating in this discussion to
> witness for themselves exactly how it works and what it does.

You would have to get an experimental implementation of LLMNR from some
developer site. To the best of my knowledge, Microsoft is not shipping
this code. In these systems, ad hoc names are resolved through NETBIOS.
The ".local" queries observed in Peter's root servers is most certainly
not caused by an LLMNR implementation. 

In the absence of LLMNR, if an application tries to resolve "host.local"
through, say, gethostbyname, then the query will indeed be forwarded to
the local DNS service. The responsibility for the ".local" traffic lies
mostly into whoever is promoting use of this top level domain and coding
that use in applications.

-- Christian Huitema

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Dave Singer]

I'm a by-stander on this discussion, maybe off-base or out of it -- 
but something other than the undesirable traffic struck me.


Isn't it also true that I might *deliberately break* all sorts of 
things by introducing 'blocking' names into DNS responses, so that an 
LLMNR request is never issued.  So an ISP could 'grab' traffic that 
the users thought was local, by replying to a DNS request in a proxy 
(or converting a negative reply into an answer).


Also, ISPs might be tempted to start turning around DNS requests in 
their proxies for names that they *think* should be answered by 
LLMNR, returning resolution failure, so as not to send too much 
traffic outbound.  This pre-empts the real DNS from ever actually 
replying.


The whole idea that 'real DNS' can arbitrarily pre-empt local name 
resolution seems, well, wrong, and needs serious study for security 
implications for the services using those names, no?


--
David Singer
Apple Computer/QuickTime

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

IETF last call on draft-hansen-2717bis-2718bis-uri-guidelines-05: The practical case of SMS and MMS URI schemes

[Markus . Isomaki]

Hi,

I did a review on 'Guidelines and Registration Procedures for new URI Schemes', 
draft-hansen-2717bis-2718bis-uri-guidelines-05, for which the IETF last call is 
on until today (sorry for leaving this so late).

My main goal was to see whether the new process would make it sufficiently 
clear for other standards organizations to get URI schemes for their 
protocols/technologies registered. This has been a problem so far. For instance 
OMA and ETSI have for a long time tried to get URI schemes for Multimedia 
Message Service (MMS) and Short Message Service (SMS) registered, but this has 
proven to be impossible due to the vagueness of the existing procedures.

I think the draft is doing a good job addressing this issue. A couple of points 
were raised, however, by people working on the current MMS and SMS URI scheme 
definitions, for which I did not find an obvious answer in the draft. 

The first one may be trivial, but still causing practical problems:
- If the provisional registration of the URI scheme is done in a format of an 
Internet-Draft (such as 
http://www.ietf.org/internet-drafts/draft-wilde-sms-uri-10.txt), is there a 
need to keep updating the draft forever as a reference, or can IANA use the 
(contents of the) draft as a reference even if it has been expired?

The second one is more profound question about the criteria for getting a 
permanent registration:
- The criteria for getting a permanent registration are understandably somewhat 
vague, since there are no precedents. Obviously the people working on SMS and 
MMS would (eventually) hope for a registration with a permanent status. My 
guess was that SMS and MMS are definitely so ubiquitously used utilities, that 
they would easily cross the bar set by section 2.1. But I guess this depends on 
how liberal or strict the IESG is going to be with this.

Otherwise I did not find any issues with the draft, and I think it is ready for 
approval and I truly welcome getting this new process in place.

Regards,
Markus   




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Single DNS root

[JFC (Jefsey) Morfin]

Dear Harald and Paul,
May be time to stop 3683ing this issue. Major moves in the naming 
area are probable in the year to come (PADs - shared root under UN - 
National TLDs, CENTR move.); while an ICANN request of update of RFC 
2826 stays unanswered or opposed for four years.


On 17:25 31/08/2005, Paul Hoffman said:

At 3:24 PM +0200 8/31/05, Peter Dambier wrote:

the Public-Root is not an alternative root but a solution.





It also confuses Registries and Registrars (cf. presentation of ccTLDs)

makes it very clear that this set of root-like servers intends to 
answer affirmatively and authoritatively for TLDs that the 
real/generally-accepted
root servers would say do not exist. From the material on that page, 
it is also likely that, in the future, the NS records returned by 
these root-like servers for some TLDs will be different than those 
returned by the real/generally-accepted root servers.


There is an USG/ICANN contract over IANA functions confirmed by RFC 
2860. Not to make any politics let call it "legacy" root as results 
from the 1984 agreement (RFC 920, claimed source of the ICANN 
legitimacy). The resulting "legacy top zone" - through server 
declarations - is already larger than documented by its root file.


In other words, the statement "the Public-Root is not an alternative 
root but a solution" seems dishonest  when one reads the material at 
the site describing the service.


Correct. The "Public-Root" is technically a decentralised root file. 
It is not a "solution".


At 13:44 31/08/2005, Harald Tveit Alvestrand wrote:
Anyone who wishes to avail themselves of this service would be well 
advised to read RFC 2826 - "IAB Technical Comment on the  Unique DNS Root".


Harald, RFC 2826 has been used and partly out-dated by the 2001 
response ICANN (http://www.icann.org/icp/icp-3.htm ) you ignored for 
practical reasons I accept, but none one commented. It calls for an 
experimentation to document the evolution we face today unprepared. 
When there is more than an unique authoritative root file.


I lead such an experimentation for two years, along with the ICANN 
criteria. Most of my positions you oppose have been tested and 
validated there. I am sure would you run a similar test-bed, our 
strategies could still oppose, but our understandings of the network 
architectural evolution would be similar.


When IETF documents refer to the DNS, I think it's a safe bet that 
they are intending to refer to the system under the single root that 
most people regard as "the root".


May be, but this is wrong. We are to face the balkanisation vs. 
compartmentalisation reality. Chinese law and US Statements of 
Principles have enforced a new situation leading to sovereign 
alt-roots. We can say "obey RFC ", be disregarded and get 
balkanisation. Or we can work on solutions adapted to the current 
evolution, imagine a distributed root system (no big deal) and 
possibly obtain a unique authoritative root matrix. A few months from 
now it will practically be too late.


Harald, we are in direct competition over the language root. "my" 
solution there can survive a balkanisation of the IANA, not yours. So 
it is a common interest to quickly review and document the evolution 
of the name root before it is too late for you and a pain for others.



I don't think any of the fundamentals have changed in the last 5 years.


This _IS_  the problem. You have not seen and acknowledged the change 
(first act: Tokyo 2000, call for the first change in RFC 920 status 
quo), leading to (2001) considering the obsolescence of these 
"fundamentals". In that area nothing has changed since 1984 on the 
internet root side, while the Internet _has_changed_ into the 
international network it only interfaced in 1984.


This change is not trivial, it must be matched by a serious "how to".

jfc


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Keith Moore]

Dave Singer wrote:
The whole idea that 'real DNS' can arbitrarily pre-empt local name 
resolution seems, well, wrong, and needs serious study for security 
implications for the services using those names, no?


The whole idea that local names should look like DNS names and be 
queried through the same APIs and user interfaces seems, well, wrong (or 
dubious at best), and needs serious study for the implications of 
applications using those APIs and the impact of such names on DNS, no?


IMO, local names and a lookup service for local names would be extremely 
useful, but neither the names nor the query interface should look much 
like DNS - the names should look different because otherwise there's too 
much potential for confusion with DNS names, and the query service 
should look different because local name lookup service probably can't 
make the same kinds of consistency or stability assurances that DNS does.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Jeroen Massar]

[for as112 project: maybe add .local into the list of domains??]

On Wed, 2005-08-31 at 14:24 -0700, Christian Huitema wrote:
> > >Windows 98, Windows 2000 and Windows XP do not enable LLMNR by
> default.
> > 
> > Christian, could you please tell us, for each OS mentioned, how to
> enable
> > LLMNR? That would enable everyone participating in this discussion to
> > witness for themselves exactly how it works and what it does.
> 
> You would have to get an experimental implementation of LLMNR from some
> developer site.

This is not 'simply enabling it' :) And then I also wonder if there
actually is an implementation for Win98/Win2k those two being pretty old
and quite unsupported by now I guess... but this besides the point.

> To the best of my knowledge, Microsoft is not shipping
> this code. In these systems, ad hoc names are resolved through NETBIOS.
> The ".local" queries observed in Peter's root servers is most certainly
> not caused by an LLMNR implementation. 

They are most likely done by these nice DSL "router" (NAT :) setups.
Most of these devices have a .local zone configured too. I would not be
surprised if these leaked their queries to the root servers.

That said, if people want to limit the effect of these 'bogus' queries
onto the root servers I suggest that ISP's join into the AS112 project.
Also it would maybe be an idea for AS112 to add .local there?

Greets,
 Jeroen

PS: Who ever named the LLMNR draft 'mdns' isn't that completely
confusing for people looking up the mDNS draft, that is the protocol
that Stuart made? :)



signature.asc
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Resent-* oddities (was: Additional appeal against publication of draft-lyon-senderid-* [...])

[Frank Ellermann]

Tony Finch wrote:

>> the author can't say "updates 2822", how should he fix it ? 
>> As you said the 822 issue is mentioned in the senderid-pra
>> draft.

> Regarding RFC 822, the S-ID draft doesn't mention the fact
> that a large proportion of software which does something
> useful with Resent- headers still implements the 822 syntax,
> not the 2822 syntax.

Except from all PRA-purposes and maybe MUAs displaying these
Resent-* header fields somehow (822 or 2822):  What other uses
do you have in mind ?

Maybe that was discussed somewhere in MARID last year, in that
case I either missed it or didn't get it.

A related issue, apparently 2822 twisted the syntax (more than
one Resent-* block allowed) _and_ the semantics.  Dave's "old"
822 concept could reflect "forwarding" (maybe - I'm not sure).

If that's true 822-Resent-* and PRA are semantically similar,
the only missing piece would be to either allow more than one
"block" (like 2822), or "invalidate" old Resent-* header fields
somehow, e.g. William's Original-* idea.

While I'm at it:  How's that supposed to work with RfC 2476bis
8.1 "MAY add Sender" ?  Apparently 2476bis 8.1 is still based
on the old 822-concept of Resent-* (?)

Or does it ignore the issue ?  Is this part of the PRA-mess in
fact "our" fault (for a definition of TINW including everybody
who reviewed the gellens-submit drafts) ?

Of course I watched 2476 6.1 (and also 8.1), it's essential for
stuff like draft-hutzler-spamops or "op=auth", but something
with Resent-* is very odd, and it's not necessarily PRA.  Bye



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf