Subject: Re: Single DNS root

From: John C Klensin <[email-masked]>
Date: Thu, 01 Sep 2005 15:10:24 -0400

--On Thursday, 01 September, 2005 02:49 +0200 "JFC (Jefsey)
Morfin" <[email-masked]> wrote:

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

Jefsey,

Just to understand the relationship between your reality and
mine, what "ICANN request for an update of RFC 2826" are you
talking about?  Certainly there was some discussion within ICANN
circles about whether 2826 meant what it said.  But, of course,
anyone can say just about anything in an ICANN meeting or on an
ICANN mailing list as long as it is consistent with the
organization's norms for appropriate behavior (just as with
Internet Drafts and IETF mailing lists).  Such a comment is not
equivalent to an "ICANN request".  

I am aware of one informal inquiry from an ICANN staff member as
to whether the IAB was likely to have more to say on the
subject.  The informal response (from one of the editors of 2826
but with general sympathy from the IAB) was, if I recall,
approximately "which part of 'unique' are you having trouble
understanding?".

At least in my memory and reality, there has been no "ICANN
request" for an update, much less one that has been "unanswered
or opposed".

Could you explain what you are talking about and identify the
request to which you are referring? 

Or stop this, lest the claim about such a request become part of
Harald's 3683 case?

   john

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

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 02 Sep 2005 04:36:10 +0200

At 21:10 01/09/2005, John C Klensin wrote:
>mine,

Dear John,
No problem. What is a reality (back-ground, referent and context) is 
precisely the ultimate question of this R&D. But you jump into 
something complex enough, at the core of an evolution the IETF does 
not consider much.

>what "ICANN request for an update of RFC 2826" are you
>talking about?

I quoted it in the mail. This is the ICP-3 document. This document is 
often confused as an anti-New.net pamphlet. This is key document 
which discusses:

- the legitimacy of ICANN, rooting in the consensus we had in 1984, 
JonPostel documented in RFC 920
- the need of a unique authoritative root as documented in RFC 2826, 
plus harping on alt-roots, etc.
- the development of the Internet technology based upon 
experimentation and the need of a community experimentation for the 
evolution of the DNS. The IETF is quoted there as both a possible 
experimentation leader and further standardiser.

I have asked several times that IETF addresses that request. I was 
usually responded that IETF is ill suited to lead an experimentation. 
I therefore ran such a test-bed for two years, involving up to 30 
machines (2002/2003) from all over the planet (dot-root project). The 
results of this experimentation lead to several 
conclusions/proposition validations. They are the base of my 
positions and several initiatives.

>  Certainly there was some discussion within ICANN

This was during the writing of ICP-3 and the fuss over alt(sic)roots. 
RFC 2860 deals with the past. Not with the evolution of the Internet. 
ICP-3 investigates the possibility of the end of the concept of 
unique authoritative root file. It takes advantage from your draft on 
classes: this a way to show where and how far to investigate and 
respond the question "what does experimentation teach about the 
internet evolution?". This was also the time IDN started being 
considered. IMO a lot of things would have been different had we 
considered that well written document.

ICP-3 also gives the criteria for such an experimentation we strictly 
followed (except in extending to what we named ULDs [upper/user level 
domains] to be able also to test real users behaviours in a 
consistent way with these criteria). In that area we experimented that:

- the management of the current root file can be far more efficient, 
secure, TLD Manager directed and universally controlled than by ICANN 
or investigated by the CENTR.

- the single authoritative root should be a notion to stay, but the 
file concept should develop into a structured matrix. We also 
identified that these notions could find an adequate solution in the 
evolution of the IANA concept itself to adapt to ISO 11179 conformant 
ideas to CRCs (Common Reference Center) organising a DRS (Distributed 
Registry System). The report I published - paid by Govs and 
international instances - was ... thick but it only partly covered 
our small budge. The AFRAC organisation we created to continue 
experimentation and development on the DRS part for France. It gives 
additional experience.

ICP-3 document refers to classes (in using a Draft of yours). This is 
a more complex issue, we identified as a general problem (I 
documented in a mail a few weeks ago) of the Internet architecture. 
Several architectural parameters default to "one". The problems of 
partitioning we face and started a balkanisation of the network, can 
be structurally solved without conflict and more easily in turning 
that parameters to "multiple set". There is one class, one (may be a 
little more) group, one IPv6 plan, one namespace, one IANA, one 
language, one ICANN, one IP, etc.

>request" for an update, much less one that has been "unanswered

I argued that IETF should comment. This did not attract people. 
Yourself now ask, in spite I explained it and gave the URL in the 
mail you comment. You are used as the main example to exemplified a 
possible evolution...

There were two main questions into this: national 
security/sovereignty and multilingualism.

- you may recall your own comments on Vint Cerf's inputs, on this 
list, over the stability of the root server system protected by 
ICANN. They helped a lot to rise the attention of some Governments 
(with direct impact on their interest in ITU and on WSIS). This 
motivation is well documented by http://whitehouse.gov/pcipb and has 
led to the US Statements of Principle. It has however a low echo at 
the IETF. But we identified we could tackle it through an evolution 
towards a user-centric architecture, the DRS and a country based 
distribution of an IPv6 /3 block.

- the main engine to make things and classes moving (with some R&D 
funding) is multilingualism. Because there is a need, there is a risk 
of balkanisation, there are budgets. But IAB forgot about it in RFC 
3869 - so there is work ahead to correct that. Harald has never been 
impressed by the capacity of IETF to deal with multilingualism. 
However with Paul Hoffman and you, he is one of the really few with a 
vision on the issue (I disagree with much of it - at least what I 
understand from his RFCs, remarks and involvements I know?).

This is why I created Eurolinc with Louis Pouzin, Gov and Industry 
people a few years ago, which was quite active at the WSIS as you may know.

Capitalising on our experience, I have engaged a project, presented 
in Luxembourg ccTLD Meeting among others, for such a test-bed to be 
now a collective effort by ccTLDs and national Internet communities. 
It has the support of a few countries communities and ccTLD Managers, 
and the opposition of some IETF members. This project started with 
the proposition of a liaison IETF/ccTLDs (I documented in a mail on 
IETF) which is very similar to the US Statement of Principles 
published further on.

>Or stop this, lest the claim about such a request become part of

Harald's claim is a welcome commercial/political blunder in a complex 
competition between his organisation and mine, over the 
centralisation or the distribution of the Multilingual Internet 
registries (control of the IANA vs. DRS). It was long awaited as a 
public confirmation of our analysis.

As far as I am concerned it concludes the IETF part of my RFC 3066 
bis saga. In spite of a tough opposition - I obtained most of the 
revamps of the December LC failed Draft I wanted, so it does not 
conflict with IRI-tags. I am sorry if Harald does not like them: they 
are in the Draft now. The GenArt seems in a position to obtain some 
of the others. IESG has now all the elements to decide of the future 
of the IANA.

I submit that the resulting future image of the IANA under the 
application of that Draft (and the resulting trust the public will 
attach to it)  will substantially weight in the future DNS 
organisation acceptation.

Obviously other findings we made, in the DNS area, which may pop-up 
sometimes and so substantially affect the joly old name space.
jfc

---

From: Daniel Karrenberg <[email-masked]>
Date: Thu, 1 Sep 2005 10:27:02 +0200

On 31.08 14:47, 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?

I believe CAIDA has published something but I cannot find it.
I have had a quick look myself:

Cursory observation of a random sampple from 2004 which I have used for 
other purporses shows that about 15% of the NXDOMAIN answers excluiding 
'.arpa.' are for questions ending in .local. A further 3% are for 
'localhost' and about 20% are for an IP address in dotted-quad format.

The .local queries have a high incidence of labels beginning with 
an underscore and often conain the string "Default-First-Site" in 
various languages such as illustrated by the following examples:

SOA? _kerberos._tcp.Default-First-Site-Name._sites.capital.local
SRV? _ldap._tcp.dc._msdcs.bsztorgau.local
SOA? _kpasswd._tcp.AppliedEngineeringServices.local
SRV? _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.semaia.local
SRV? _ldap._tcp.a9c93f95-51af-4f5d-8280-1171e79176c4.domains._msdcs.Netcare.local
SOA? _ldap._tcp.Standardname-des-ersten-Standorts._sites.gc._msdcs.VESTERBERG.local
SOA? _kerberos._tcp.Nombre-predeterminado-primer-sitio._sites.d1asib03.local
SRV? _ldap._tcp.Premier-Site-par-defaut._sites.dc._msdcs.production.local
SOA? _kerberos._udp.Christ.local
SRV? _ldap._tcp.dc._msdcs.production.local
SRV? _ldap._tcp.3b6c4c19-2d29-4ed0-9915-b7b43f3488e3.domains._msdcs.datalog.local
SOA? _kpasswd._udp.tae.local
SOA? _ldap._tcp.Default-First-Site._sites.gc._msdcs.ufficio-tecnico.local

Preventing an increase of this nonsense from getting worse or even reducing
it is a worthy cause because root servers can use all the headroom they can
get. 

Note that this is only an random sample and as such is just an indication
of what is happening. It should be considered not more than anecdotal evidence.

Note also that I do not read the ietf list.

Daniel

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 2 Sep 2005 18:19:44 -0400

On Tue, Aug 30, 2005 at 12:29:37PM -0400, Margaret Wasserman wrote:
> 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 

I did not follow the development of the LLMNR drafts; but the
discussion on this list inspired me to review the latest (-43)
Internet Draft.  Having reviewed it, I do not think it should be
published as a Proposed Standard.

My greatest concern is that the document as it stands is likely to
cause a large number of bogus DNS queries.  If the protocol is widely
adopted, it seems probable that many clients will have LLMNR enabled
on an interface in a situation where a DNS server has been configured
(as described in section 2).  In that case, every LLMNR query will
entail (possibly more than) one DNS query, because of the provision,
"All attempts to resolve the name via DNS on all interfaces have
failed after exhausting the searchlist."  Such DNS queries will become
commonplace if the protocol is widely adopted and widely used.  This
feature of the design appears to increase the burden on the entire
Internet infrastructure in order to support unshared infrastructure.

My second worry is that, because the behaviour changes depending on
the results from the DNS query, this protocol will sometimes, if not
often, violate the principle of least surprise.  It also opens a
whole new model for "phishing" attacks, particularly in the context
of ubiquitous wireless access points.  

Because of the foregoing, I do not believe LLMNR, in its current
form, should be adopted as a Proposed Standard.

Regards,
Andrew Sullivan

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110