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
