Re: understanding keymgr handling of KSK
Hi,
On 09-05-2022 10:16, Bjørn Mork wrote:
Michael Richardson via bind-users writes:
4) I don't understand the difference between "auto-dnssec maintain;"
and "dnssec-policy default" (given that I haven't overridden anything).
I believe the only difference is that the latter will track your keys in
addition to the automatic signing. And it will auto-generate CDS and
CDNSKEY records. None of which matters much until you start using it
for automatic rollovers.
'auto-dnssec maintain' will also adjust the DNSSEC keys according to the
key timing metadata ('auto-dnssec allow' will only update signatures).
'dnssec-policy' is also able to create new keys when needed and allows
you to specify a policy for DNSSEC signing (roughly put: it moves
dnssec-keymgr functionality inside BIND).
I am not sure, but I suspect this is because the key didn't match your
dnssec-policy. So the rollover started immediately when you configured
dnssec-policy, with a fresh KSK generatated and removal of the existing
keys with "wrong" algorithms scheduled.
I suspect so too.
AFAIK, I'm not doing CDS (I'd like to, but I don't know how, and I don't know
if .org is doing it).
Yes, same here. This is not a problem. I learned from the discussion
here earlier that BIND will just wait for me to manually tell if about
the DS state using "rndc dnssec -checkds ...". Which is fine.
What's surprising is that the KSK went missing without you telling BIND
that the DS was removed. I wonder if the problem is that it started out
already having "DSState: hidden" because of the policy mismatch?
Yes, if BIND thinks the DS is not known to the world, it may remove the
DNSKEY record.
- Matthijs
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: understanding keymgr handling of KSK
Michael Richardson via bind-users writes: > I have moved from dnssec-tools to having bind9 do all the management itself. > There are a couple of things that I don't understand, and I find that the > FAQs and howtos I've read are rather too introductory for me. > I have been signing my zones since around 2004... FWIW, this guide helped me a lot: https://kb.isc.org/docs/dnssec-key-and-signing-policy And it is updated and improved based on the feedback here. So report anything you find missing or confusing. > 4) I don't understand the difference between "auto-dnssec maintain;" >and "dnssec-policy default" (given that I haven't overridden anything). I believe the only difference is that the latter will track your keys in addition to the automatic signing. And it will auto-generate CDS and CDNSKEY records. None of which matters much until you start using it for automatic rollovers. But you should note the hints for migrating already signed zones: https://kb.isc.org/docs/dnssec-key-and-signing-policy#migrate-to-dnssec-policy In particular the importance of matching your existing keys: "if your zone uses another algorithm or has a separate KSK and ZSK, setting the default policy to your zone immediately starts a rollover because the existing keys do not match the given policy" > 5) Did $INCLUDE change such that it no longer accepts path names relative to > the > zone file that included it? (no, not really DNSSEC related, but maybe bind > 9.11 vs bind 9.16 changes) It has never been relative to the zone file AFAIK. It's relative to the working directory. See https://bind9.readthedocs.io/en/latest/reference.html#the-include-directive and the "directory" node under options: https://bind9.readthedocs.io/en/latest/reference.html#options-statement-definition-and-usage So I guess you have kept your zone files in the working directory earlier, and then moved them somewhere else? This would break any relative $INCLUDE directive. > 6) Sometime yesterday (or maybe Friday night) many of my zones went offline: > > tuna-[~] lmcr 10002 %dig @8.8.8.8 list.goslingcommunity.org > > ; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> @8.8.8.8 > list.goslingcommunity.org > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45108 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > looks like failure to find the right keys. > > I investigated, and the first thing I did was "rndc reload", and magically > everything started working again. No idea what happened. > > I poke around and I look at one of the state files: > > tilapia-[/etc/domain/brski.org] mcr 10010 %cat Krfc8995.org.+013+65171.state > ; This is the state of key 65171, for rfc8995.org. > Algorithm: 13 > Length: 256 > KSK: yes > ZSK: no > Generated: 20210503023712 (Sun May 2 22:37:12 2021) > Published: 20210503023712 (Sun May 2 22:37:12 2021) > Active: 20210503023712 (Sun May 2 22:37:12 2021) > Retired: 20220505221112 (Thu May 5 18:11:12 2022) > Removed: 20220507001112 (Fri May 6 20:11:12 2022)<<< > SURPRISING!!! > DNSKEYChange: 20220505221612 (Thu May 5 18:16:12 2022) > ZRRSIGChange: 20220506231836 (Fri May 6 19:18:36 2022) > KRRSIGChange: 20220505221612 (Thu May 5 18:16:12 2022) > DSChange: 20220505221112 (Thu May 5 18:11:12 2022) > DNSKEYState: hidden > ZRRSIGState: hidden > KRRSIGState: hidden > DSState: hidden > GoalState: hidden > > okay, let's go look at the one that I had the servfail for: > > tilapia-[/etc/domain/goslingcommunity.org] mcr 10029 %cat > Kgoslingcommunity.org.+005+05881.state > ; This is the state of key 5881, for goslingcommunity.org. > Algorithm: 5 > Length: 2048 So these two zones use different algorithms, and the one that failed does not use the default dnssec-policy algorithm. So you must create your own policy if you want to migrate this zone without initiating an immediate algorithm rollover. And I believe you should wait with any rollovers until you are confident that you have a stable and working configuration matching your exisiting setup. Did you create your own policies, and what do they look like? Maybe not switch over all zones at once, but experiment on one or two less important (or "dummy") zones first? Not that I personally followed that advice, but I'm known to be more impatient than smart ;-) > KSK: yes > ZSK: no > Generated: 20190808220317 (Thu Aug 8 18:03:17 2019) > Published: 20190808220317 (Thu Aug 8 18:03:17 2019) > Active: 20190808220317 (Thu Aug 8 18:03:17 2019) > Retired: 20220505221645 (Thu May 5 18:16:45 2022) > Removed: 20220507001645 (Fri May 6 20:16:45 2022) > DNSKEYChange: 20220505222145 (Thu May 5 18:21:45 2022) > ZRRSIGChange: 20220506232645 (Fri May 6 19:26:45 2022) > KRRSIGChange: 20220505222145 (Thu May 5 18:21:45 2022) > DSChange: 20220505221645 (Thu May 5 18:16:45 2022) > DNSKEYState: hidden > ZRRSIGState: hidden > KRRSIGState: hidden > DSState: hidden > GoalSta
Re: understanding keymgr handling of KSK
I found this message: May 8 16:41:18 tilapia named[1268]: zone ox.org/IN: zone_rekey:dns_dnssec_keymgr failed: error occurred writing key to disk It would be great if it could tell me the file name that failed to write, and ideally what the error was (EPERM is my guess, but there could also be AppArmor stupids for some people which are really hard to diagnose). Is there a way to put all the keymgr logging into a different debug stream? Ideally, I think I need it emailed to me daily :-) -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
understanding keymgr handling of KSK
I have moved from dnssec-tools to having bind9 do all the management itself. There are a couple of things that I don't understand, and I find that the FAQs and howtos I've read are rather too introductory for me. I have been signing my zones since around 2004... I will attempt to blog some of my experiences, but I'm a bit lost. I keep my zones in /etc/domain/foo.com/db.foo.com, usually a few zones in "foo.com" related to foo.com, like foo.net, reverses... and I allow Debian's etckeeper to track changes there. etckeeper is mostly very nice, but there is some interaction among tools that sometimes winds up with my zone files getting truncated to zero. But, it being git, one can keep extra copies. I haven't caught it in the act yet. Probably I should change the key-directory to be a different directory, because maybe letting etckeeper do stuff with keys is a bad idea. (I'm more concerned about keys getting lost due to VMs going bad that I am about keys getting disclosed because I git cloned the repo to my laptop. You may feel different about security, good for you) 1) I'm unclear about freeze/thaw and signing and editing. I prefer to edit my zones with vi/emacs/sshfs/tramp. For that reason, I have them g+w, group bind, and my login is in the "bind" group, and my user id can rndc reload. 2) I've historically had a perl script that updated the SERIAL in place, based upon MMDDLL, where XX was Hour*4 + minutes/15. And LL was always maintained as > than last time. https://www.sandelman.ca/tmp/updateser you care. 3) I have a very few dynamic zones which are updated by DNS update. I have basically CNAME'ed all my dns-01 LetsEncrypt challenges into a single zone that I allow to completely dynamically managed. 4) I don't understand the difference between "auto-dnssec maintain;" and "dnssec-policy default" (given that I haven't overridden anything). 5) Did $INCLUDE change such that it no longer accepts path names relative to the zone file that included it? (no, not really DNSSEC related, but maybe bind 9.11 vs bind 9.16 changes) 6) Sometime yesterday (or maybe Friday night) many of my zones went offline: tuna-[~] lmcr 10002 %dig @8.8.8.8 list.goslingcommunity.org ; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> @8.8.8.8 list.goslingcommunity.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45108 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 looks like failure to find the right keys. I investigated, and the first thing I did was "rndc reload", and magically everything started working again. No idea what happened. I poke around and I look at one of the state files: tilapia-[/etc/domain/brski.org] mcr 10010 %cat Krfc8995.org.+013+65171.state ; This is the state of key 65171, for rfc8995.org. Algorithm: 13 Length: 256 KSK: yes ZSK: no Generated: 20210503023712 (Sun May 2 22:37:12 2021) Published: 20210503023712 (Sun May 2 22:37:12 2021) Active: 20210503023712 (Sun May 2 22:37:12 2021) Retired: 20220505221112 (Thu May 5 18:11:12 2022) Removed: 20220507001112 (Fri May 6 20:11:12 2022)<<< SURPRISING!!! DNSKEYChange: 20220505221612 (Thu May 5 18:16:12 2022) ZRRSIGChange: 20220506231836 (Fri May 6 19:18:36 2022) KRRSIGChange: 20220505221612 (Thu May 5 18:16:12 2022) DSChange: 20220505221112 (Thu May 5 18:11:12 2022) DNSKEYState: hidden ZRRSIGState: hidden KRRSIGState: hidden DSState: hidden GoalState: hidden okay, let's go look at the one that I had the servfail for: tilapia-[/etc/domain/goslingcommunity.org] mcr 10029 %cat Kgoslingcommunity.org.+005+05881.state ; This is the state of key 5881, for goslingcommunity.org. Algorithm: 5 Length: 2048 KSK: yes ZSK: no Generated: 20190808220317 (Thu Aug 8 18:03:17 2019) Published: 20190808220317 (Thu Aug 8 18:03:17 2019) Active: 20190808220317 (Thu Aug 8 18:03:17 2019) Retired: 20220505221645 (Thu May 5 18:16:45 2022) Removed: 20220507001645 (Fri May 6 20:16:45 2022) DNSKEYChange: 20220505222145 (Thu May 5 18:21:45 2022) ZRRSIGChange: 20220506232645 (Fri May 6 19:26:45 2022) KRRSIGChange: 20220505222145 (Thu May 5 18:21:45 2022) DSChange: 20220505221645 (Thu May 5 18:16:45 2022) DNSKEYState: hidden ZRRSIGState: hidden KRRSIGState: hidden DSState: hidden GoalState: hidden Some surprising things here. The key was generated ages ago, great. It was removed on Friday evening what? But, it's a KSK. To update it, I need to visit my registrar and update things. AFAIK, I'm not doing CDS (I'd like to, but I don't know how, and I don't know if .org is doing it). tilapia-[/etc/domain/goslingcommunity.org] mcr 10034 %dig +short @a0.org.afilias-nst.org. goslingcommunity.org. ds 5881 5 1 64E6DE566F8F3E33B83FCF51DDE6746872E51432 5881 5 2 5F7C3229244CFE80835B1FCAE94BE8ED2CF26D31942E1628C3D1E7A9 A026535A No change in the key at .org, and I checked and I don't have a CDS published. So what happened? I shall troll my logs and see w
