Hello Daniel, On Sun, 2019-11-17 at 07:50 +0000, Daniel Migault wrote: > Hi, > > Please find our draft that provides recommendations for DNSSEC resolvers > Operators. Any comment is appreciated! > > Yours, > Daniel > > -----Original Message----- > From: [email protected] <[email protected]> > Sent: Sunday, November 17, 2019 2:48 AM > To: Edward Lewis <[email protected]>; Daniel Migault > <[email protected]>; Dan York <[email protected]> > Subject: New Version Notification for > draft-mglt-dnsop-dnssec-validator-requirements-08.txt > > > A new version of I-D, draft-mglt-dnsop-dnssec-validator-requirements-08.txt > has been successfully submitted by Daniel Migault and posted to the IETF > repository. > > Name: draft-mglt-dnsop-dnssec-validator-requirements > Revision: 08
Thank you for this work, a document outlining operational concerns/requirements for DNSSEC validation sounds useful to me. However, this document currently looks like a weird mix between requirements for operators, requirements for operating systems, and requirements for DNSSEC validator software. I think it would be good to clarify the scope of the document. I also have a few concerns with the current content. Section 2 tries to describe DNSSEC validation in general. I find this section to both be too long and too short. It is too short because it has inaccuracies (like the statement "Once accurately validated the RRset is assumed to be accurately validated and trusted during the time indicated by its TTL." which completely ignores RRSIG expiry) and it is too long because it mostly restates what was already described in RFCs such as 4033-4035. In other words, this section also needs to decide who it is for, and what it is trying to convey. Section 7.1: a very common deployment scenario is the OS or validator vendor shipping the current root anchors, and keeping them up to date, with no operator intervention needed. I think this form deserves more than an afterthought in the last paragraph of 7.1. Although some bootstrapping mechanisms to securely retrieve publish [RFC7958] and retrieve [UNBOUND-ANCHOR] the Root Zone Trust Anchor have been defined, it is believed these mechanisms should be extended to other KSKs or Trust Anchors. 'it is believed' - is it? why? Section 7.1.1: this, apparently, is a recommendation to implementers, not to operators. I refer to my earlier remark about scope. Section 7.2.1: it is my opinion that RFC5011 is a mistake and we should deprecate it. As such, I disagree with the recommendation. Section 7.2.2: it is my opinion that RFC8145 is a mistake and we should deprecate it. As such, I disagree with the START-UP REC. Besides that, this section talks, without referencing any defined process, about things changing in the validator's memory as the result of key rollovers. I am not sure what is meant here. 'TA health check results MUST be logged.' It is unclear to me what a 'TA health check' is (so perhaps that could be clarified), but many operators prefer to log as little as possible, for performance reasons. A 'MUST' on logging an event will need to be clearly argued. Section 8: a nitpick: different keys can have the same key tag. Comparing key tags is always an optimisation, never something to draw conclusions from. A serious problem: the RUN TIME REC here is a terrible idea. It is, as the section in fact argues, the authoritative operator's responsibility to provide a coherent set of keys and signatures at any point in time. Recursive caches already expire things based on TTL and RRSIG Expiry; this is enough. I note that Edward Lewis argued the same thing convincingly in https://mailarchive.ietf.org/arch/msg/dnsop/SB0S9eci_GUiY2qCgKM9Py7_dW8, many revisions of the draft ago. "The net recommendation is to separate cache management from validation." Section 9.1: this repeats the RFC8145 recommendation, and as such I disagree with it. "This would at least provide insight to the authoritative server and provide it some context before moving a key roll over further." It is important to remember how bad the 8145 data in the time leading up to the cancelled root TA rollover was. Bad data does not become better by getting more of it. Section 9.3: as I mentioned for section 8, cache management and validation are separate concerns. This means that the only reasonable implementation of this recommendation is to 'flush example.com and everything below it'. I suggest simplifying the recommendation to that. Section 10: I believe 6975, like 8145, is a bad idea. I also believe that no validators have implemented it, except systemd-resolved, which implemented it wrongly, because it does not talk to authoritative servers. The RUN TIME REC makes no sense to me. "A DNSSEC validator operator SHOULD regularly request and monitor the signature scheme supported by an authoritative server." Which authoritative server? What does it mean to 'request and monitor'? Is that anything more than requesting the DNSKEY set and looking at the algorithms used in it? We already have a deprecation mechanism for algorithms, through somewhat periodic RFCs that update https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml. Section 11, second RUN TIME REC: certainly an operator is not expected to notice -every- failed DNSSEC validation? And what does 'report' mean? Report it where? I'm looking forward to a more focused revision of the draft. I suspect that this document could be a lot shorter without losing its usefulness. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
