This document describes the process used to generate and distribute the Yeti root.
In Yeti, this modified root zone is generated by the Yeti Distribution Masters (DM), which provide it to the Yeti root servers.
While in principle this could be done by a single DM, Yeti uses a set of three DM. These DM coordinate their work so that the resulting Yeti root zone is always consistent. (We need to avoid the case where not all DM share the same set of Yeti root servers, and so they produce different versions of the Yeti root zone with the same serial.)
The generation process is:
- Download the latest IANA root zone
- Make modifications to change from the IANA to Yeti root servers
- Sign the new Yeti root zone
- Publish the new Yeti root zone
IANA Root Zone
The root zone is currently downloaded using AXFR from F.ROOT-SERVERS.NET:
$ dig -t axfr . @f.root-servers.net.
This appears to be the best way to get the updated version of the root zone as soon as possible.
TODO: The DM should check that the zone they are retrieving from IANA is properly signed, with something like ldns-verify-zone.
A new version of the Yeti zone is only generated when the IANA zone changes, which is detected by the change in the serial number value in the SOA record.
All DM share the same KSK secret material. This generated using the BIND 9 dnssec-keygen tool, and then sent via encrypted PGP to the other DM operators.
The root zone is modified as follows:
- The SOA is updated:
- The MNAME and RNAME are set to Yeti values
- The IANA DNSSEC information is removed:
- The DNSKEY records
- The RRSIG and NSEC records
- The IANA root server records are removed:
- The NS records for [A-M].ROOT-SERVERS.NET
- The Yeti DNSSEC information is added:
- The DNSKEY records
- The Yeti root server records are added:
- The NS records
- The AAAA glue records
- The Yeti root zone is signed
It might be worthwhile to use the serial value in the SOA field, however for now we duplicate the IANA serial value.
The list of Yeti name Servers is synchronized between the DM as described below.
Each Yeti DM checks to see if the IANA root zone has changed hourly, on the following schedule:
|BII||hour + 00|
|WIDE||hour + 20|
|TISF||hour + 40|
A new version of the Yeti root zone is generated if the IANA root zone has changed.
Synchronizing List of Yeti Name Servers
It is important that the root zone produced by the Yeti DM is always consistent. In order to do this, we use something like a 2-phase commit procedure.
A change to the list of Yeti name servers gets put into a PENDING directory on any one of the Yeti DM. This directory contains:
- the new list of Yeti name servers
- the time when the new list will be valid from
- a file for each Yeti DM which has confirmed the new list
Each DM will periodically check this PENDING directory. If the directory is present, then the DM will download the new information, add a file documenting that it has received it.
Sometime after the scheduled time arrives and before the next Yeti root zone is generated, each DM will check if the other DM have both received the new list of Yeti name servers. If they have, then the list of Yeti name servers will be replaced with the new one. If they have NOT, then an alarm is raised, and humans debug the failure.
In pseudocode, something like this:
sync_yeti_roots: loop forever: try rsync with PENDING directory with each other DM if PENDING list of roots != my list of roots: add a DM file for me in the PENDING directory if current time > PENDING scheduled time: if the DM file for each DM is present: copy PENDING list of roots to my list of roots else: PANIC (notify a human being) sleep a bit
We choose 48 hours as the current time to adopt a new list of Yeti name servers. This allows plenty of time for for DM administrators to fix issues.
Only a single PENDING change is possible at one time. This is an entire new list of Yeti root servers. Further changes must be held until the current set is applied.
Note that it might be possible to start using the new list of Yeti name servers as soon as all DM have received it. However for predictability and simplicity we will always use the scheduled time for now.