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?. - If I wanted to sign a zone for instance in 5 and 7 algorithm (if it’s advisable, as isc.org <http://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 <http://isc.org/> does double signing with two different algorithms so… what is the recommended practice here?. - 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?. - 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 <http://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 <http://seranet.es/>. IN DNSKEY 256 3 8 AwEAAdrLnpJilOPdAh8Y1LLPpLCB+600MqhwuaEVYYQ4wWMXdl+JaeFm wUIVUd3BSR+qz034t7VT/8rtIzc6jXaoOjqvIbnS5NMje49503Fikt7X WwST61AhtghrGFl6Wl27E3WT5s3IlJFDUo1efLy0E18qm5Q8JPkt38zI BJ9339HL dig seranet.es <http://seranet.es/> a +dnssec ; <<>> DiG 9.10.6 <<>> seranet.es <http://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 <http://seranet.es/>. IN A ;; AUTHORITY SECTION: seranet.es <http://seranet.es/>. 300 IN SOA ns1.sarenet.es <http://ns1.sarenet.es/>. dnsmaster.sarenet.es <http://dnsmaster.sarenet.es/>. 2019101005 86400 7200 2592000 300 seranet.es <http://seranet.es/>. 300 IN RRSIG SOA 8 2 300 20191109151754 20191010141754 38689 seranet.es <http://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 <http://h4mu3s6caie18l011aohnrksd5fbveab.seranet.es/>. 300 IN RRSIG NSEC3 8 3 300 20191105235142 20191010141754 38689 seranet.es <http://seranet.es/>. AfCHv2pcGq2bXP9/nRwe7s4g1zBavup1YsbHRF7qhZf5luC3OqnHII+N 2Hz2Gv58/35R+l2tDdEQerzgRF7jOy60sdVRStUX9gmuLUoYgcAUm9dg R52E7QnN0DMvgGwn1ET1JxLzCJ15fCK+rsnkBh7ZKousmMgt7a1psjwM VzcgYsrkBdhv6rNPLEfifbz0X3G+KmdToXIkejkcig+O8jtO2eBGuHfA 7RW2ByH44x6Kw1QGHtg1a+KvgD1R0fpRDH0svuivzKF4fb9YYpviipNV x5MsAduESxm4PviqRTrRfUSC9eJ9Zx08Nr8qh3VRt+TmZtZFJ2p737Sn H+vp6g== H4MU3S6CAIE18L011AOHNRKSD5FBVEAB.seranet.es <http://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 <http://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 <mailto:ego...@sarenet.es> www.sarenet.es <http://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
