At Wed, 23 May 2018 14:39:40 -0400,
Warren Kumari <war...@kumari.net> wrote:
> Just so the WG knows, the authors (myself in particular) had some
> productive discussions with Job at the RIPE meeting in Marseille.
> As a reminder, this mechanism is designed to measure the *user* impact of
> the KSK roll - this means that querying the first resolver in e.g:
> resolve.conf, getting SERVFAIL and then failing over to the second (or
> third or n-th) until a response is received is fine, and expected.
> The document currently contains:
[...]
> "Note that a slew of other issues can also cause SERVFAIL responses, **and
> so the sentinel processing may sometimes result in incorrect
> conclusions.**" (emphasis added).
> An example of a case where an incorrect conclusion could occur is if the
> client is using an Anycast recursive resolver (e.g: 8.8.8.8) and some of
> the backends of that Anycast network have only the old key, and some have
> the new key, and ECMP directs you to different backend. Another exmaple is
> if the resolver learns the new key *during* a clients testing. To me these
> feel like pathological cases, and are covered by "may sometimes result in
> incorrect conclusions".
> Does the WG feel that this is sufficient, or would it like additional
text?
> If so, can you propose some?
I don't have a strong opinion on the main question (I'm fine with the
current version of this draft regarding this matter). But I'd like to
point out that the above quoted text regarding SERVFAIL and "incorrect
conclusions" (which I think I proposed before) mainly concerned cases
where SERVFAIL is returned for a different reason than the one
described in kskroll-sentinel such as query timeout (note the "other
issues" in the text). Likewise, "incorrect conclusions" mainly
intended such cases as deducing Vnew/Vold/Vleg labels while the
corresponding SERVFAIL was returned for a different reason. I think
it's slightly different from a type of "incorrect conclusions"
discussed in this thread, since an incorrect conclusion is reached not
because SERVFAIL is returned for a different reason but because it's
inconsistent which server sends which.
Again, I'm fine with the current text anyway. But if we want to tweak
the text in response to the concern in this thread while preserving
the original text quoted above, then we might say something like:
OLD
[...] Note that a slew of other issues can also cause SERVFAIL
responses, and so the sentinel processing may sometimes result in
incorrect conclusions.
NEW
[...] Note that a slew of other issues can also cause SERVFAIL
responses and DNS transactions are not always reliable or
consistent, and so the sentinel processing may sometimes result in
incorrect conclusions.
--
JINMEI, Tatuya
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
