In the section the section called “How Does DNSSEC Change DNS Lookup (Revisited)?”, we walked through the DNSSEC lookup process (12 steps), and at the end of the 12 steps, a critical comparison happens: the key received from the remote server, and the key we have on file are compared to see if we trust it. The key we have on file is called a trust anchor, sometimes also known as a trust key, trust point, or secure entry point.

The 12-step lookup process describes the DNSSEC lookup in the ideal world where every single domain name is signed and properly delegated, each validating resolver only needs to have one trust anchor, and that is the root's public key. But there is no restriction that the validating resolver must only have one trust anchor. In fact, in the early stages of DNSSEC adoption, it was not unusual for a validating resolver to have more than one trust anchor.

For instance, before the root zone was signed (prior to the year 2010), some validating resolvers that wish to validate domain names in the .gov zone needed to obtain and install the key for .gov. A sample lookup process for www.fbi.gov would thus be only 8 steps rather than 12 steps that look like this:

Figure 3.3. DNSSEC Validation with .gov Trust Anchor

This all looks very similar, except it's shorter than the 12-steps that we saw earlier. Once the validating resolver receives the DNSKEY file in #8, it recognizes that this is the manually configured trusted key (trust anchor), and never goes to the root name servers to ask for the DS record for .gov, or ask the root name servers for its DNSKEY.

In fact, whenever the validating resolver receives a DNSKEY, it checks to see if this is a configured trusted key, to decide whether or not it needs to continue chasing down the validation chain.

So, as the resolver is validating, we must have at least one key (trust anchor) configured. How did it get here, and how do we maintain it?

If you followed the recommendation in the section called “Easy Start Guide for Recursive Servers”, by setting dnssec-validation to auto, then there is nothing you need to do. BIND already includes a default key (in the file bind.keys), that will automatically update itself. It looks something like this:

managed-keys {
    . initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
    FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
    bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
    X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
    W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
    Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
    QxA+Uk1ihz0=";
};

You could, of course, decide to manage this key on your own by hand. First, you'll need to make sure that your dnssec-validation is set to yes rather than auto:

options {
    dnssec-validation yes;
};

Then, download the root key manually from a trustworthy source, such as https://www.isc.org/bind-keys. Finally, take the root key you manually downloaded, and put it into a trusted-keys statement as shown below:

trusted-keys {
    . 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
    FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
    bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
    X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
    W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
    Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
    QxA+Uk1ihz0=";
};

Looking back at the example in the section called “How Trust Anchors are Used”, if you wanted to explicitly trust .gov and only validate domain names under .gov, your trusted-keys statement would look something like this:

trusted-keys {
    gov. 257 3 8 "AQO8daaz7B+yshOfL60rytKd9aOSujgponEw3fwBMEC3
    /+e9XzHw2k+VKnbJTZ+QaVtpfUd1q9HKZIv/ck83Gl5T
    jYKE5jtUZ2kpEDZfVNGv6yx0smtWAXv1nCJS9ohnyOTd
    397eMojGDHqkEC+uojEScZheEkMxzgCZwDAs+/CSU7mS
    uHtCRZn19xlZUd5Gv7yDQ3mbOUwuy30oSk0z1Q5UUPpo
    ihOugIZHFX6Jk7NLiW2wlqfq9qhV4zj7TiBiJY0mCc4z
    HN8/aq2VKDHp2Na7mWzvKyTy+SYQkBQ/08LbPwj9YMc+
    uCzKL6sU/ObHv17EFhD8aPDftTHZvV9L+OZr";
};

As the name trusted-keys suggests, it is possible to have more than one key configured. You could also leverage the section called “DNSSEC Look-aside Validation (DLV)” as part of your trust-anchor management strategy.

While trusted-keys and managed-keys appear similar, there is an important difference: trusted-keys are always trusted, until they are deleted from named.conf; managed-keys (specifically, initial-key, which is the only supported type currently) are only trusted once: for as long as it takes to load the managed key database and start the key maintenance process.