DNSSEC is a mechanism to protect DNS data. It uses digital signatures. To use it the public keys must be configured. Below this is explained.
Note that your distribution, operating system, or device vendor may have already provided the anchor, securing it with its own vendor-specific update mechanism. In that case, use that.
You must obtain an initial trust anchor. The unbound-anchor tool provides an initial anchor from builtin values, but for real trust you should check this thoroughly.
The root key is stored in a file, /usr/local/etc/unbound/root.key. Unbound must be able to read and write it, to keep it up to date with the latest key(s). It must therefore reside within the chroot of unbound (if that is used). Access rights are world readable, user unbound write only. Use sudo -u unbound to start unbound-anchor so that the file owner is set to the unbound user (same username as daemon uses). You can put it somewhere else, accessible to the unbound daemon, such as /var/unbound or /etc. You need to pass this value to unbound-anchor (option -a file) and to unbound (auto-trust-anchor-file: "file" in unbound.conf).
unbound-anchor creates this file for you if it does not exist. But must check this file so you can trust it. unbound-anchor also has a builtin certificate (from the ICANN Certificate Authority) that it will use to update the root key if it becomes out of date, you should check this too (-l option to show it), or provide some other certificate that you want unbound-anchor to use.
There are trusted community representatives that have sworn and signed attestations, and there may be publications (i.e. in printed form).
Please notice that our unbound-anchor tool provides an initial value for convenience, under the terms of our LICENSE; you must perform your checks to obtain trust.
You can download the trust anchor via https from IANA: root-anchors.xml (click link and then check the lock icon and the urlbar and the hash displayed against the hash you can put as initial value into the root.key file, see below for an example of the syntax of how to input the initial value).
Here are the 2010-2011 and the 2017 trust anchors for the root zone. This is the syntax that you can use to provide an initial value for the root.key file.
. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 . IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
Set the unbound-anchor tool to run at system startup, it is part of the unbound package. This tool checks if the anchor is out-of-date and attempts to update it. A good way is to run it from the init scripts, with sudo -u unbound so that the file permissions work out.
Before unbound-anchor is run inside the init scripts, you must run NTP (in secure mode), so that the time and date have been set properly.
Unbound uses RFC5011 updates to keep the anchor updated if it is changed while the computer is in operation, but the unbound-anchor tool is used if it is changed while the computer is not in operation.
In the unbound.conf config file, include the root anchor file with the automatic updated anchor statement, like this:
server: # ... other stuff # root key file, automatically updated auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"
After you change the config, restart unbound. Unbound will then overwrite the key file with status information (such as the last time the key was seen).
If you then dig com. SOA +dnssec you should see the AD flag there. If things go wrong, try the unbound option val-log-level: 2 that will log explanations why the DNSSEC validation fails (one line per failed query).
And: internet.nl (tests for IPv6 support too) or rootcanary.org (tests for all DNSSEC algorithms).
