> On 17 May 2018, at 13:29, Job Snijders <j...@ntt.net> wrote:
> 
> On Mon, May 07, 2018 at 07:07:05PM +0000, Job Snijders wrote:
>> 3/ Section 3 states: "The responses received from queries to resolve
>> each of these names would allow us to infer a trust key state of the
>> resolution environment.".
>> From what I understand, in today's DNS world we can only reasonably
>> expect to do one query per packet. It is well understood that many
>> operators use BGP-4 anycasting (ECMP), the likes of dnsdist, and/or
>> simple UDP loadbalancers. I think it may be good to document that
>> running 3 queries (in essence 3 independent experiments) may not
>> generate sufficient data to properly infer the state (or any state) of
>> the resolution environment. Each query (as part of a single sentinel
>> data gathering session) may be handled by an entirely different resolver
>> with different keys, contaminating any lookup in the proposed truth
>> tables. Section 4 covers a number of cases where the results are
>> indeterminate. It maybe should be added to Section 4 that the client has
>> no awareness of how the resolver environment is constructed, and thus
>> requiring multiple independent queries to infer state has its downsides.
> 
> Do the authors agree with the above observation?

No, not really, at least in my case. What you are saying is that an incoherent 
system behaves in inconsistent manners (a service exposes itself to the outside 
as a homogeneous system but doesn’t behave that way). In that case the problem 
is not one or more queries, the problem is an internally misconfigured system.
If you are referring to the case when a client has several resolvers that I can 
try, I think what we can do is stress even more is that this measures the 
client’s resolver environment, not aspects of particular resolvers. We are 
after finding out whether a user can get a successful resolution in their 
configure environment.

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

Reply via email to