Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
At Wed, 23 May 2018 14:39:40 -0400, Warren Kumari 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
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
On Thu, May 17, 2018 at 9:27 AM Joao Damas wrote: > > > > On 17 May 2018, at 13:29, Job Snijders wrote: > > > > On Mon, May 07, 2018 at 07:07:05PM +, 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. > > 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: "This document specifies a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries." and "The sentinel test described in this document determines whether a **user's browser or operating system** looking up the special names that are used in this protocol would be able to validate using the root KSK indicated by the special names. The protocol uses the DNS SERVFAIL response code (RCODE 2) for this purpose because that is the response code that is returned by resolvers when DNSSEC validation fails. If a browser or operating system has multiple resolvers configured, and those resolvers have different properties (for example, one performs DNSSEC validation and one does not), the sentinel mechanism **might search among the different resolvers**, or might not, depending on how the browser or operating system is configured. Note that the sentinel mechanism described here measures a very different (and likely more useful) metric than RFC8145. RFC 8145 relies on resolvers reporting towards the root servers a list of locally cached trust anchors for the root zone. Those reports can be used to infer how many resolvers may be impacted by a KSK roll, but not what the user impact of the KSK roll will be." (emphasis added) and "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? W > Joao > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
> On 17 May 2018, at 13:29, Job Snijders wrote: > > On Mon, May 07, 2018 at 07:07:05PM +, 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
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
On Mon, May 07, 2018 at 07:07:05PM +, 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? If so, we can work to produce text. Kind regards, Job ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
Hi Benno, On 9 May 2018, at 09:12, Benno Overeinder wrote: > There are now 2 implementations of kskroll-sentinel: > 1) peer-reviewed and merged in the BIND master branch; > 2) released with Unbound 1.7.1 last week. > > (And the draft mentions the implemention early versions of this > technique into the Knot resolver.) > > Implementation reports/observations for BIND and Unbound have been sent > to the mailing list. That's great. To the earlier question (the WGLC or WGLCish one) I have sympathy with what Job is saying, but I think we should be pragmatic and not pick on the one DNS extension that is actually seeing coordinated funding, implementation and testing because of problems that have been observed with entirely different extensions whose track record is not so good. Perhaps an acceptable compromise would be to expand slightly on the implementation reports from -12 (which I tend to agree look a bit like placeholders) and expand them to include details of: - specific revisions of code bases, and whether they were released, public and private - revisions of code bases (with similar detail) that exhibited interestingly different behaviour from that described in -12 For example, the use of different labels in earlier revisions of the draft seems worth mentioning to the extent that it's possible some code based on those earlier revisions is or has been running, and examples of those labels might well show up in historical or future data sets. With the observed high level of engagement from three major vendors on this it doesn't seem like fleshing out that section would take very long, and if it helped improve consensus on pushing the doc towards the IESG (which I am in favour of) it might be a good investment in time. I realise it's only a snapshot in time, but really so is a release. (Draft is good though, and in my opinion it could be written up and sent to the IESG right now. It still has to pass the IESG's scrutiny and an IETF-wide last call though, and I think the suggestions above if followed could only oil the tracks through those processes.) Joe signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
To followup on myself, and was dropped with quoting email. On 09/05/2018 15:12, Benno Overeinder wrote: > > Implementation reports/observations for BIND and Unbound have been sent > to the mailing list. > For the future, if the DNSOP working group likes to see an implementation report in a more structured manner, e.g. following the RFC 2119 terms for compliance, please let me know. Of course, we are not volunteering to write extensive reports, but a set of minimal considerations could give guidance. -- Benno -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
Hi all, (Speaking as implementer/NLnet Labs.) To update all readers of this thread. On 09/05/2018 14:56, Job Snijders wrote: > Publishing draft-ietf-dnsop-kskroll-sentinel as RFC on the Standards > Track - without implementations - is, plainly said, not very IETF-like. > But I'm happy to observe that the feedback received during WGLC was > taken serious and at least one implementer got to work, with indications > that more will follow. There are now 2 implementations of kskroll-sentinel: 1) peer-reviewed and merged in the BIND master branch; 2) released with Unbound 1.7.1 last week. (And the draft mentions the implemention early versions of this technique into the Knot resolver.) Implementation reports/observations for BIND and Unbound have been sent to the mailing list. -- Benno -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
Dear Joao, On Wed, May 09, 2018 at 09:39:56AM +0200, Joao Damas wrote: > While I do agree with you that having implementations early on is a > very desirable requirement, though I would disagree with making it a > hard requirement (see the case of aggressive negative caching and how > it unfolded as an example), for any new idea brought to the IETF I > would like to point out a couple of things here: > > - there is an established way for drafts to progress to RFCs and > within the RFC levels. The progression from proposed to full Standard > absolutely requires implementations (plural) >From a rhetoric perspective you are quite creative in making a _seemingly_ reasonable point: "why don't we kick the can down the road and require implementations on the 'proposed standard' -> 'internet standard' barrier?". But in my opinion you are misrepresenting the 'established way', this is reason for concern. The IETF TOA is a foundational document https://www.ietf.org/tao.html, let's look at section "A.5 Documents": """ IETF Standards Track specifications are not considered to be satisfactory standards until interoperable independent implementations have been demonstrated. (This is the embodiment of the "running code" slogan.) """ Now let's look at https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-12 and in the upper left corner we see: "Intended status: Standards Track". Publishing draft-ietf-dnsop-kskroll-sentinel as RFC on the Standards Track - without implementations - is, plainly said, not very IETF-like. But I'm happy to observe that the feedback received during WGLC was taken serious and at least one implementer got to work, with indications that more will follow. > - the issue is not specific to any give wg, it is an IETF-wide issue > and so the right place for discussion of improving this aspect of > standards development is the IETF list rather any specific wg list You seem to be attempting to move the elephant in the room to a different room (generalizing the issue to an IETF wide scope), this distracts from the issue at hand. Bert Hubert's talk about the "DNS Camel" should have made it clear to anyone that DNSOP itself has a problem. Each working group has to come up with strategies to maximize the quality of their publications; in the case of DNSOP one of the aspects of the solution is fairly obvious: require running code. This is not an IETF-wide issue. The IETF norm is to demonstrate interoperable independent implementations, and if you'd like to argue there should be an exception for the DNSOP working group, the onus is on you to take that discussion to the IETF list. > - in the specific case in the subject, there is funding available to > support final implementation of this idea on three code bases. This > won’t be released until we are past a successful last-call (because > that’s how it works) and so stalling this specific draft on behalf of > a way more general idea and discussion is actually having the opposite > effect of what the discussion’s goals are. It is delaying final > implementation. You may be holding the argument upside down: not having implementations delays having a high quality protocol specification, which delays RFC publication, which (in the diffusion of innovations theory) delays the early & late majority. When not even "innovators" and "early adaptors" can get behind a given draft, that draft is already in trouble. There is no need to _release_ said implementations to the public. The implementers are right to not publish releases containing features that have not yet been standardized. A common approach is to have implementations sit on feature/beta branches, so that you can demonstrate that there is interopability, to have discussion about how to test & validate that the implementation confirms to the protocol specification. Implementer feedback is crucial in constructing a protocol specification. If there are zero implementations of a concept a lot of the discussion about that concept is merely theoretical. This is not a chicken-egg situation. If someone believes this draft is good and serves a purpose benefical to the Internet community, they will attempt to implement the draft and during that development process feedback is collected which the working group can consider to either improver wording, remove non-essential parts, or re-architect the whole thing. Kind regards, Job ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
Hi Job, While I do agree with you that having implementations early on is a very desirable requirement, though I would disagree with making it a hard requirement (see the case of aggressive negative caching and how it unfolded as an example), for any new idea brought to the IETF I would like to point out a couple of things here: - there is an established way for drafts to progress to RFCs and within the RFC levels. The progression from proposed to full Standard absolutely requires implementations (plural) - the issue is not specific to any give wg, it is an IETF-wide issue and so the right place for discussion of improving this aspect of standards development is the IETF list rather any specific wg list - in the specific case in the subject, there is funding available to support final implementation of this idea on three code bases. This won’t be released until we are past a successful last-call (because that’s how it works) and so stalling this specific draft on behalf of a way more general idea and discussion is actually having the opposite effect of what the discussion’s goals are. It is delaying final implementation. Just my 2 cents Joao > On 8 May 2018, at 10:49, Job Snijders wrote: > > On Tue, May 08, 2018 at 11:05:50AM +1000, Mark Andrews wrote: We have also taken the implementation comments posted to the WG mailing list and collected them in a new section titled "Implementation Experience” in the light of Suzanne’s request So we would like to pass this draft back to the WG Chairs at this point for your review for potential submission as an RFC. >>> >>> 1/ While this is a step in the right direction, I'm not yet entirely >>> impressed by the 'Implementation Experience' section. Is it somehow >>> hard to write an implementation report that describes which >>> implementations comply with the BCP 14 / RFC 8174 terms used in >>> draft-ietf-dnsop-kskroll-sentinel? Are the authors experiencing some >>> blocker in this regard? >> >> Is it a implementation report or a compliance report? > > Well, the current section on the implementations isn't much of either, > it is very sparse. This working group should try to raise the bar for > RFC publication, not explore what the bare minimum is. > > I've used this example before: what I was hoping for is reports that > allude to the BCP14 terms and implementation's compliance similar to > what is done here: > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-large-community%20implementations > Overviews like these are easy to consume for humans, and are derived > from extensive tests like the one you showed below. > > I'd like to note that describing people's intention to implement in a > section called 'Implementation experience' of course doesn't add much > value. :-) > >> To actually do a full compliance report for this draft it would >> require including a complete DNSSEC compliance report and in turn a >> complete STD 13 compliance report to meet this “MUST”. >> >> DNSSEC-Validating resolvers that implement this mechanism MUST >> perform validation of responses in accordance with the DNSSEC >> response validation specification [RFC4035]. >> >> A exhaustive compliance report would run to a couple of thousand tests >> without doing a DNSSEC compliance report due to the combinatorial >> nature of this draft. >> >> You would need validate as secure zone, a validate as bogus zone, a >> validate as insecure w/ signatures, a validate as insecure w/o >> signatures. You then for all of these need zones with and without A >> and records at the test names where without includes both NODATA >> and NXDOMAIN. You then need to multiply that by servers configured to >> validate and those configured not to validate. Then you need to >> multiply this by having the functionality enabled or disabled. You >> then need to do a test for each of the conditions in the list of >> conditions that must be met for the modified responses to be returned. >> You also need to do that where the label looked up after a CNAME and a >> DNAME. >> >> We skipped some of these tests when we built our system tests by I >> believe we hit enough of them to be happy that the code is operating >> correctly. > > Yes, I think you are touching upon the core of the issue. Discussing > _how_ to test a specification is exactly the type of discussion to be > held in this working group. > > Its commonly accepted that even seemingly simple specifications may be > stringing together a number of complex features. Extensive testing and > demonstrations of such testing are a necessity to be able to claim > 'running code and rough consensus'. > >> S:rootkeysentinel:Mon May 7 17:55:35 UTC 2018 >> T:rootkeysentinel:1:A >> A:rootkeysentinel:System test rootkeysentinel >> [snip] > > Thanks for sharing this! > > So, the current status is that there is no longer zero, but now a single > implementation of draft-ietf-dnsop-kskroll-sentinel-12?
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
On Tue, May 08, 2018 at 11:05:50AM +1000, Mark Andrews wrote: > >> We have also taken the implementation comments posted to the WG > >> mailing list and collected them in a new section titled > >> "Implementation Experience” in the light of Suzanne’s request > >> > >> So we would like to pass this draft back to the WG Chairs at this > >> point for your review for potential submission as an RFC. > > > > 1/ While this is a step in the right direction, I'm not yet entirely > > impressed by the 'Implementation Experience' section. Is it somehow > > hard to write an implementation report that describes which > > implementations comply with the BCP 14 / RFC 8174 terms used in > > draft-ietf-dnsop-kskroll-sentinel? Are the authors experiencing some > > blocker in this regard? > > Is it a implementation report or a compliance report? Well, the current section on the implementations isn't much of either, it is very sparse. This working group should try to raise the bar for RFC publication, not explore what the bare minimum is. I've used this example before: what I was hoping for is reports that allude to the BCP14 terms and implementation's compliance similar to what is done here: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-large-community%20implementations Overviews like these are easy to consume for humans, and are derived from extensive tests like the one you showed below. I'd like to note that describing people's intention to implement in a section called 'Implementation experience' of course doesn't add much value. :-) > To actually do a full compliance report for this draft it would > require including a complete DNSSEC compliance report and in turn a > complete STD 13 compliance report to meet this “MUST”. > >DNSSEC-Validating resolvers that implement this mechanism MUST >perform validation of responses in accordance with the DNSSEC >response validation specification [RFC4035]. > > A exhaustive compliance report would run to a couple of thousand tests > without doing a DNSSEC compliance report due to the combinatorial > nature of this draft. > > You would need validate as secure zone, a validate as bogus zone, a > validate as insecure w/ signatures, a validate as insecure w/o > signatures. You then for all of these need zones with and without A > and records at the test names where without includes both NODATA > and NXDOMAIN. You then need to multiply that by servers configured to > validate and those configured not to validate. Then you need to > multiply this by having the functionality enabled or disabled. You > then need to do a test for each of the conditions in the list of > conditions that must be met for the modified responses to be returned. > You also need to do that where the label looked up after a CNAME and a > DNAME. > > We skipped some of these tests when we built our system tests by I > believe we hit enough of them to be happy that the code is operating > correctly. Yes, I think you are touching upon the core of the issue. Discussing _how_ to test a specification is exactly the type of discussion to be held in this working group. Its commonly accepted that even seemingly simple specifications may be stringing together a number of complex features. Extensive testing and demonstrations of such testing are a necessity to be able to claim 'running code and rough consensus'. > S:rootkeysentinel:Mon May 7 17:55:35 UTC 2018 > T:rootkeysentinel:1:A > A:rootkeysentinel:System test rootkeysentinel > [snip] Thanks for sharing this! So, the current status is that there is no longer zero, but now a single implementation of draft-ietf-dnsop-kskroll-sentinel-12? I see progress, but not last call material. Kind regards, Job ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
> On 8 May 2018, at 5:07 am, Job Snijders wrote: > > On Thu, May 03, 2018 at 06:15:49PM +1000, Geoff Huston wrote: >> We have submitted -12 of this draft which we believe incorperates the >> substantive review comments made during the WG Last Call period that >> were posted to the WG Mailing List. >> >>> Editors: Please take “concern about a description of current >>> implementation status” as WGLC input, and consider what you might be >>> able to add to the draft to address it. >> >> We have also taken the implementation comments posted to the WG >> mailing list and collected them in a new section titled >> "Implementation Experience” in the light of Suzanne’s request >> >> So we would like to pass this draft back to the WG Chairs at this >> point for your review for potential submission as an RFC. > > 1/ While this is a step in the right direction, I'm not yet entirely > impressed by the 'Implementation Experience' section. Is it somehow hard > to write an implementation report that describes which implementations > comply with the BCP 14 / RFC 8174 terms used in > draft-ietf-dnsop-kskroll-sentinel? Are the authors experiencing some > blocker in this regard? Is it a implementation report or a compliance report? To actually do a full compliance report for this draft it would require including a complete DNSSEC compliance report and in turn a complete STD 13 compliance report to meet this “MUST”. DNSSEC-Validating resolvers that implement this mechanism MUST perform validation of responses in accordance with the DNSSEC response validation specification [RFC4035]. A exhaustive compliance report would run to a couple of thousand tests without doing a DNSSEC compliance report due to the combinatorial nature of this draft. You would need validate as secure zone, a validate as bogus zone, a validate as insecure w/ signatures, a validate as insecure w/o signatures. You then for all of these need zones with and without A and records at the test names where without includes both NODATA and NXDOMAIN. You then need to multiply that by servers configured to validate and those configured not to validate. Then you need to multiply this by having the functionality enabled or disabled. You then need to do a test for each of the conditions in the list of conditions that must be met for the modified responses to be returned. You also need to do that where the label looked up after a CNAME and a DNAME. We skipped some of these tests when we built our system tests by I believe we hit enough of them to be happy that the code is operating correctly. S:rootkeysentinel:Mon May 7 17:55:35 UTC 2018 T:rootkeysentinel:1:A A:rootkeysentinel:System test rootkeysentinel I:rootkeysentinel:PORTRANGE:11300 - 11399 I:rootkeysentinel:get test ids (1) I:rootkeysentinel:test id: oldid=35058 (configured) I:rootkeysentinel:test id: newid=36058 (not configured) I:rootkeysentinel:test id: badid=42835 I:rootkeysentinel:check authoritative server (expect NOERROR) (2) I:rootkeysentinel:check test zone resolves with 'root-key-sentinel yes;' I:rootkeysentinel: (expect NOERROR) (3) I:rootkeysentinel:check root-key-sentinel-is-ta with old ta and I:rootkeysentinel: 'root-key-sentinel yes;' (expect NOERROR) (4) I:rootkeysentinel:check root-key-sentinel-not-ta with old ta and I:rootkeysentinel: 'root-key-sentinel yes;' (expect SERVFAIL) (5) I:rootkeysentinel:check root-key-sentinel-not-ta with old ta, CD=1 and I:rootkeysentinel: 'root-key-sentinel yes;' (expect NOERROR) (6) I:rootkeysentinel:check root-key-sentinel-is-ta with new ta and I:rootkeysentinel: 'root-key-sentinel yes;' (expect SERVFAIL) (7) I:rootkeysentinel:check root-key-sentinel-is-ta with new ta, CD=1 and I:rootkeysentinel: 'root-key-sentinel yes;' (expect NOERROR) (8) I:rootkeysentinel:check root-key-sentinel-not-ta with new ta and I:rootkeysentinel: 'root-key-sentinel yes;' (expect NOERROR) (9) I:rootkeysentinel:check root-key-sentinel-is-ta with bad ta and I:rootkeysentinel: 'root-key-sentinel yes;' (expect SERVFAIL) (10) I:rootkeysentinel:check root-key-sentinel-is-ta with bad ta, CD=1 and I:rootkeysentinel: 'root-key-sentinel yes;' (expect NXDOMAIN) (11) I:rootkeysentinel:check root-key-sentinel-not-ta with bad ta and I:rootkeysentinel: 'root-key-sentinel yes;' (expect NXDOMAIN) (12) I:rootkeysentinel:check root-key-sentinel-is-ta with out-of-range ta and I:rootkeysentinel: 'root-key-sentinel yes;' (expect NXDOMAIN) (13) I:rootkeysentinel:check root-key-sentinel-not-ta with out-of-range ta and I:rootkeysentinel: 'root-key-sentinel yes;' (expect NXDOMAIN) (14) I:rootkeysentinel:check root-key-sentinel-is-ta with no-zero-pad ta and I:rootkeysentinel: 'root-key-sentinel yes;' (expect NXDOMAIN) (15) I:rootkeysentinel:check root-key-sentinel-not-ta with no-zero-pad ta and I:rootkeysentinel: 'root-key-sentinel yes;' (expect NXDOMAIN) (16) I:rootkeysentinel:check CNAME to root-key-sentinel-is-ta with old ta and I:rootkeysentinel: 'r
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
On Thu, May 03, 2018 at 06:15:49PM +1000, Geoff Huston wrote: > We have submitted -12 of this draft which we believe incorperates the > substantive review comments made during the WG Last Call period that > were posted to the WG Mailing List. > > > Editors: Please take “concern about a description of current > > implementation status” as WGLC input, and consider what you might be > > able to add to the draft to address it. > > We have also taken the implementation comments posted to the WG > mailing list and collected them in a new section titled > "Implementation Experience” in the light of Suzanne’s request > > So we would like to pass this draft back to the WG Chairs at this > point for your review for potential submission as an RFC. 1/ While this is a step in the right direction, I'm not yet entirely impressed by the 'Implementation Experience' section. Is it somehow hard to write an implementation report that describes which implementations comply with the BCP 14 / RFC 8174 terms used in draft-ietf-dnsop-kskroll-sentinel? Are the authors experiencing some blocker in this regard? 2/ Moving the Walkthrough Example to the end of the document as an appendix has greatly improved the readability of the document. 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. Kind regards, Job ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
I reviewed the -11 to -12 changes and they look good to me. The document is ready to go in my opinion. Ondrej -- Ondřej Surý ond...@isc.org > On 3 May 2018, at 10:15, Geoff Huston wrote: > > Hi WG Chairs (and WG) > > We have submitted -12 of this draft which we believe incorperates the > substantive review comments made during the WG Last Call period that were > posted to the WG Mailing List. >> >> Editors: Please take “concern about a description of current implementation >> status” as WGLC input, and consider what you might be able to add to the >> draft to address it. > > We have also taken the implementation comments posted to the WG mailing list > and collected them in a new section titled "Implementation Experience” in the > light of Suzanne’s request > > So we would like to pass this draft back to the WG Chairs at this point for > your review for potential submission as an RFC. > > Thanks, > > Geoff (for co-editors Joao and Warren) > > > ___ > 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
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
Geoff Huston wrote: On 4 May 2018, at 3:06 am, Paul Vixie wrote: what are the implications for older (pre-KSKROLL) validators when icann eventually rolls the key? I assume that you are referring to security-aware resolvers that do not perform the actions specified in this draft. There are no implications at all for these resolvers. Any trusted key measurement conducted using such a resolver will show that the resolver is a security-aware resolver, but is not performing the sentinel method. thanks. i feared for a moment a second TCR. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
> On 4 May 2018, at 3:06 am, Paul Vixie wrote: > > what are the implications for older (pre-KSKROLL) validators when icann > eventually rolls the key? I assume that you are referring to security-aware resolvers that do not perform the actions specified in this draft. There are no implications at all for these resolvers. Any trusted key measurement conducted using such a resolver will show that the resolver is a security-aware resolver, but is not performing the sentinel method. Geoff ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
On 3 May 2018, at 10:06, Paul Vixie wrote: what are the implications for older (pre-KSKROLL) validators when icann eventually rolls the key? None. That is, they will either be ready or they won't be, and this draft doesn't change that. This draft is about signaling, not about actually being ready for a roll. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
what are the implications for older (pre-KSKROLL) validators when icann eventually rolls the key? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
Hi, On 03-05-18 10:15, Geoff Huston wrote: > We have also taken the implementation comments posted to the WG mailing list > and collected them in a new section titled "Implementation Experience” in the > light of Suzanne’s request This draft is by now implemented in Unbound and is in version 1.7.1 which we just released. I didn't find deficiencies in the latest version of the draft that would hinder implementation. I like to second Ondrej's earlier remark that from an implementors point making an implementation for an early draft makes little sense, which is why we waited until now. We need a somewhat stable specification before we make code that will be used in the real world to prevent pollution and in this case would make it even harder to do proper measurements. -- Ralph ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
