1.7.3 - trusted-keys-file location

ѽ҉ᶬḳ℠ vtol at gmx.net
Thu Jul 26 15:34:03 UTC 2018

>> 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...

More information about the Unbound-users mailing list