> 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
