mglt / draft-mglt-dnsop-dnssec-validator-requirements Goto Github PK

The current version force the configuration to be updated at the time the service is started and does not recommend the configuration file to be updated.
Another alternative is to update the configuration file and attempt to keep the configuration updated at run-time.

The section should provide clearer recommendations on what is monitored.

The case of ENT-optout-no-signed [1] subzones provides two examples where DNSSEC validation could not be performed due to software bug. In one case the validation could not be performed because the provided data could not validated appropriately. In the other case, even when correct data is provided, some resolver implementations are not able to proceed to validation.

"""
More often, to date, failed validation is due to operator error and
not an attempt to forge data.
"""

1. We should add the case of software bug.
2. We should also recommend that DRO run multiple implementations so, when a bug is detected, it can switch to one implementation the time it takes to address the bug.

[1] https://indico.dns-oarc.net/event/25/contributions/403/attachments/378/647/AFNIC_OARC_Dallas.pdf

This section needs to be clarified. In particular it seems unclear that signature scheme are retrieved by requesting a DNSKEY.

envisioned action points:

1. clarify the text and mentioning how the signature schemes are discovered.
2. It is unclear if we should keep track of the requested domain, in order to be able to request the DNSKEYs 
3. emphasize on a communication of supported algorithms between authoritative servers and resolvers.  

There should be a discussion regarding the consideration of these parameters and associated values.

   val-sig-skew-min: <seconds>
          Minimum number of seconds of clock skew to  apply  to  validated
          signatures.   A  value of 10% of the signature lifetime (expira-
          tion - inception) is used, capped by this setting.   Default  is
          3600  (1  hour)  which  allows for daylight savings differences.
          Lower this value for more strict checking of short lived  signa-
          tures.

   val-sig-skew-max: <seconds>
          Maximum  number  of  seconds of clock skew to apply to validated
          signatures.  A value of 10% of the signature  lifetime  (expira-
          tion  -  inception) is used, capped by this setting.  Default is
          86400 (24 hours) which allows for timezone setting  problems  in
          stable  domains.  Setting both min and max very low disables the
          clock skew allowances.  Setting both min and max very high makes
          the validator check the signature timestamps less strictly.

[1] https://nlnetlabs.nl/documentation/unbound/unbound.conf/

draft-jabley-dnsop-validator-bootstrap-00 provides some considerations on the selection and retrieval of the TA. We should probably try to merge these documents.

1. Introduction - "As such differ the confidence into the Trust to designate which DNSKEY RR is legitimate." I don't understand what this sentence is supposed to mean.

2. Introduction - "The chain of trust is obtained by recursively validating the DNSKEY RRs." This sentence appears before the paragraphs which describe the recursive DNSKEY validation process and before any indication of the fact that there are even multiple DNSKEY RRs involved (in most cases).

3. Introduction - "Keys for a name will "vouch for" keys at a name delegated via the signing of a DS resource record set." The signing of the DS RRset isn't the delegation process, the delegation process is the addition of NS records for the domain being delegated. Also "Keys for a name" is repeated in this sentence and I suspect the two uses are referring to different things.

4. Introduction - "Once accurately validated the RRset is assumed to be accurately validated and trusted during the time indicated by its TTL." This is repetitive, and it's not clear to me that 'accurately' is providing any value here, because the RRset is either validated or is not validated; it cannot be 'inaccurately' validated. I see that in section 3 there is a definition of 'accurate validation' but I don't think this is as helpful as intended, as a validator can return a 'false negative' response for reasons which are completely outside of its control (and some are noted in the document) but this does not make that response 'inaccurate'.

5. Introduction - "The responsibilities of a DRO are limited to the management of TAs as well as providing the necessary infrastructure to perform the signature validation, e.g. appropriated libraries and time." Disregarding the misuse of 'appropriated' I believe this sentence is incorrect. The responsibilities of a DRO include all activities required to operate the recursive resolution service they are offering to their users, not just the aspects related to DNSSEC validation.

6. Section 3 - "Trust Anchor Data Store: a module (of code) implementing functions related to the trust anchors used by the validator. This is essentially a database allowing access, monitoring of, and changes to trust anchors." I don't think it is useful to refer to this as "a module (of code)", as it may not be a distinct module in the DRO's chosen implementation, and it might not even be code! It is conceivable that a DRO may choose to use something analogous to an HSM for storing Trust Anchors.

7. Section 4 - "Time Source: The wall clock time provides the DNSSEC Validation Engine the current time. Time is one input used to validate the RRSIG Signature and Inception Fields to provide some protection against replay attacks." Unless the reader of this document keeps their 'wall clocks' in UTC, the timestamps used in DNSSEC are not wall clock time.

8. Sections 3 & 4 - Section 3 defines "Trust Anchor Data Store", and Section 4 redefines the same concept as "Trust Anchor Manager", without referring to the previously-defined Trust Anchor Data Store. In fact "Trust Anchor Data Store" is never used in the document beyond its definition.

The resolver should return information on the reasons a DNSSEC validation fails. This provides the DNS client has a better understanding of the resolution, increases trust in the resolver.