Current Keys

This page lists the current keys / DS records.

If you want to test your implementation against this server, you will need to tell it that this server is the DNS Root and what the current (fake) root key is. This information is below.

I have also included an example config file (named.conf) for testing with ISC BIND, I will add additional example config files in the future. If you would like an example for your implementation added, please email me an example.

Raw Information

Root server IP 204.42.252.20
Current Key ID 25681
Current Key DS . IN DS 25681 8 2 86AA051BC19C506F70CC25D2B72C963651BB6C394541DD32358ED36A7213C568
Current Key 257 3 8 AwEAAcadZcgPMk9ay8DYkJPgWXna0LjmknsapsGuQgYMF1gKyJvWPWQs mv8kY/Q8Xl7thF4rGNjel9k1SKX/7V5mg+OLs3NVeZIbDDgQy9IOpGq/ e8HAWgNWX783riFFn5JKM8RWNYilgBsK+Gtxes6h4hqRWf+vYAaf/y8/ yiXdDIQuCP8DNYAZO0FQqlkXo4+fQZku/6GmioJXxSEHtLTBTxBC/blK jIinrX8ehA+qhB5JPMuVkxS/PCNxKW+xjAjMR0GH9fL7o0M6NwPJS0s9 5Dm7empm9GLzaGN78c1mQxoZQotZl4a6Q3PaYrkhiqaCBPeTYtfeI7Va PTTS+q1urU8=
Key file K.+008+25681.key

Example BIND Config

Note: When using this config file you will probably need to delete /var/named/21ce078705d04ca6324c1d0313fc08ea99f3cef6389a6744d40bd2d9d0cd7816.mkeys* every time you restart BIND after missing a keyroll.
Thus sayeth the BIND 9.8.0-P4, Chapter 6, "managed-keys Statement Grammar":

The first time named runs with a managed key configured in named.conf, it fetches the DNSKEY RRset directly from the zone apex, and validates it using the key specified in the managed-keys statement. If the DNSKEY RRset is validly signed, then it is used as the basis for a new managed keys database. From that point on, whenever named runs, it sees the managed-keys statement, checks to make sure RFC 5011 key maintenance has already been initialized for the specified domain, and if so, it simply moves on. The key specified in the managed-keys is not used to validate answers; it has been superseded by the key or keys stored in the managed keys database.

// BIND named.conf file for RFC5011 style keyroll testing.
// 
// NOTE: 
// This is an example named.conf file to test RFC5011 style key rollovers.
// It is NOT useful for general purposes. 
// 

options {
        directory "/var/named";
        dump-file "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named.memstats";

        zone-statistics yes;

        // We need to allow recursion so that we can actually query the root.
	recursion yes;

	// Not much point without doing DNSSEC :-P
	dnssec-enable yes;
        dnssec-validation yes;  # enable DNSSEC validation

	auth-nxdomain no;    # conform to RFC1035
	listen-on { 127.0.0.2; };

};


# // Root key.
managed-keys {
      . initial-key 257 3 8 "AwEAAcadZcgPMk9ay8DYkJPgWXna0LjmknsapsGuQgYMF1gKyJvWPWQs
mv8kY/Q8Xl7thF4rGNjel9k1SKX/7V5mg+OLs3NVeZIbDDgQy9IOpGq/
e8HAWgNWX783riFFn5JKM8RWNYilgBsK+Gtxes6h4hqRWf+vYAaf/y8/
yiXdDIQuCP8DNYAZO0FQqlkXo4+fQZku/6GmioJXxSEHtLTBTxBC/blK
jIinrX8ehA+qhB5JPMuVkxS/PCNxKW+xjAjMR0GH9fL7o0M6NwPJS0s9
5Dm7empm9GLzaGN78c1mQxoZQotZl4a6Q3PaYrkhiqaCBPeTYtfeI7Va
PTTS+q1urU8="; }; view "recursive" IN { match-clients { any; }; allow-query { any; }; recursion yes; allow-recursion { any; }; // prime the server with the RFC5011 Key roll server. zone "." { type hint; file "/tmp/keyroller/db.root"; }; }; // End of recursive view.

Example Unbound Config

Note: Thanks to Jakob Schlyter for this config.
He has created a nifty toolset at https://github.com/jschlyter/keyroll/ to download the key, put it in the right format, etc. It comes with config files for Unbound and BIND, and makes using this simpler and easier!

More info in the README.md file.

When using this config file, you will need to put the trust anchor in /var/tmp/keyroll-unbound/keyroll-systems-root.key and the root hints in /var/tmp/keyroll-unbound/keyroll-systems-root.zone. Jakob's scripts / Makefile does all this for you...

# unbound.conf

server:
	verbosity: 1

	statistics-interval: 10
	extended-statistics: yes

	logfile: ""
	username: ""
	chroot: ""

	root-hints: "/var/tmp/keyroll-unbound/keyroll-systems-root.zone"
	auto-trust-anchor-file: "/var/tmp/keyroll-unbound/keyroll-systems-root.key"
	
	# instruct the auto-trust-anchor-file probing to add anchors after ttl.
	# add-holddown: 2592000 # 30 days

	# instruct the auto-trust-anchor-file probing to del anchors after ttl.
	# del-holddown: 2592000 # 30 days

	# auto-trust-anchor-file probing removes missing anchors after ttl.
	# If the value 0 is given, missing anchors are not removed.
	# keep-missing: 31622400 # 366 days

remote-control:
	control-enable: yes

Fake root.db

We create a fake root zone, both so that we can sign it, and so that we can make our recursive server believe that we know everything that there is to know about the world.

Please note: This is a fake version of the root, only for testing. It only knows about 2 TLDs, .invalid and .example. Using this in the real world will not work!

; A fake root zone for RFC5011 testing.
; 
; This fake root zone file exists purely for testing RFC5011 implmentations. 
; Trying to use this to actually resolve names simply won't work (unless you 
; get your jollies by only looking up 4 TXT records!)

$TTL 900	; We make the TTL be 15 minutes - this way we will get >1 request during the 1h keyroll time.

.			IN SOA	mname.invalid. ns.invalid. (
				42         ; serial
				3600       ; refresh (1 hour)
				3600       ; retry (1 hour)
				1814400    ; expire (3 weeks)
				3600       ; minimum (1 hour)
				)

.             		NS	ns.root.
ns.root.                A	204.42.252.20

invalid.                NS      ns.invalid.
ns.invalid.             A       204.42.252.20

example.                NS      ns.example.
ns.example.             A       204.42.252.20

.            TXT     "This is the example root zone"

This system written and maintained by Warren Kumari (warren@kumari.net). Feel free to contact with any questions / issues.