Subject: [Inip-discuss] Innovation in DNS

From: Bauyrzhan Askar <[email-masked]>
Date: Fri, 19 Aug 2016 15:49:59 +0100

Dear members of this discussion group

I would like to draw your attention to an invention at  www.ainasystem.org,
that advances current DNS into new level and eliminates its scalability
issue. Feel free to ask questions related to the invention.

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.

Best regards
Bauyrzhan Askar

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 22 Aug 2016 19:36:58 -0400

Hi there,

On Fri, Aug 19, 2016 at 03:49:59PM +0100, Bauyrzhan Askar wrote:
> 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.

> reality as I have no experience in contributing or writing a draft about

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
[email-masked]

---

From: Bauyrzhan Askar <[email-masked]>
Date: Tue, 23 Aug 2016 17:24:21 +0100

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 <[email-masked]>
wrote:

> _______________________________________________
> Inip-discuss mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/inip-discuss
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 23 Aug 2016 12:35:53 -0400

> unknown domain name is requested no matter which TLD zone the unknown

Not true.  That claim ignores the effects of TTLs.

> query to root nameserver. *

So?

> number of copies of root nameserver, because of the increased rate of

All of this is true of the com zone, too, so I don't see how it's
relevant at all.  I just don't see that this is a significant
improvement of the DNS, and it involves adding changes to the system
that present their own risks.  If we're going to undertake such risks,
it seems to me a tiny incremental improvement to address no actual
practical problem anyone has for only one zone seems like a low
return on the investment.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Bauyrzhan Askar <[email-masked]>
Date: Thu, 25 Aug 2016 17:01:46 +0100

Hi there

>So?

Andrew, would you explain the effects of TLL related to that claim.

For the purpose of clarification of the claim, TTL specifies time it will
be in cache of DNS resolver. I  point you to “request to *unknown domain
name*” and it means that there is no record data for the unknown domain
name not just on Internet users PC but also in DNS resolvers cache.

As for the risk it brings, what kind of risk are you mentioning?
Cybersquatting, risk of switching to AINA System or other risks?

I want to draw your attention to the part where implementation of the AINA
System is described. As you can see for the purpose of simplicity,
switching to AINA System can be conducted through three scenarios. (at
least three and it is up to imagination). The first one is the one which
has no risk, and what needed is just to direct requests to AINA System in
case of unknown domain name for root nameservers.

Many problems may rise here not from the technical aspect but rather from
political or business interest aspects. And I hopefully believe that the
discussions conducted here is out of that topics.

Thanks

---

From: "Marc Blanchet" <[email-masked]>
Date: Thu, 25 Aug 2016 12:09:35 -0400

> Andrew, would you explain the effects of TLL related to that claim.

not wanting to respond for Andrew, but maybe he was referring to 
« TTL » of negative caching (RFC2308, see section 5).

Regards, Marc.

---

From: Bauyrzhan Askar <[email-masked]>
Date: Thu, 25 Aug 2016 17:13:12 +0100

Thanks Mark
I will investigate that RFC
Best wishes

On 25 Aug 2016 17:09, "Marc Blanchet" <[email-masked]> wrote:

> not wanting to respond for Andrew, but maybe he was referring to « TTL »
> of negative caching (RFC2308, see section 5).
>
> Regards, Marc.
>
> be in cache of DNS resolver. I point you to “request to
> *unknown domain name*” and it means that there is no record data for the
> unknown domain
> On Tue, Aug 23, 2016 at 5:35 PM, Andrew Sullivan [email-masked]
> wrote:
>
> ------------------------------
>
> ------------------------------
>

---

From: Bauyrzhan Askar <[email-masked]>
Date: Thu, 25 Aug 2016 17:14:47 +0100

Sorry Marc Blanchet

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 25 Aug 2016 16:48:03 -0400

> name not just on Internet users PC but also in DNS resolvers cache.

Perhaps I'm misunderstanding you, but it sounds like you think that if
unknown.example.com arrives ar a resolver, it needs to do the whole
resolution chain.  But the fact is that the NS set for com and
possibly for example.com will both be in the cache.  There's no need
to ask the root about com in this case.  Com is almost always hot in
every cache.  This is true for a lot of TLDs.  And with the advent of
the signed root, lots of resolvers just copy the root, so they don't
really have to consult the root servers at all.

> Cybersquatting, risk of switching to AINA System or other risks?

You're changing the system, and making it considerably more complex.
That necessarily brings risk.

> case of unknown domain name for root nameservers.

There's not "no risk" to that.  You're introducing a new set of
dependencies.  That automatically brings risk, and I don't see what
the reward is.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 25 Aug 2016 18:27:05 -0400

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 <[email-masked]> wrote:
> 
> Hello everyone
> 
> 
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Hi there,
> 
> > I would like to draw your attention to an invention at  www.ainasystem.org <http://www.ainasystem.org/>,
> [email-masked] <mailto:[email-masked]>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.iab.org/mailman/listinfo/inip-discuss <https://www.iab.org/mailman/listinfo/inip-discuss>
>