I’d tried that…this has been going on for five days, and I can not describe my level of frustration. But I solved it, literally just now.

Despite systemctl status apparmor.service claiming it was inactive, it was secretly active. audit.log was so full of sudo that I failed to see all of the

apparmor=“DENIED” operation=“mknod” profile=“/usr/sbin/named” name=“/etc/bind/dnssec-keys/K[zone].+013+16035.l6WOJd” pid=152161 comm=“isc-net-0002” requested_mask=“c” denied_mask=“c” fsuid=124 ouid=124FSUID=“bind” OUID=“bind”

That made me realize, when I thought I fixed the apparmor rule, I’d used /etc/bind/dnskey/ rw instead of /etc/bind/dnskey/** rw

The bind manual claims that you don’t need to manually create keys or manually include them in your zone file, if you use dnssec-policy default or presumably any other policy with inline-signing. Claims that bind will generate its own keys, write them, and even manage timed rotation or migration to a new policy. I can’t confirm or deny that, because it definitely found the keys I had manually created (one of which was $INCLUDEd in the zone file, and one not) and used them. It also edited them and created .state files.

I feel like I should take the rest of the day off and celebrate.