Re: [DNSOP] Decreasing Access Time to Root Servers

[yaojk]

>> 在 2015年10月8日，21:56，Paul Hoffman  写道：
>> 
>> On 7 Oct 2015, at 21:59, Jiankang Yao wrote:
>> 
>> 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.
> 
> 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.
> 
> If I do not have this difference correct, please clarify.

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.

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

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.



>> 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
>> resolving service providers.
>> The root-cache enabled software can be 

Re: [DNSOP] Decreasing Access Time to Root Servers

[Paul Hoffman]

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

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.


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

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.


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.

It is better that the WG provides another choice for dns operators.


Only if the other choices are operationally reasonable.

--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Decreasing Access Time to Root Servers

[Jiankang Yao]

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.