This document has described how to configure and maintain a secure nameserver which supplies signed zones and delegations. All the signed zones and delegations within the scope of the server form an island of security from which nameserver data can be retrieved in a authenticated and verifiable way by a security aware resolver.
But there are times operationally when a recursing secure name server may need to refer to, and retrieve, data from servers outside this island of security. If the referral is to a non-secure name server there is no secure recourse and the chain of authentication is broken and this data can not then be trusted.
To extend the scope of security, a secure nameserver may be
configured with public key data from other remote secure zones so that the
chain of trust is expanded. The trusted-keys directive in
the named.conf configuration file provides this
capability.
The mechanism described below for extending the chain of trust should be used judiciously and comes with the added operational burden of verifying and maintaining key validity and timeliness.
The following is an example of a trusted-keys
directive in a named.conf which provides verification
of data retrieved from the se. and
dnssec-tools.org. zones.
Note: Key data may be different from that shown and should be obtained as described below.
trusted-keys {
se. 257 3 5
"AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM65KbhTjrW1ZaARmPhEZZe3Y
9ifgEuq7vZ/zGZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb4JKUbbOTcM
8pwXlj0EiX3oDFVmjHO444gLkBOUKUf/mC7HvfwYH/Be22GnClrinKJp
1Og4ywzO9WglMk7jbfW33gUKvirTHr25GL7STQUzBb5Usxt8lgnyTUHs
1t3JwCY5hKZ6CqFxmAVZP20igTixin/1LcrgX/KMEGd/buvF4qJCydui
eHukuY3H4XMAcR+xia2nIUPvm/oyWR8BW/hWdzOvnSCThlHf3xiYleDb
t/o1OTQ09A0=";
dnssec-tools.org. 257 3 5
"AQOoEFn3VnV1qDwnNX9GlukAsbL7buCk6Wmt3VG9BOVae84VVc/yWghg
tFM/WKw/5243XoBEeNyaahRIrlAJEnErLUWlKO/YuWkasRN4jkS2dDjS
MWgjdGxzux+e0UV2UZfpjyygYvaD9U8xTwwzLYLDkamr1SCaHWCWUOO+
QMa/WY//r3ObbOFOYCvyqvsLRwofSFnQnsbihKbcP9HQSDQ4iRqbCTMV
B+yq5NXiFoZT05Sqm/ijOrjLznZkUqIal9EXqyhNT0dTa9Gdn8+tfn+l
YApwK91NA2YG/3t8ZKTYjDLe1YlwKg8OBTTN4ARap+265EtE87BhE6ZK
fp+DUx4N";
};
The format of the directive is:
trusted-keys { <zone>
<flags>
<protocol>
<algorithm>
<quoted-key-string>; };
The flags, protocol,
algorithm and
quoted-key-string data may be obtained using the
following dig command, but the content of the string
should be verified in a secure out-of-band way to ensure its
validity.
# dig se. DNSKEY
;; Truncated, retrying in TCP mode. ;
<<>> DiG 9.3.1 <<>> se. DNSKEY ;; global options:
printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status:
NOERROR, id: 31166 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 8,
ADDITIONAL: 0 ;; QUESTION SECTION: ;se. IN DNSKEY ;; ANSWER SECTION: se.
3600 IN DNSKEY 257 3 5
AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM65KbhTjrW1ZaARmPhEZZe3Y
9ifgEuq7vZ/zGZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb4JKUbbOTcM
8pwXlj0EiX3oDFVmjHO444gLkBOUKUf/mC7HvfwYH/Be22GnClrinKJp
1Og4ywzO9WglMk7jbfW33gUKvirTHr25GL7STQUzBb5Usxt8lgnyTUHs
1t3JwCY5hKZ6CqFxmAVZP20igTixin/1LcrgX/KMEGd/buvF4qJCydui
eHukuY3H4XMAcR+xia2nIUPvm/oyWR8BW/hWdzOvnSCThlHf3xiYleDb t/o1OTQ09A0=
...
Note: from the output select the DNSKEY whose flags have the zone signing key bit set (257).
Once the 'named.conf' is edited as above, the configuration can be reloaded with:
# rndc reload
It may also be necessary to flush the cache data before retrieving authenticated results:
# rndc flush
To verify that the trusted-keys directive is
working properly perform a secure dig at the configured
server for the remote signed zone data and observe that the
ad flag is set in the response. For example:
# dig @localhost se. ANY +dnssec
;; Truncated, retrying in TCP mode. ;; Connection to
::1#53(::1) for se. failed: connection refused. ; <<>> DiG
9.3.1 <<>> @localhost ANY se. +dnssec ; (2 servers found) ;;
global options: printcmd ;; Got answer: ;; ->>HEADER<<-
opcode: QUERY, status: NOERROR, id: 56473 ;; flags: qr rd ra ad; QUERY: 1,
ANSWER: 23, AUTHORITY: 9, ADDITIONAL: 1 ...