Michael Richardson via bind-users <bind-users@lists.isc.org> 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 > 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. Looks like it was retired on Thursday. so I believe removed on Friday is expected. 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. > 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? > So what happened? I shall troll my logs and see what else I can find out, > but there sure is a lot of stuff going on. Maybe lots of flotsam from my > previous situation that needs to expunged. I see that you found that keymgr failed to write some key to disk. Maybe the new KSK it generated? If so, then it would have been nice if any rollover to that key paused there... But it probably doesn't. Generally I believe BIND, including keymgr, simply assumes that it can write to any file it needs to change. Otherwise you have undefined behaviour. This goes for journals, slave zones, and dynamic zones as well as the managed keys. Make sure they're all writeable. Bjørn -- 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
