From greg at isc.org Wed Sep 15 07:27:17 2021 From: greg at isc.org (Greg Choules) Date: Wed, 15 Sep 2021 07:27:17 +0000 (UTC) Subject: New BIND releases are available: 9.16.21 and 9.17.18 Message-ID: <578047166.1376014.1631690837262.JavaMail.zimbra@isc.org> Our September maintenance releases of BIND are available and can be downloaded from the ISC software download page, https://www.isc.org/download As it happens, this month there were no significant changes to the 9.11 branch and as a result there is no September release for it. More significant changes were made in the 9.16 and 9.17 release branches. A summary of significant changes in the September releases can be found in their release notes: Current supported stable branches: 9.11.35 - https://downloads.isc.org/isc/bind9/9.11.35/RELEASE-NOTES-bind-9.11.35.html (August release) 9.16.21 - https://downloads.isc.org/isc/bind9/9.16.21/doc/arm/html/notes.html Experimental development branch: 9.17.18 - https://downloads.isc.org/isc/bind9/9.17.18/doc/arm/html/notes.html From ebf at isc.org Tue Sep 28 21:35:24 2021 From: ebf at isc.org (Everett B. Fulton) Date: Tue, 28 Sep 2021 16:35:24 -0500 Subject: Operational Notification: NSEC3 hash iterations should be minimised. Message-ID: Posting date: 28 September 2021 Program impacted: BIND Versions affected: All versions of BIND that support DNSSEC zone signing with NSEC3 Description: This notification describes a recommended change in DNSSEC practice relating to authoritative zones that are DNSSEC-signed using NSEC3. Although we are issuing this advisory to users of BIND, the advice therein is also applicable to authoritative zone operators using other DNS implementations. DNSSEC-signed zones offer protection against response spoofing to both DNSSEC-validating resolvers and authoritative DNS zone operators who choose to sign their published zones. NSEC and NSEC3 are the mechanisms within DNSSEC used to provide proof of non-existence of names. This is achieved by a DNSSEC-signed assurance that between two signed names, no other names exist. NSEC3 uses hash mechanisms to avoid disclosure of the bounding names themselves, otherwise it is possible to establish a list of all names in a zone by 'walking' the non-existence bounds chain (NSEC). NSEC3 records are created by first hashing the input domain and then repeating that hashing algorithm a number of times based on the iterations parameter in the NSEC3PARM and NSEC3 records. The use of non-zero NSEC3 iterations is largely now held to be ineffectual against a determined attacker. Furthermore, the use of NSEC3 iterations impose a significant computational overhead on DNSSEC-processing. Updated best practice guidance for NSEC3 is to select an iteration value of 0 (in other words, use no additional hash iterations). BIND and other DNS resolver implementations are being updated to treat DNSSEC-signed zones as insecure (unsigned) if the zone operator is using NSEC3 with greater than 150 iterations. For more information and additional references, see ISC KB article https://kb.isc.org/docs/dnssec-signed-zones-best-practice-guidance-for-nsec3-iterations Impact: Operators of DNSSEC-signed authoritative zones using NSEC3 iterations greater than 150 will weaken rather than strengthen their zone's DNSSEC security. Solution: Review your DNSSEC implementation. If you are maintaining DNSSEC-signed zones using NSEC3 with iterations greater than 150 and prefer not to follow updated best practice guidance to use a value of 0 (no additional hash iterations beyond the first one), then to ensure that your zone is still secure, reduce the iterations to a value less than 150 so that DNSSEC-validating resolvers do not downgrade responses from your zone's servers to insecure (unsigned). Note: The validation limit on NSEC3 additional hash iterations has been set at 150 in 2021, but may be further reduced in future years. Related documents: BIND Administrator Reference Manual section on DNSSEC. ISC KB article https://kb.isc.org/docs/dnssec-signed-zones-best-practice-guidance-for-nsec3-iterations IETF Draft https://datatracker.ietf.org/doc/html/draft-hardaker-dnsop-nsec3-guidance Do you still have questions? Questions regarding this advisory should go to security-officer at isc.org. To report a new issue, please encrypt your message using security-officer at isc.org's PGP key which can be found here: https://www.isc.org/pgpkey/. If you are unable to use encrypted email, you may also report new issues at: https://www.isc.org/reportbug/. Note: ISC patches only currently supported versions. When possible we indicate EOL versions affected. (For current information on which versions are actively supported, please see https://www.isc.org/download/.) ISC Security Vulnerability Disclosure Policy: Details of our current security advisory policy and practice can be found in the ISC Software Defect and Security Vulnerability Disclosure Policy at https://kb.isc.org/docs/aa-00861. Legal Disclaimer: Internet Systems Consortium (ISC) is providing this notice on an "AS IS" basis. No warranty or guarantee of any kind is expressed in this notice and none should be implied. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any implied warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use or reliance on this notice or materials referred to in this notice is at your own risk. ISC may change this notice at any time. A stand-alone copy or paraphrase of the text of this document that omits the document URL is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors. -- Kind regards, Everett B. Fulton ISC Support