On 14 April 2018 at 12:54, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > A number of checks are listed in: > > https://tools.ietf.org/html/draft-ietf-regext-dnsoperator- > to-rrr-protocol-04#section-3.4 > > that are intended to make sure a domain is ready for DNSSEC. > > As I've been the DNSSEC and DANE implementations at now ~5.8 million > domains, I'd like to suggest some additional checks: > Thanks for the review Viktor. We haven't had many DNS people respond to the draft.. I've been considering mentioning it in DNSOP, but was going to wait until several pending changes are in the doc and -05 is out (hopefully in the next week or two, time permitting). > > o ensuring that the SOA record RRset is correctly signed, unlike: > > http://dnsviz.net/d/_25._tcp.mx1.techtrack.gov/dnssec/ > > which is always incremented by 1 *after* the zone is signed! > I believe this is already covered by the first point: "checks that the child zone is is properly signed as per the Registration Entity and parent DNSSEC policies". Although, we could add some example RRsets that should be examined for correct signatures. > o ensuring the NS RRset at the zone apex matches the glue RRs > at the parent zone > o Verifying that TLSA lookups are NOT blocked and denial of > existence works by querying for: > > _25._tcp.<nonce>.example.net. IN TLSA ? > > and verifying the NXDomain, NODATA, or (very rarely) wildcard > TLSA records against the implied DNSKEYs. The nonce can be some > random hex string of 8 or more bytes, that is unlikely to be an > actual name in the zone. > > o Do the above for all IPv4 and IPv6 addresses of all the > nameservers, > as some misconfigured firewalls block unexpected RR types for just > IPv4 or just IPv6. > > o A similar probe for CAA records is likely appropriate, Let's > Encrypt > runs into CAA lookup issues for a non-negligible fraction of > domains. > These are getting into name server quality checks, and not security checks, which is the point of the acceptance testing. I don't agree that these should be part of this document. > > o Check that if the zone uses RSA, the KSK and ZSK are at least 1280 > bits and at most 2048 bits. This may be controversial, but for new > deployments RSA <= 1024 bits is widely considered too weak, and RSA > with more than 2048 bits creates signatures that are often too > large > for reliable UDP transport. > While this is probably a reasonable thing to do, a registration mechanism documented in REGEXT is not the place to do this. I think if DNSOP wants such advice in a standard there should be a BCP document out of DNSOP that defines it. > > o Check that if the zone uses NSEC3 the NSEC3PARAM iteration count is > at most 150 (regardless of RSA key size). Larger iteration counts > are both inefficient and fragile in the face of algorithm > rollovers. > The optimal value is 0 (performs one round of SHA1, which is > enough to > deter casual zone walking). The most popular value is 1, which is > very likely because it is slightly unclear whether 0 means no hash > or (as is the case) just one initial hash. So hats off to the > operations that chose 1, they understand that the count should be > low, and are careful to avoid edge cases. > Again, I think this is out of scope of a document standardizing a registration mechanism. Besides which, there are operators out there who deliberately have a low iteration count because they don't care about zone walking, and are only using NSEC3 for the opt-out capability.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
