Subject: RE: Something better than DNS?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 27 Nov 2006 07:16:45 -0800

> From: Patrick Vande Walle [mailto:[email-masked]] 

> From
> http://www.cs.cornell.edu/people/egs/beehive/codons-sigcomm04/
node15.html
> 
> "CoDoNS enables multiple namespace operators to manage the 
> same part of the name hierarchy [...] Ideally, competing 
> operators would preserve a single consistent namespace by 
> issuing names out of a common, shared pool. In the presence 
> of conflicting or inconsistent records, clients simply pick 
> the records signed by an operator they trust, similar to the 
> way they pick between separate sets of root servers today. 
> Essentially, nameowners have the ability to choose the 
> namespace operator that will endorse their records based on 
> price, service and functionality."

Beware academic speculation, it has a tendency to obsess on the exact wrong thing.

For years extreemly intellignt people that many of us know quite well worked away on cryptographic voting protocols that are designed to provide perfect secrecy. The realization that auditability was the central criteria in a voting system only came in the fall of 2000. 

[That is not to say that commerce does not have similar issues but the falure modes are different.]

The issue for DNS users is that core DNS has to be there with at least five nines reliability. No part of the Internet can exceed the reliability of core DNS, if core DNS is down everything is.

Without reading the paper the abstract alone gives the game away 'issuing names out of a common pool'. Who manages the central pool? What we end up with here is nothing more than a recapitulation of the current situation except that the registry function has been distributed across the registrars.

I don't think that you will find many registrars that actually want to be in the capital intensive business of operating  a registry, or a registry that wants to be in the customer support intensive business of operating a retail registrar.

Even if you did the cost of achieving current levels of reliability would be considerably higher.

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

---

From: John Levine <[email-masked]>
Date: 28 Nov 2006 18:45:08 -0000

> Beware academic speculation, it has a tendency to obsess on the

Indeed.  (And I should know, having taken eight years to get my PhD.)

>From a technical point of view, the registry/registrar model works
fine.  I have plenty of bad things to say about VRSN, but it is hard
to deny that their registry is very reliable and plenty fast, despite
having a TLD zone that is probably four orders of magnitude bigger
than anyone imagined when the DNS was designed.  It is even surviving
the completely needless crisis of domain tasting, with millions of
unpaid domains added and deleted every day.

The problems are all political and administrative.  Registries charge
six bucks per domain, while their actual cost is more like a quarter,
and ICANN in their grand naivete appears poised to let them all raise
the price rather than pushing it down toward cost.  Registries' primary
goal is to make money rather than to serve their clients, so there's
constant pressure to steal traffic with wildcards, sell traffic data to
the highest bidder, and other user-hostile antics.

When I first proposed the registry/registrar model in 1996, I assumed
that the registries would be co-ops owned by the registrars and run to
recover costs, exactly to prevent the sorts of problems we see with
registries whose interests are opposed to their registrars.  Too bad
people only seem to have read the first half of my paper.

But it's not just registry/registrar issues.

As someone noted a few days ago, ICANN and the current roots have yet
to address the issues related to IDNs.  There's only one significant
technical issue, mapping non-unique Unicode strings into unique DNS
names, and we seem finally to be getting a handle on that.  But
there's a raft of significant non-technical issues to address as well.
Should registries prevent registrations of homographs, and if so, what
rule(s) do you use to define homographs, and what do you do when you
find them?  If we add non-English TLDs, do we add a hundred local
language equivalents of com, org, net, and so forth?  If we do, are
they aliases for each other, or do we suddenly get 300 new TLDs?

ICANN has not to date dealt very effectively with these issues, but
they are real issues that will have a great effect on people who use
the DNS every day, and they're not technical issues, since all of the
alternatives are equally feasible technically.

So, basically, I'm not sure what people are arguing about here.  The DNS
of 2006 is not the DNS of 1992.  Deal with it, we're not going back.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: Karl Auerbach <[email-masked]>
Date: Tue, 28 Nov 2006 12:05:43 -0800

John Levine wrote:

> names

There is an ancillary issues that have not, to my knowledge, been 
adequately researched, and that is the expansion in the size of the 
response packets.

IDN's will tend to be longer than ASCII names.  This will by itself make 
response packets larger.  And, to the degree that root and secondary 
servers are named by IDNS, the various NS records will tend to grow as 
well.  And most users are probably not aware of DNS name compression or 
try to accommodate it in the way that is done with the 
?.root-servers.net convention, so we may get larger packets because name 
compression doesn't give us the same boost it used to.

Brew in longer addresses from IPv6 and we end up with longer response 
packets.

How much longer probably isn't a big issue unless they are big enough to 
trigger a fallback onto TCP rather than UDP or if we get UDP packets 
that exceed path MTU and have to be fragmented.  (By-the-way, why is 
EDNS/RFC 2671 not advancing on the standards track?)

		--karl--

---

From: Edward Lewis <[email-masked]>
Date: Tue, 28 Nov 2006 15:36:00 -0500

At 12:05 -0800 11/28/06, Karl Auerbach wrote:

>path MTU and have to be fragmented.  (By-the-way, why is EDNS/RFC 2671 not
>advancing on the standards track?)

For the same reason almost none of the other DNS RFCs have not advanced.

RFC 3596 being the lone Draft Standard.
RFC 1034/1035 being the lone Full Standard.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Dessert - aka Service Pack 1 for lunch.

---

From: David Conrad <[email-masked]>
Date: Tue, 28 Nov 2006 20:16:44 -0800

Karl,

> adequately researched, and that is the expansion in the size of the  

I suppose that depends on your definition of "adequately".

> This will by itself make response packets larger.

Yes, the future definitely has larger response packets in store for us.

> How much longer probably isn't a big issue unless they are big  
> enough to trigger a fallback onto TCP rather than UDP or if we get  
> UDP packets that exceed path MTU and have to be fragmented.

The issue of response size comes up in a bunch of places (IDNs,  
adding AAAA, DNSSEC, etc.) and the implications of that growth is  
definitely an area of concern.  Given the indeterminate number of  
broken DNS implementations out there, any change (even one as  
innocuous (from a DNS protocol technical perspective) as adding IDNs)  
is almost guaranteed to break something.  The big question in my mind  
is how much will break and who will be affected.

> (By-the-way, why is EDNS/RFC 2671 not advancing on the standards  
> track?)

Good question.

Rgds,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Nov 2006 16:24:17 +1100

> > (By-the-way, why is EDNS/RFC 2671 not advancing on the standards  

	It's on the dnsext charter though a little late.

Jun 2005	  	RFC2671 (EDNS0) to Draft Standard 

	Most of the issues with RFC2671 are the result on non
	conformance w/ RFC 103[45] and firewall that *think* they
	know what is a valid DNS packet or feel that IP fragmentation
	should not be allowed.

	Note the later two usually affect the client side and when
	lookups start failing they usually address the issue.

	The non conformance with RFC 103[45] usually takes the form
	of dropping packets the server doesn't know how to handle
	rather than returning a error code.

	Note: in general EDNS0 just works.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 29 Nov 2006 14:34:28 +0100

> For the same reason almost none of the other DNS RFCs have not  

Any volunteers for performing interoperability tests and writing the  
reports that are needed for advancement are kindly requested to send  
a mail to [email-masked].

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/