>> to my understanding it is feasible to have DNSSEC served for private >> zones in stub-zone, requiring a trusted key entry with the public key >> in config - that would be trough > trusted-keys-file: <, right? > trusted-keys-file reads the BIND syntax for a key statement, but not the > managed 'db' file that has internal BIND stuff for key rotation.
What is the purpose of > trusted-keys-file < then compared to > trust-anchor-file < except for the BIND-9 style format? Since BIND-9 style format is expressively stated I thought it would makes sense to utilize the BIND-9 zone file directly but apparently being a misconception on my part and thus the question of the purpose of > trusted-keys-file <. > > trust-anchor-file is easy: just copy and paste the DNSKEY or DS records > in there. Like, grep DNSKEY example.com.zone > example.com.key > auto-trust-anchor-file enables RFC5011 rotation and keeps track if the > keys are rotated (like, for the root zone that is important). > > You can start the auto-trust-anchor-file rotation by providing a file > like for trust-anchor-file: a plain text file with DNSKEY or DS records > in there. > > By default chroot is enabled; chroot: "" disables the use of chroot. That is not very clear (to me) from the online documentation: > The default is "/usr/local/etc/unbound". If you give "" no chroot is performed. < It implies a default directory but It does not expressively state that chroot is enabled by default. > > Best regards, Wouter >> Since the authoritative server being Bind 9.13.0 I thought it would make >> sense to utilize its zone file straight away for unbound as > >> trusted-keys-file: "/var/named/mail.db" <. However, unbound is reporting >> >> /etc/unbound/var/named/mail.db: No such file or directory >> [1532614243] unbound-checkconf[2467:0] fatal error: trusted-keys-file: >> "/var/named/mail.db" does not exist in chrootdir /etc/unbound >> >> There is no chroot directive in the unbound conf however...
