>> 在 2015年10月8日，21:56，Paul Hoffman <paul.hoff...@vpnc.org> 写道：
>>
>> 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 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.
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.
>> 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.
Thanks.
Jiankang
> --Paul Hoffman
>
> _______________________________________________
> 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
