Each Yeti Distribution Master (DM) needs to publish the same root zone file as the other DM. In order to do this, the DM need to synchronize the information used to produce and publish the root zone. This includes:
- the list of Yeti root servers, including:
- public IPv6 address
- host name
- IPv6 addresses originating zone transfer
- IPv6 addresses to send DNS notify to
- a flag indicating whether it is active or not
- the ZSK used to sign the root
- the KSK used to sign the root
- the serial when this information is active
Theory of Operation
Each DM operator runs a Git repository, containing files with the information needed to produce the Yeti root zone.
When a change is desired, a DM operator updates the local Git repository. A serial number in the future is chosen for when the changes become active.
The DM operator then pushes the changes to the Git repositories of the other two DM operators. When the serial of the root zone passes the number chosen, then the new version of the information is used.
Details of Git Setup
Each DM operator runs a Git repository, with SSH access.
username: yeticonf repository: dm
The SSH keys for the account include one from all three DM operators.
Any firewall must allow access from the IPv6 prefixes designated by the coordinators.
Only the master branch is used.
Details of Files
The Git repository has the following directory structure:
Note that while the various
zsk directories use a date
format, this is to make it easy to generate unique names and also to
give humans some indication of when changes were made. The directory
names MUST NOT be interpreted in any other way.
yeti-root-servers.yaml file contains one entry per Yeti root
server, which has the server name, public IPv6 address, IPv6 networks
to allow transfer from, and IPv6 addresses to send NOTIFY packets to.
# BII - name: bii.dns-lab.net public_ip: 240c:f:1:22::6 transfer_net: [ "240c:f:1:23::/48", "240c:f:1:24::6" ] notify_addr: [ "240c:f:1:23::6", "240c:f:1:24::6" ] # TISF - name: yeti-ns.tisf.net public_ip: 2001:559:8000::6 active: no
Each Yeti root starts with a '-' and then contains information about it. The following rules apply to each type of variable:
nameis required, and is a host name
public_ipis required, and is an IPv6 address
transfer_netis optional, and is a list of IPv6 prefixes or addresses. If it is not present, then the
public_ipof the server is used instead.
notify_addris optional, and is a list of IPv6 addresses. If it is not present, then the
public_ipof the server is used instead.
activeis optional, and is either "yes" or "no". If it is not present, then the server is active. If it is set to "no", then the DM should set up the transfer and notify addresses, but will not publish the server in the Yeti root zone. (This allows for a new server to be provisioned and tested before being published, and also allows a server to easily be temporarily removed from production.)
iana-start-serial.txt file contains the serial in the SOA of the
IANA root zone when to start using the data:
The KSK directory contains a number of subdirectories, created with a
unique name based on the ISO 8601 date format, with a number at the
end to allow for more than one per day if necessary (up to 100). Each
directory contains any number of
.key files which is in the format
that BIND 9
dnssec-keygen creates. It also contains a
file for each
.key file, with the secret information.
The KSK directories each contain a file called
iana-start-serial.txt, which contains the serial in the SOA of the
IANA root zone when to start using the contents of the directory.
The ZSK directory contains three subdirectories, named for each of the DM operators: bii, tisf, and wide.
Each DM operator subdirectory contains a number of subdirectories, created with a unique name based on the ISO 8601 date format, with a number at the end to allow for more than one per day if necessary (up to 100).
Each directory contains any number of
.key files which is in the
format that BIND 9
The ZSK directories each contain a file called
iana-start-serial.txt, which contains the serial in the SOA of
the IANA root zone when to start using the contents of the directory.
There are a number of operations that the distributors need to perform.
The various operations that change data are:
- Add/delete/renumber/rename Yeti root server
- Change to a new set of KSK
- Change to a new set of ZSK
The logic add/delete/renumber/rename of Yeti root servers is:
- Check to make sure that no operation is pending (if the
iana-start-serial.txtis in the future, an operation is pending).
- Update the appropriate file in the directory.
- Update the
iana-start-serial.txtfile with a serial 2 days in the future.
- "git add"/"git commit"/"git push" of the file(s) and the
All of the basic CRUD (Create, Read, Update, Delete) operations on the
list of Yeti root servers is made by changing the
To change the KSK and ZSK, the logic is:
- Make a directory named "YYYYMMDD##", where YYYYMMDD is the current date and ## is a number, starting with 00.
- Put all of the desired KSK or ZSK files into the new directory.
iana-start-serial.txtas appropriate, with a serial 2 days in the future.
- "git add"/"git commit"/"git push" of the directory.
Generate a Yeti root zone
To generate a root zone the server does this:
- Download the root zone (F.ROOT-SERVERS.NET is good for this).
- Check the root zone is correct using DNSSEC validation.
- If the root serial number is >=
iana-start-serial.txtthen copy the
yeti-root-servers.yamland use that, else use the previous
- Modify the root zone:
- Remove DNSSEC (NSEC, RRSIG, DNSKEY) records.
- Remove records for . (SOA, NS).
- Add Yeti SOA.
- Add Yeti NS RRSET (based on
- Find the latest KSK directory where the serial number is <= the root serial number. Find all the ZSK directories where the serial number is <= the root serial number.
- Add the KSK and ZSK found there into DNSKEY when "Publish<time<Delete"
- Use the keys found there signing the root zone when "Active<time<Inactive" Note that the signing process should use the active ZSK private key that the DM doing the signing is using, as well as the KSK private key from the repository.
- Reload the root zone. (This will send notifies.)
If there is an error getting the IANA root zone, then the DM should not generate a Yeti root. (Probably an alarm of some kind shoul de raised in this case.)
A DM should always generate a zone during its time slot if the Yeti serial is less than the IANA serial for the root zone.
Future Work: Consistency Protocol
Communication failures between the Yeti DM can result in inconsistent Yeti root zone. Solving this requires something like a 2-phase commit or some other consistency protocol. This coordination protocol has not been developed, and will be implemented as a future experiment. For now, we rely on each Yeti DM operator monitoring their systems carefully, along with human oversight of the entire process.
Future Work: Pre-share Multiple Keys
Using the directory structure, it is possible to pre-share any number of keys (or indeed all keys for the lifetime of the project).
Future Work: Figure out the KSK signing process
Right now we assume that each DM operator has access to the KSK secret material. Ultimately this should change, so that there is a true separation of authority between the KSK and ZSK holders.