Re: [Inip-discuss] Innovation in DNS

[Suzanne Woolf <[e-mail]>]

Hi,

I’m happy to see interest in improving naming on the internet, but I’m going to suggest that an improvement aimed at the root zone of the DNS is going to be very difficult to persuade people to use. The root server operators are a pretty conservative bunch in my experience— they only adopt changes of clear benefit and clearly manageable risk— and the truth is that providing DNS service at the root level is already pretty efficiently done. 

The root zone is not very large (a few hundred entries for many years, now about 1500—many TLDs and many enterprise zones are much, much larger). It doesn’t have a lot of records in it that require special processing on the server, and it doesn’t change very often, relative to many zones lower in the tree (the zone is regenerated, signed, and distributed twice a day). Root servers answer many millions of queries per day, but answers are not complex (mostly referrals to TLD servers and NXDOMAIN), and can be efficiently cached by the recursive resolvers that generate most of the queries on behalf of their end-user clients.  (See traffic statistics published by assorted root server operators, such as those for L-root at http://www.dns.icann.org/lroot/rssac/index.html <http://www.dns.icann.org/lroot/rssac/index.html> and http://stats.dns.icann.org/hedgehog/ <http://stats.dns.icann.org/hedgehog/>, or B-root at https://b.root-servers.org/rssac/. Some of these stats are provided per RSSAC 002, https://www.icann.org/en/system/files/files/rssac-002-measurements-root-06jun16-en.pdf <https://www.icann.org/en/system/files/files/rssac-002-measurements-root-06jun16-en.pdf>, a common framework for the root server operators to share comparable data about their operations.)

Hundreds of anycast instances distribute the query load on the root servers, and modern hardware, software, and network capabilities mean that the resources to scale the service as the internet expands (more users, more devices, broader internet availability) can be added incrementally and at reasonable cost. (See https://www.icann.org/en/system/files/files/rssac-001-root-service-expectations-04dec15-en.pdf <https://www.icann.org/en/system/files/files/rssac-001-root-service-expectations-04dec15-en.pdf> for a description of the DNS root service, and RFC 7720 for a description of protocol requirements for the DNS root.)

It’s also the case that ISPs, enterprise DNS operators, cloud providers, and other infrastructure operators can further expand fast, reliable access to the root zone for their users by caching the entire root zone locally, on their recursive resolvers. (See RFC 7706 for one way this is done.)

Your document suggests you’re trying to improve name service on the internet in some other ways as well. But it’s going to be hard to get people to accept the risk of adding complexity to the system for the benefit of possible but unspecified improvements to service for the root zone, which already works pretty well and has clear, simple ways to improve with existing technology where it doesn’t.


best,
Suzanne

> On Aug 23, 2016, at 12:24 PM, Bauyrzhan Askar <[e-mail]> wrote:
> 
> Hello everyone
> 
> 
> 
> Thank you for your analysis, Andrew
> 
> 
> 
> I think I have to show some main points
> 
> 
> 
> Unlike com zone, root zone is accessed every time when DNS resolution for unknown domain name is requested no matter which TLD zone the unknown domain name belongs to. 
> 
> So, increase of SLD together with TLD, increases rate of DNS resolution query to root nameserver.
> 
> 
> 
> Yes, the load can be lowered by increasing root nameserver copies. That was one of the reason to spread the copies of current root nameservers throughout the world. 
> 
> 
> 
> But the problem here is that when TLD list increases and any entry or update made to the root zone file in master root nameserver, all root nameservers have to be updated which in turn
> 
> 1)     increases the load to network handling root nameservers. (this may not be a big problem at the moment)
> 
> 2)     increases the time for update to be finished throughout the world because of increased number of copies of root nameservers.
> 
> 3)     increases the load to any particular root nameserver, no matter of number of copies of root nameserver, because of the increased rate of updates.  
> 
> What it solves is that the root zone file can be divided by the way the invention suggests. And each piece of zone file (domain name group) is maintained by separate network of root nameservers. The problems listed above because of increased number of TLDs will not be a case in the new system. And also increase of TLD in one particular group can be divided further into sub groups for the redundancy and efficacy purposes.
> 
> 
> 
> There are other problems related to TLD operation other than the technical part which is also by the way can be solved by the invention but I think that is out of the scope of the topic of this discussion group.
> 
>  
> Thank you
> 
> Bauyrzhan Askar 
> 
> 
> On Tue, Aug 23, 2016 at 12:36 AM, Andrew Sullivan <[e-mail] <mailto:[e-mail]>> wrote:
> Hi there,
> 
> On Fri, Aug 19, 2016 at 03:49:59PM +0100, Bauyrzhan Askar wrote:
> > I would like to draw your attention to an invention at  www.ainasystem.org <http://www.ainasystem.org/>,
> > that advances current DNS into new level and eliminates its scalability
> > issue.
> 
> I had a look at this.  It isn't clear to me what problem it solves
> except for the practical limitation on the size of a given zone, which
> doesn't seem to be to be a practical problem at all given the size of
> the com zone.
> 
> If we are going to go to the trouble of replacing the DNS, it seems to
> me that we'd want to fix more than just that.
> 
> > Also I would like to ask your advice or help to bring this invention into
> > reality as I have no experience in contributing or writing a draft about
> > such ideas to IETF.
> 
> Well, the easiest thing to do is to write up an Internet Draft
> describing it and send tht to the repository.  That's all it takes,
> though you will need to make an IPR declaration since you say there's
> a patent pending.
> 
> A
> 
> --
> Andrew Sullivan
> [e-mail] <mailto:[e-mail]>
> 
> _______________________________________________
> Inip-discuss mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.iab.org/mailman/listinfo/inip-discuss <https://www.iab.org/mailman/listinfo/inip-discuss>
> 
> _______________________________________________
> Inip-discuss mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/inip-discuss