TL;DR use ECDSA, single algorithm
https://tools.ietf.org/html/rfc8624
--
Ondřej Surý
ond...@isc.org
> On 11 Oct 2019, at 08:38, ego...@sarenet.es wrote:
>
> Good afternoon,
>
> I would like to ask you some questions about DNSSEC, which I have not been
> able to clarify by my own, reading documentation or testing… they are these
> ones :
>
> - Is it important or should be signed the whole zone with a “compatible"
> algorithm as SHA1 and with a stronger one like SHA256 or is it just ok with
> SHA256?. I would like to avoid the fact that a resolver could have issues
> validating rrsets… I have seen root servers DS has algorithm id 7. Perhaps is
> this one the most compatible algorithm for using in DNSSEC?. The most
> recommended?. Perhaps we should just use for all keys algorithm 7 as have
> seen some root servers use?.
Use ECDSA, it’s well-supported.
> - If I wanted to sign a zone for instance in 5 and 7 algorithm (if it’s
> advisable, as isc.org for instance is signed with two algorithms), should I
> run dnssec-sigzone twice and/or perhaps with two different keys?. Can the
> same key converted to one kind of key to another (from sha1 to sha256 or
> sha256 to sha1) for this purpose?. I have seen isc.org does double signing
> with two different algorithms so… what is the recommended practice here?.
It’s not advisable. It just increases the response size.
> - I have seen the procedure of key rolling over. I have seen there is a
> manual procedure. Perhaps the most advantageous aspect of manual handling of
> zone signing, can be that you can revoke privileges to Bind to read the
> private keys?. I say it, because you generate as root for instance, a signed
> zone file and then you just serve it as a master zone… and perhaps the
> flexibility you have with it?.
Could you please rephrase? I don’t know what you are asking about...
For the rest, I would recommend using inline-signing with auto-dnssec and
dnssec-keymgr tool from BIND distribution to manage the keys, and set some
reasonable times for ZSK rollovers (1 year+). Roll keys only if there’s a
security breach. There’s no cryptographic need to roll the keys if you pick
ECDSA. If there will be, you will get that in the news :), and we’ll be in
much bigger troubles than broken DNSSEC.
> - By the way, I have seen that exists too the possibility of a slightly less
> complicated way of signing a zone, the dynamic one, but… you have to update
> the zone as a dynamic zone with nsupdate for including in the zone the
> DNSKEYS and you need to manage by your own equally the key regeneration (the
> keys files generation with dnssec-keygen) for avoiding having your zone
> signatures expired, am I wrong?…. I think that instead of using this method,
> perhaps could be better to use inline signing method instead (if you decide
> discarding totally manual method…)?… which by the way… allows you to not
> having a ”real” “declared” dynamic zone… with dynamic updates… but… in either
> dynamic key roll over method, do you have equally to create by your own, new
> keys (mainly talking now about ZSK because KSK needs to update DS in the root
> servers) in the key directory of the zone for resigning the zone?. The
> recommended method for that is dnssec-keygen -S?.
>
> - It seems inline signing method of key rolling over does not allow you to
> choose the key rolling over method?. How does, inline-signing manage the zone
> sign in the terms of which key algorithm, rollover method and so, does use?.
>
> - Do you have a minimum time a zsk should be enabled?. I say it, because even
> setting the zsk key this way :
>
> ; This is a zone-signing key, keyid 45018, for seranet.es.
> ; Created: 20191010111754 (Thu Oct 10 13:17:54 2019)
> ; Publish: 20191010111754 (Thu Oct 10 13:17:54 2019)
> ; Activate: 20191010111754 (Thu Oct 10 13:17:54 2019)
> ; Inactive: 20191010131754 (Thu Oct 10 15:17:54 2019)
> ; Delete: 20191010151754 (Thu Oct 10 17:17:54 2019)
> seranet.es. IN DNSKEY 256 3 8
> AwEAAdrLnpJilOPdAh8Y1LLPpLCB+600MqhwuaEVYYQ4wWMXdl+JaeFm
> wUIVUd3BSR+qz034t7VT/8rtIzc6jXaoOjqvIbnS5NMje49503Fikt7X
> WwST61AhtghrGFl6Wl27E3WT5s3IlJFDUo1efLy0E18qm5Q8JPkt38zI BJ9339HL
> dig seranet.es a +dnssec
>
> ; <<>> DiG 9.10.6 <<>> seranet.es a +dnssec
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8734
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;seranet.es. IN A
>
> ;; AUTHORITY SECTION:
> seranet.es. 300 IN SOA ns1.sarenet.es.
> dnsmaster.sarenet.es. 2019101005 86400 7200 2592000 300
> seranet.es. 300 IN RRSIG SOA 8 2 300 20191109151754
> 20191010141754 38689 seranet.es.
> FCG4zWvtZ3/DfnKuAj+O9drdVFGkmoyGY8PssnMLGG3G5yf0GIXu4dob
> r/i/BBuV+Y8gtcrbAWRD7TwlWYId6Rlazwn80MJncGH1JVMVtcJIfM+E
> 8sq6yWBhHkswUX0UCwFpu1/cNg0vKad7VMxtW4ycZEcN3+NnWyU+yT+L
> g7usDNd6kEB/fsO+9Z3ioCBS0wGzW3Kv/SOlmkhiHkux+Eg/X97G8f8C
> 1BUXpEtJ/SGY715q+XYn78SowQQ5GjgI2EVgG8qgNFu6zlex2HX8US7T
> mL62Lu0FS4TNMTPAstiFmEXn4nOAf86jE1IeYLdMGpTd+LOUHM1yOgKn IuAS6Q==
> H4MU3S6CAIE18L011AOHNRKSD5FBVEAB.seranet.es. 300 IN RRSIG NSEC3 8 3 300
> 20191105235142 20191010141754 38689 seranet.es.
> AfCHv2pcGq2bXP9/nRwe7s4g1zBavup1YsbHRF7qhZf5luC3OqnHII+N
> 2Hz2Gv58/35R+l2tDdEQerzgRF7jOy60sdVRStUX9gmuLUoYgcAUm9dg
> R52E7QnN0DMvgGwn1ET1JxLzCJ15fCK+rsnkBh7ZKousmMgt7a1psjwM
> VzcgYsrkBdhv6rNPLEfifbz0X3G+KmdToXIkejkcig+O8jtO2eBGuHfA
> 7RW2ByH44x6Kw1QGHtg1a+KvgD1R0fpRDH0svuivzKF4fb9YYpviipNV
> x5MsAduESxm4PviqRTrRfUSC9eJ9Zx08Nr8qh3VRt+TmZtZFJ2p737Sn H+vp6g==
> H4MU3S6CAIE18L011AOHNRKSD5FBVEAB.seranet.es. 300 IN NSEC3 1 0 100 1CA7B3AC
> V4LV1AUI40OATTPVFINRGQMESCHEUE1F NS SOA MX RRSIG DNSKEY NSEC3PARAM
>
> The RRSIG sais as expiration date 20191109151754...
>
> - The revoke state of a key, it’s just for emergencies when the private key
> of the key pair has been compromised?. I mean, the only states you usually
> see in a key are, published, activate, inactivate and delete?.
>
> - Perhaps the most proper way of handling dnssec is to just use something as
> :
>
> zone "seranet.es" { type master; inline-signing yes; key-directory
> "/expert/keys/es-domain/named.seranet"; auto-dnssec maintain; file
> "es-domain/named.seranet"; };
>
> as zone config in Bind, and let inline-signing doing it’s job?. Will it
> manage the proper algorithms, rollover methods and so?. If I used this
> method, we should just have to ensure, that in the key directory we always
> have a ready inactive key, for rolling over in the needed date and Bind would
> perform all zone signing tasks (except obviously tell registrar new DS)?… but
> even will it handle KSK roll over?.
>
>
> Thanks you so much in advance… There are questions I have not been able to
> answer by reading books and at the Internet…
>
> Best regards,
>
>
>
> Egoitz Aurrekoetxea
> Dpto. de sistemas
> 944 209 470
> Parque Tecnológico. Edificio 103
> 48170 Zamudio (Bizkaia)
> ego...@sarenet.es
> www.sarenet.es
>
> Antes de imprimir este correo electrónico piense si es necesario hacerlo.
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
