Subject: [DNSOP] Decreasing Access Time to Root Servers

From: "Jiankang Yao" <[email-masked]>
Date: Thu, 8 Oct 2015 12:59:05 +0800

Hello,

It is good to know that draft-ietf-dnsop-root-loopback will be soon be published as RFC.
Thanks for authors' and WG's  effort. 

For the rfc-to-be (draft-ietf-dnsop-root-loopback-05.txt), there are following working group summary
"
This document came out of several different proposals involving
improving the redundancy of the DNS Root Zone.  The document was the
one which the Working Group was able to gather consensus.  The
discussion behind this was engaging as several felt the trade off of
local copies for speed increased operational fragility.  This document
was not written to become a Best Practice or an Internet Standard, but
as an Informational document to explain how operators currently manage
such tasks."

draft-yao-dnsop-root-cache helps to provide another or alternative choices to improve the redundancy of the DNS Root Zone.
Different dns operators may choose different methods:  draft-ietf-dnsop-root-loopback  or draft-yao-dnsop-root-cache.
draft-yao-dnsop-root-cache improves on draft-ietf-dnsop-root-loopback in the following ways:
1.  The resolver which supports draft-yao-dnsop-root-cache is still a resolver which still needs to get the root data information from 13 dns root servers.
    The resolver which supports draft-ietf-dnsop-root-loopback does not need to get the root data information from 13 dns root servers.     In the other words,  if all resolvers were upgraded to support draft-ietf-dnsop-root-loopback, there would have millions of "root servers". It is hard to imagine how to manage so many "root servers".  The root-cache-enabled resolver has not such problems.

2. Root-loopback server Operation of the Root Zone  must be run on the Loopback Address while the root-cache-enabled resolver can be run on any address. 

3. The resolver which supports draft-yao-dnsop-root-cache will cache and improve the recent query result (which is also most likely to be queried again) via the new mechanism, improving the dns query efficiency. 

4. Due to the possible "operational fragility", the root-loopback enabled software will be released without the default configuration of support of draft-ietf-dnsop-root-loopback.  The root-loopback enabled software is suitable for the experienced DNS operators and big dns 
resolving service providers.  
The root-cache enabled software can be released with the default configuration of support of draft-yao-dnsop-root-cache.  The root-cache enabled software is suitable for most DNS operators and dns 
resolving service providers.  

To help to decrease the access time to root servers, one method might be not enough to satisfy all kinds of DNS operators.
It is better that the WG provides another choice for dns operators.

Thanks.

Jiankang Yao

From: The IESG
Date: 2015-10-06 07:03
To: IETF-Announce
CC: dnsop mailing list; dnsop chair; RFC Editor
Subject: [DNSOP] Document Action: 'Decreasing Access Time to Root Servers by Running One on Loopback' to Informational RFC (draft-ietf-dnsop-root-loopback-05.txt)
The IESG has approved the following document:
- 'Decreasing Access Time to Root Servers by Running One on Loopback'
  (draft-ietf-dnsop-root-loopback-05.txt) as Informational RFC

This document is the product of the Domain Name System Operations Working
Group.

The IESG contact persons are Benoit Claise and Joel Jaeggli.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-root-loopback/

Technical Summary

   Some DNS recursive resolvers have longer-than-desired round trip
   times to the closest DNS root server.  Some DNS recursive resolver
   operators want to prevent snooping of requests sent to DNS root
   servers by third parties.  Such resolvers can greatly decrease the
   round trip time and prevent observation of requests by running a copy
   of the full root zone on a loopback address (such as 127.0.0.1).
   This document shows how to start and maintain such a copy of the root
   zone that does not pose a threat to other users of the DNS, at the
   cost of adding some operational fragility for the operator.

Working Group Summary

This document came out of several different proposals involving
improving the redundancy of the DNS Root Zone.  The document was the
one which the Working Group was able to gather consensus.  The
discussion behind this was engaging as several felt the trade off of
local copies for speed increased operational fragility.  This document
was not written to become a Best Practice or an Internet Standard, but
as an Informational document to explain how operators currently manage
such tasks.

Document Quality

Note, 

There is an IPR disclosure related to this document.  The Authors have
already been aware of this IPR disclosure, and no of no other IPR
disclosure related to this document.  The opinion of the working group
is that the IPR party implies a willingness to commit to not requiring
any licenses or royalties.

Personnel

The Document Shepherd is Tim Wicinski.  The Responsible Area Director
is Joel Jaggeli.

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 08 Oct 2015 06:56:36 -0700

On 7 Oct 2015, at 21:59, Jiankang Yao wrote:

> 1.  The resolver which supports draft-yao-dnsop-root-cache is still a 
> resolver which still needs to get the root data information from 13 
> dns root servers.

This sentence is confusing, maybe due to language. In 
draft-yao-dnsop-root-cache, resolvers don't get root data from the root 
servers: they get it from an off-site cache server that is not 
controlled by the root server operators.

> The resolver which supports draft-ietf-dnsop-root-loopback does not 
> need to get the root data information from 13 dns root servers.

This too is confusing, since resolvers act the same in both proposals: 
the only difference is the location of the root information. In 
draft-yao-dnsop-root-cache, that information is in an off-site cache 
server, while in draft-ietf-dnsop-root-loopback it is on the same system 
as the resolver.

If I do not have this difference correct, please clarify.

> In the other words,  if all resolvers were upgraded to support 
> draft-ietf-dnsop-root-loopback, there would have millions of "root 
> servers".

This seems like a ridiculous re-definition of the term "root server". A 
system that cannot be accessed by anyone else is not a "server".

> It is hard to imagine how to manage so many "root servers".

Good, because there is no reason for anyone to manage them.

> The root-cache-enabled resolver has not such problems.

Instead, it has the major problem that the resolvers using it are 
relying on an external entity (the operator of the root cache) to be 
completely reliable. This adds a hard dependency on the management of an 
external service, instead of just on network connectivity.

> 2. Root-loopback server Operation of the Root Zone  must be run on the 
> Loopback Address while the root-cache-enabled resolver can be run on 
> any address.

That is a true statement, but it is an operational advantage for 
draft-ietf-dnsop-root-loopback and a disadvantage for 
draft-yao-dnsop-root-cache. There is never a problem for the operational 
stability of loopback addresses, but there are sometimes problems with 
relying on the stability of external addresses.

> 3. The resolver which supports draft-yao-dnsop-root-cache will cache 
> and improve the recent query result (which is also most likely to be 
> queried again) via the new mechanism, improving the dns query 
> efficiency.

Why do you list this as advantage of draft-yao-dnsop-root-cache? It is 
identical for both drafts.

> 4. Due to the possible "operational fragility", the root-loopback 
> enabled software will be released without the default configuration of 
> support of draft-ietf-dnsop-root-loopback.  The root-loopback enabled 
> software is suitable for the experienced DNS operators and big dns
> The root-cache enabled software can be released with the default 
> configuration of support of draft-yao-dnsop-root-cache.  The 
> root-cache enabled software is suitable for most DNS operators and dns

If this WG adopts draft-yao-dnsop-root-cache, there will need to be a 
discussion about whether deploying software with it's mechanism as a 
default configuration. I can think of some reasons why that would be a 
terrible idea:

- There is no assurance that the service will be live, such as if the 
service provider has gone out of business since the configuration was 
generated for the distribution.

- There is no assurance that the service will be reachable by the new 
resolver due to network topology issues.

Operationally, making draft-yao-dnsop-root-cache a pre-configured choice 
is significantly worse than pre-configuring for 
draft-ietf-dnsop-root-loopback. Neither should be allowed in default 
configurations, but doing so for draft-yao-dnsop-root-cache has many 
more failure modes.

> To help to decrease the access time to root servers, one method might 
> be not enough to satisfy all kinds of DNS operators.

Only if the other choices are operationally reasonable.

--Paul Hoffman

---

From: yaojk <[email-masked]>
Date: Sat, 10 Oct 2015 17:17:59 +0800

>> 在 2015年10月8日，21:56，Paul Hoffman <[email-masked]> 写道：
>> 
> This sentence is confusing, maybe due to language. In draft-yao-dnsop-root-cache, resolvers don't get root data from the root servers: they get it from an off-site cache server that is not controlled by the root server operators.

Only when the root data cache (off-site cache server called by you) happens to have such root data. If such root data queried is not in the root data cache, the resolver need to query the information from the 13 root servers directly. The dnsop-root-cache enabled resolver has the root data cache timeout mechanism. When the refresh timer for some root data cached is timeout, these root data cached will be deleted from the root data cache. When these root data are queried again, the resolver need to get the data from the 13 root servers directly. So the dnsop-root-cache enabled resolver increase the chance of getting the root data directly from the root data cache, but still has a chance to get the root data directly from the 13 root servers while The dnsop-root-loop-back enabled resolver never need to query 13 root servers. 

The original source of root data in the dnsop-root-cache enabled resolver is from the 13 root servers while The original source of root data in the dnsop-root-loop-back enabled resolver is not from the 13 root servers.

> 
>> The resolver which supports draft-ietf-dnsop-root-loopback does not need to get the root data information from 13 dns root servers.
> 
> This too is confusing, since resolvers act the same in both proposals: the only difference is the location of the root information. In draft-yao-dnsop-root-cache, that information is in an off-site cache server, while in draft-ietf-dnsop-root-loopback it is on the same system as the resolver.
> 

Pls see the clarification above too.
The difference is :
The original source of root data in the dnsop-root-cache enabled resolver is from the 13 root servers while The original source of root data in the dnsop-root-loop-back enabled resolver is not from the 13 root servers.

>> In the other words,  if all resolvers were upgraded to support draft-ietf-dnsop-root-loopback, there would have millions of "root servers".
> 
> This seems like a ridiculous re-definition of the term "root server". A system that cannot be accessed by anyone else is not a "server".

We may avoid the argument of what is the server. 

One picture we can imagine is :

The world do not need the 13 root servers again if all resolvers are updated to support draft of dnsop-loop-back. 
The world do need the 13 root servers if all resolvers are updated to support draft of dnsop-root-cache.

> Instead, it has the major problem that the resolvers using it are relying on an external entity (the operator of the root cache) to be completely reliable. This adds a hard dependency on the management of an external service, instead of just on network connectivity.
> That is a true statement, but it is an operational advantage for draft-ietf-dnsop-root-loopback and a disadvantage for draft-yao-dnsop-root-cache. There is never a problem for the operational stability of loopback addresses, but there are sometimes problems with relying on the stability of external addresses.

My original sentence may cause some confusion.
Some clarification here,
When implementation, the root data cache can be an internal part or function of the dnsop-root-cache enabled resolver.  It serves the local resolver only.

> Why do you list this as advantage of draft-yao-dnsop-root-cache? It is identical for both drafts.
> 
> If this WG adopts draft-yao-dnsop-root-cache, there will need to be a discussion about whether deploying software with it's mechanism as a default configuration.

If The root data cache is implemented    as part of local function of resolver, the default configuration can be made. If it is implemented as external function of the resolver, it may need more consideration.

Yes, the wg may discuss this issue.

Thanks.

Jiankang