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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
