> On 8 May 2018, at 5:07 am, Job Snijders <j...@ntt.net> 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 AAAA 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: 'root-key-sentinel yes;' (expect NOERROR) (17) I:rootkeysentinel:check CNAME to root-key-sentinel-not-ta with old ta and I:rootkeysentinel: 'root-key-sentinel yes;' (expect NOERROR) (18) I:rootkeysentinel:check CNAME to root-key-sentinel-is-ta with new ta and I:rootkeysentinel: 'root-key-sentinel yes;' (expect NOERROR) (19) I:rootkeysentinel:check CNAME to root-key-sentinel-not-ta with new ta and I:rootkeysentinel: 'root-key-sentinel yes;' (expect NOERROR) (20) I:rootkeysentinel:check CNAME to root-key-sentinel-is-ta with bad ta and I:rootkeysentinel: 'root-key-sentinel yes;' (expect NXDOMAIN) (21) I:rootkeysentinel:check CNAME to root-key-sentinel-not-ta with bad ta and I:rootkeysentinel: 'root-key-sentinel yes;' (expect NXDOMAIN) (22) I:rootkeysentinel:check test zone resolves with 'root-key-sentinel no;' I:rootkeysentinel: (expect NOERROR) (23) I:rootkeysentinel:check root-key-sentinel-is-ta with old ta and I:rootkeysentinel: 'root-key-sentinel no;' (expect NOERROR) (24) I:rootkeysentinel:check root-key-sentinel-not-ta with old ta and I:rootkeysentinel: 'root-key-sentinel no;' (expect NOERROR) (25) I:rootkeysentinel:check root-key-sentinel-is-ta with new ta and I:rootkeysentinel: 'root-key-sentinel no;' (expect NOERROR) (26) I:rootkeysentinel:check root-key-sentinel-not-ta with new ta and I:rootkeysentinel: 'root-key-sentinel no;' (expect NOERROR) (27) I:rootkeysentinel:check root-key-sentinel-is-ta with bad ta and I:rootkeysentinel: 'root-key-sentinel no;' (expect NXDOMAIN) (28) I:rootkeysentinel:check root-key-sentinel-not-ta with bad ta and I:rootkeysentinel: 'root-key-sentinel no;' (expect NXDOMAIN) (29) I:rootkeysentinel:check root-key-sentinel-is-ta with out-of-range ta and I:rootkeysentinel: 'root-key-sentinel no;' (expect NXDOMAIN) (30) I:rootkeysentinel:check root-key-sentinel-not-ta with out-of-range ta and I:rootkeysentinel: 'root-key-sentinel no;' (expect NXDOMAIN) (31) I:rootkeysentinel:check root-key-sentinel-is-ta with no-zero-pad ta and I:rootkeysentinel: 'root-key-sentinel no;' (expect NXDOMAIN) (32) I:rootkeysentinel:check root-key-sentinel-not-ta with no-zero-pad ta and I:rootkeysentinel: 'root-key-sentinel no;' (expect NXDOMAIN) (33) I:rootkeysentinel:check CNAME to root-key-sentinel-is-ta with old ta and I:rootkeysentinel: 'root-key-sentinel no;' (expect NOERROR) (34) I:rootkeysentinel:check CNAME to root-key-sentinel-not-ta with old ta and I:rootkeysentinel: 'root-key-sentinel no;' (expect NOERROR) (35) I:rootkeysentinel:check CNAME to root-key-sentinel-is-ta with new ta and I:rootkeysentinel: 'root-key-sentinel no;' (expect NOERROR) (36) I:rootkeysentinel:check CNAME to root-key-sentinel-not-ta with new ta and I:rootkeysentinel: 'root-key-sentinel no;' (expect NOERROR) (37) I:rootkeysentinel:check CNAME to root-key-sentinel-is-ta with bad ta and I:rootkeysentinel: 'root-key-sentinel no;' (expect NXDOMAIN) (38) I:rootkeysentinel:check CNAME to root-key-sentinel-not-ta with bad ta and I:rootkeysentinel: 'root-key-sentinel no;' (expect NXDOMAIN) (39) I:rootkeysentinel:exit status: 0 R:rootkeysentinel:PASS E:rootkeysentinel:Mon May 7 17:55:38 UTC 2018 > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
