Selfhosted @lemmy.world tburkhol @lemmy.world 10mo ago

Bind 9.18.18 dnssec key location and privileges?

[update, solved] It was apparmor, which was lying about being inactive. Ubuntu's default profile denies bind write access to its config directory. Needed to add /etc/bind/dnskeys/** rw, reload apparmor, and it's all good.

Trying to switch my internal domain from auto-dnssec maintain to dnssec-policy default. Zone is signed but not secure and logs are full of

zone_rekey:dns_dnssec_keymgr failed: error occurred writing key to disk

key-directory is /etc/bind/dnskeys, owned bind:bind, and named runs as bind

I've set every directory I could think of to 777: /etc/bind, /etc/bind/dnskeys, /var/lib/bind, /var/cache/bind, /var/log/bind. I disabled apparmor, in case it was blocking.

A signed zone file appears, but I can't dig any DNSKEYs or RRSIGs. named-checkzone says there's nsec records in the signed file, so something is happening, but I'm guessing it all stops when keymgr fails to write the key.

I tried manually generating a key and sticking it in dnskeys, but this doesn't appear to be used.

3 comments

You need to include the files in the zone file. Bind 9.18.18 is a mess with the changed DNSSEC setup, it broke my domains as well. I't isn the bind documentation, so I have to refer you there. I have no access to my setup now (or my browser history) as I'm not at my computer.

Edit: managed to get in dns.

named.conf.local: zonefile needa to be the .signed file the unsigned zone file must have both keys included, best is via absolute path:

$INCLUDE "/etc/bind/keys/example.com.123456.key"

for both the ZSK and KSK keys. The include is to get the RRSIG entries.
- 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.
  
  Sorry, totally forgot apparmor. On debian that thing can be nasty, I had to fix those rules as well for bind That was years ago and was added to my Puppet module, so I forgot.