Introduction

DNS Root Server system is an early form of cloud model to replicate the root zone file and enhance high availability. To expand the capacity of the root server system, the root anycast instances were deployed widely given that the list of root servers are the proof of the integrity of root zone content. People trust the data by trusting the servers where the data is pulled from.

Entering DNSSEC, data can be authenticated with crypto-signature. People gain confidence on data integrity by self-validating data. The place where the root zone file is replicated and stored becomes irrelevant. RFC7706 is one example providing a mechanism to give the same answer back from the “local” root server as from the “real” root server on the same level of authentication. Although they may bring some operation concerns and risks, it does gain in terms of performance (reducing the latency). So it becomes popular among some public DNS operators.

By contrast, Yeti provides a different zone file distribution model which introduces a new set of authoritative servers and their instances for the root zone. It is an efficient and large-scale approach to replicate and distribute the root zone file in a straightforward manner compared to RFC7706. Imagine that you have more than 1000 resolvers in your network, you may prefer one root instance located in your network to the management of 1000 “local” root servers.

However, compared to RFC7706, Yeti model cannot provide an unmolested DNSKEY RRset or an unmolested apex RRset or RRSIG. It is questioned as being an alternative root, with the ability to change the TLD meta data and sign with alternative keys. It is regarded as violating the political correctness of keeping a unique identifier system. It is not a technical issue, but an “ethic” risk which Yeti model advocates are undertaking.

To relieve the risk as much as possible, an proposal is formed to build a new root zone containing both Yeti and IANA Keys and RRSIGs. The new root zone are divided into two parts: one is apex records : SOA, NS , DNSKEY including their RRSIG signed by Yeti keys(ZSK & KSK). The other part is TLD meta data like DS, NSEC, NS, A/AAAA glue as well as their RRSIG signed by IANA ZSK(glue and NS has no RRSIG). Note that DNSKEY RRset includes Yeti ZKS(s), KSK(s) and IANA ZSK(s).

Lab test and result

To validate this proposal, a lab environment test was done. In normal DM operation loop, the IANA DNSKEY RRset and DNSSEC signature is removed after downloading the root zone. In the test, we keep IANA ZSK and non-Apex RRSIG (signature for DS and NSEC) and NSEC in the Yeti root zone.

Authority server setup

The routine for generation of a new Yeti root zone is as follows:

  • Download the latest IANA root zone.(using AXFR from F.ROOT-SERVERS.NET for instance);
  • Strip apex SOA, NS and DNSKEY as well as their RRSIGs; Keep the NSEC ,TLD DNS and Glue, RRSIG of non-apex RR unchanged;
  • Put a new DNSKEY RRset into the zone with Yeti ZSK and KSK as well as IANA ZSK.
  • Put a new SOA RR, copying IANA SOA SERIAL, setting MNAME to www.yeti-dns.org. and setting RNAME to <dm-operator>.yeti-dns.org. where <dm-operator> is currently one of “wide”, “bii” or “tisf”.
  • Put a new NS RRset with existing 25 servers in Yeti testbed.
  • Sign the apex SOA, NS RR with Yeti ZSK and sign the DNSKEY RRset with Yeti KSK in the zone.
  • Publish the root zone to testing server A.

There is a diagram of the constructed new Yeti root zone. At left is the IANA root zone, at right Yeti’s one. Only one delegation is put, only to show the mechanism. The (I) suffix means “IANA” and “Y” Yeti:

SOA(I)                          SOA(Y)
RRSIG(. SOA(I)(ZSK(I))          RRSIG(. SOA(Y)(ZSK(Y))

DNSKEY(I)                       DNSKEY(Y)
    KSK(I)                           KSK(Y)
    ZSK(I)                           ZSK(I)
                                     ZSK(Y)
RRSIG(. DNSKEY(I))(KSK(I))      RRSIG(. DNSKEY(Y))(KSK(Y))

. NS IANA_NS1                   . NS Yeti_NS1
. NS IANA_NS2                   . NS Yeti_NS2
. NS IANA_NS3                   . NS Yeti_NS3
RRSIG(. NS)(ZSK(I))             RRSIG(. NS)(ZSK(Y))

NSEC1(.->net.)                  NSEC1(.->net.)
RRSIG(NSEC1)(ZSK(I))            RRSIG(NSEC1)(ZSK(I))

net. NS NS7                     net. NS NS7
net. NS NS8                     net. NS NS8
net. DS                         net. DS
RRSIG(net. DS)(ZSK(I))          RRSIG(net. DS)(ZSK(I))

NSEC2(net.->.)                  NSEC2(net.->.)
RRSIG(NSEC2)(ZSK(I))            RRSIG(NSEC2)(ZSK(I))

Resolver setup

There was a DNSSEC validating resolver B set up (BIND). Resolver B used Yeti KSK as its trust anchor. The glues record of Yeti_NS1, Yeti_NS2, Yeti_NS3 are configured with the address of server A. So that all queries will be sent to server A. The rollover of KSK and ZSK of the new Yeti root zone is expected to be fine because Yeti Multiple-ZSK experiment had been tested and workable with many keys in DNSKEY RRset. The only impact is the size of DNSKEY response.

Result analyses

By analyzing the log, it was found that server B validate the response using the RRSIG signed by IANA zsk (keyid=14796).

Resolver B’s DNSSEC log:


31-May-2017 15:46:49.278 dnssec: debug 3: validating net/DS: starting 
31-May-2017 15:46:49.278 dnssec: debug 3: validating net/DS: attempting positive response validation 
31-May-2017 15:46:49.278 dnssec: debug 3: validating net/DS: keyset with trust secure 
31-May-2017 15:46:49.278 dnssec: debug 3: validating net/DS: verify rdataset (keyid=14796): success 
31-May-2017 15:46:49.278 dnssec: debug 3: validating net/DS: marking as secure, noqname proof not needed

The current dnskey rrset of IANA root zone is:

dig @f.root-servers.net . dnskey +multi

.                       172800 IN DNSKEY 257 3 8 (
                                AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
                                bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh
                                /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA
                                JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp
                                oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3
                                LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO
                                Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc
                                LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
                                ) ; KSK; alg = RSASHA256; key id = 19036
                                
.                       172800 IN DNSKEY 256 3 8 (
                                AwEAAZLsvvPf/WDYE8L8ZUOiXEN9PSg3Nqyqu8WWKVu4
                                LIvPW77Y0W1mBgmroFEHxzA9zM2edQbYIFhj536sx3fj
                                1bx4n8yKwQ0y1MYkXvgU3aKWf0jnm8qz5RPVa4iEUgP5
                                og/70muAXmo38Ru10asc3SNtN2OlAT1Tivp+U4JUlVA8
                                ICvierUPg2Kgf2gtNFhuqMTx/IHrE5DdV+Z/rmHGqESe
                                /mnaDzHdFnKy7Ma5zcPTekmwZ86CnG+vNWMT6wiO56YS
                                AaiHX0jSCjmkL7JzT3xpp/vtoWLK1rir70i6NbsU48sP
                                ZOHLfhwzbownewAsng0QqMOcVcmhl6ifE3C/vjE=
                                ) ; ZSK; alg = RSASHA256; key id = 14796

Conclusion and future work

There is an effort to make and demonstrate a diff file between IANA root zone and Yeti root zone in the monitoring website. By reusing IANA DNSSEC stuff, this proposal generates a Yeti root zone including IANA ZSK and signatures, consequently reducing the size of the diff file (smaller diff means less change). If IANA ZSK and RRSIG in Yeti root zone can be viewed in a way as a proof integrity, then it “provides”:

1) Guarantee no edit or changes to existing TLD meta data(DS RR);

2) Guarantee no existing TLD is removed or new TLD is added into the root zone;

3) Yeti keys only sign apex will avoid multiple RRSIGs and keep the response size small.