[DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4
Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 14 April 2018 16:54 UTC
Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E033C126CC4 for <dnsop@ietfa.amsl.com>; Sat, 14 Apr 2018 09:54:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5t2w0h-y_VK for <dnsop@ietfa.amsl.com>; Sat, 14 Apr 2018 09:54:07 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D45A12025C for <dnsop@ietf.org>; Sat, 14 Apr 2018 09:54:07 -0700 (PDT)
Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id C389E7A3309 for <dnsop@ietf.org>; Sat, 14 Apr 2018 16:54:05 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Message-Id: <72D91139-BD51-43A9-8AEA-177753A29F90@dukhovni.org>
Date: Sat, 14 Apr 2018 12:54:04 -0400
To: dnsop@ietf.org
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IJksFj26_cKXeGD56gQQszn7MeI>
Subject: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Apr 2018 16:54:10 -0000
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: 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! 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. 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. 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. -- Viktor.
- [DNSOP] Acceptance processing in draft-ietf-regex… Viktor Dukhovni
- Re: [DNSOP] Acceptance processing in draft-ietf-r… Matthew Pounsett
- Re: [DNSOP] Acceptance processing in draft-ietf-r… Viktor Dukhovni
- Re: [DNSOP] Acceptance processing in draft-ietf-r… Matthew Pounsett
- Re: [DNSOP] Acceptance processing in draft-ietf-r… Viktor Dukhovni
- Re: [DNSOP] Acceptance processing in draft-ietf-r… Viktor Dukhovni
- Re: [DNSOP] Acceptance processing in draft-ietf-r… John Levine
- Re: [DNSOP] Acceptance processing in draft-ietf-r… Viktor Dukhovni
- Re: [DNSOP] Acceptance processing in draft-ietf-r… John Levine
- Re: [DNSOP] Acceptance processing in draft-ietf-r… Viktor Dukhovni
- Re: [DNSOP] Acceptance processing in draft-ietf-r… Jacques Latour
- Re: [DNSOP] Acceptance processing in draft-ietf-r… Viktor Dukhovni
- Re: [DNSOP] Acceptance processing in draft-ietf-r… Matthew Pounsett
- Re: [DNSOP] Acceptance processing in draft-ietf-r… Matthew Pounsett