Changes BIND 9.15+ source distribution (gz -> xz, and SHA1 deprecation)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Changes BIND 9.15+ source distribution (gz -> xz, and SHA1 deprecation)

Ondřej Surý
Hi,

the BIND 9 development team has decided to change the compression method for BIND 9.15.7, and also for the next BIND 9.16.0 release to widely available **xz** compression algorithm.  Therefore, the tarball extension has changed from https://downloads.isc.org/isc/bind9/9.15.7/bind-9.15.7.tar.gz to https://downloads.isc.org/isc/bind9/9.15.7/bind-9.15.7.tar.xz

xz offers considerable savings in terms of disk space and thus network traffic and the tool is available in the base system for most if not all Linux and BSD distributions.

The previous versions of BIND 9 (9.11 and 9.14) are still distributed compressed with gzip.

The other change we will introduce early next year (timed with BIND 9.16.0 release) is the deprecation of SHA1 checksums.  The MD based algorithms are no longer collision resistant enough and henceforth the SHA1 based checksums no longer bear any real value.

Ondrej
--
Ondřej Surý
[hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Changes BIND 9.15+ source distribution (gz -> xz, and SHA1 deprecation)

Alan Batie
On 12/19/19 1:16 AM, Ondřej Surý wrote:

> The other change we will introduce early next year (timed with BIND 9.16.0 release) is the deprecation of SHA1 checksums.

This is timely as I was about to ask if there's any reason to generate
SHA1 DNSKEY records?  I should think that anything I care about can
handle SHA256 these days...


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changes BIND 9.15+ source distribution (gz -> xz, and SHA1 deprecation)

Tony Finch
Alan Batie <[hidden email]> wrote:
>
> This is timely as I was about to ask if there's any reason to generate
> SHA1 DNSKEY records?  I should think that anything I care about can
> handle SHA256 these days...

There are extremely strong reasons for NOT generating SHA1 DNSKEY records!

https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html

There are sadly still a lot of SHA1 zones out there, so it can't yet be
disabled outright, but we need to get rid of it as soon as possible.

https://www.dns.cam.ac.uk/news/2020-02-14-sha-mbles.html

I recommend that new SHA1 keys (algorithms 5 and 7) are never generated.
The only exception is to support routine ZSK rollovers for zones that are
already signed with algo 5 or 7. Don't do same-algorithm KSK rollovers in
these zones, do an algorithm rollover instead, as soon as possible, to
algorithm 13 (ECDSA P256) or 8 (RSA SHA256). For zones that are being
signed for the first time, use algorithm 13 or 8.

RSASHA256 is used by the root zone so it has been universally supported
for over 10 years. Algorithm rollovers are relatively easy now. (The bugs
in certain validating resolvers that made things tricky are long gone.)

https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html

(I was near the end of a very belated algorithm rollover project when the
SHA-mbles collision was announced!)

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Lyme Regis to Lands End including the Isles of Scilly: Northwest 4 or 5,
backing west 3, then backing southeast 5 or 6, then veering southwest later.
Moderate or rough in far west, otherwise slight or moderate. Showers then
fair, rain later. Good, occasionally moderate later.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Changes BIND 9.15+ source distribution (gz -> xz, and SHA1 deprecation)

Alan Batie
On 3/3/20 8:59 AM, Tony Finch wrote:
> Alan Batie <[hidden email]> wrote:
>>
>> This is timely as I was about to ask if there's any reason to generate
>> SHA1 DNSKEY records?  I should think that anything I care about can
>> handle SHA256 these days...
>
> There are extremely strong reasons for NOT generating SHA1 DNSKEY records!

That was my thought, but the tools complain about not having both...

# dnssec-verify -v 9 -I raw -o domain.com domain.com.signed
Loading zone 'domain.com' from file 'domain.com.signed'
Verifying the zone using the following algorithms: RSASHA256.
Missing self-signed KSK for algorithm RSASHA1
Missing ZSK for algorithm RSASHA256
The zone is not fully signed for the following algorithms: RSASHA1
RSASHA256.
dnssec-verify: fatal: DNSSEC completeness test failed.


Still working out which ones it thinks are missing, as both appear to be
there - it would be nice if the tool was more specific...


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changes BIND 9.15+ source distribution (gz -> xz, and SHA1 deprecation)

Tony Finch
Alan Batie <[hidden email]> wrote:
>
> That was my thought, but the tools complain about not having both...

[snip]

> Still working out which ones it thinks are missing, as both appear to be
> there - it would be nice if the tool was more specific...

If you are doing an algorithm rollover, you should have 2 keys (ZSK and
KSK) for each algorithm, 4 keys total. I only use dnssec-signzone if I'm
testing or doing something weird, so I'm not familiar with it. (In
production I use automatic signing in `named` because it is easier.) But
you might be able to follow my howto inserting a dnssec-signzone before
rndc reload and you might get something that will approximately work...

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Irish Sea: Westerly becoming variable, then northeasterly later, 2 to 4,
occasionally 5 in south. Slight or moderate in south, smooth or slight in
north. Rain or showers. Good, occasionally poor in south.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Changes BIND 9.15+ source distribution (gz -> xz, and SHA1 deprecation)

Alan Batie
On 3/3/20 5:26 PM, Tony Finch wrote:

> If you are doing an algorithm rollover, you should have 2 keys (ZSK and
> KSK) for each algorithm, 4 keys total. I only use dnssec-signzone if I'm
> testing or doing something weird, so I'm not familiar with it. (In
> production I use automatic signing in `named` because it is easier.) But
> you might be able to follow my howto inserting a dnssec-signzone before
> rndc reload and you might get something that will approximately work...

I'm letting named do the automatic signing/generation of RRSIG records,
but unless I'm missing something, you still have to generate the DNSKEY
records manually.  dnssec-verify is the tool in question complaining
about not including RSASHA1 keys and signatures.  I'm still in the
initial phases of setting this up, so I don't have to worry about
algorithm rollover so much, as except for a couple of test domains,
there's no DS record to cause them to get used.  I did build scripts for
doing the zsk and ksk rollovers though.

In short, I'm setting things up so there's only two keys: ksk and zsk
using RSASHA256, which I think is the way things should be these days.


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changes BIND 9.15+ source distribution (gz -> xz, and SHA1 deprecation)

Tony Finch
Alan Batie <[hidden email]> wrote:
>
> I'm letting named do the automatic signing/generation of RRSIG records,
> but unless I'm missing something, you still have to generate the DNSKEY
> records manually.  dnssec-verify is the tool in question complaining
> about not including RSASHA1 keys and signatures.

Oh whoops, sorry, I wasn't paying proper attention.

I think those errors from dnssec-verify look to me like you have an
RSASHA256 KSK and an RSASHA1 ZSK. Your key files should all have names
like K*+008+* not K*+005+*. In older versions of BIND it's easy to
accidentally get a bad key by forgetting the -a option to dnssec-keygen.

(BTW I prefer to talk about "keys" when I have the files with both the
public and private parts, and only talk about DNSKEYs when I'm referring
to the public parts published in zone files.)

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
a fair, free and open society
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Changes BIND 9.15+ source distribution (gz -> xz, and SHA1 deprecation)

Alan Batie
On 3/5/20 5:26 AM, Tony Finch wrote:

> I think those errors from dnssec-verify look to me like you have an
> RSASHA256 KSK and an RSASHA1 ZSK. Your key files should all have names
> like K*+008+* not K*+005+*. In older versions of BIND it's easy to
> accidentally get a bad key by forgetting the -a option to dnssec-keygen.

That sounds like a likely scenario actually

> (BTW I prefer to talk about "keys" when I have the files with both the
> public and private parts, and only talk about DNSKEYs when I'm referring
> to the public parts published in zone files.)

Seems reasonable, thanks


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment