#bitfehler.net DNS infrastructure

This repository contains the full code (minus the secrets) used to deploy x.bitfehler.net and y.bitfehler.net, the authoritative name servers for bitfehler.net, anemos.io, and a few other zones.

All aspects of the systems are described in code in the form of a makeimg IMGBUILD. Anemos is used for deployment. Besides the obvious utility of this repository its main purpose is to serve as a demo for these projects.

#How it is being used

A server is redeployed by running e.g. make BF_HOST=y deploy. This assumes it is already running the system as described in this repo.

If one of the servers has to be remotely re-imaged (e.g. because something broke beyond repair) or a new server is brought in, using the init target instead of deploy can achieve the same thing off of a stock Leaseweb Debian image (they do not offer Alpine).

You can see this in action here.

#How it works

In rough terms, this is what happens:

• makeimg is used to reveal all used secrets - these secrets are only accessible on my laptop and need to be shipped somehow.
• A tarball is prepared containing the entire IMGBUILD (i.e. the IMGBUILD file plus additional input files), an Anemos env file, and the secrets
• The tarball and an appropriate Anemos config are sent to the server
• Anemos is "installed" on the server (downloaded, as there are no packages yet)
• Anemos is executed on the server

The execution of Anemos will lead to the following events:

• Anemos prepares a special initramfs, based on the Anemos base image but including the prepared tarball (the payload in Anemos terms)
• Anemos reboots the server into the prepared initramfs
• The initramfs executes makeimg, bootstrapping a system exactly as described in the IMGBUILD
• The server is rebooted one more time, booting into the newly deployed system

#What is notable about this?

#Entire system defined in code

The system description includes low-level details like disk partitioning, file systems, and boot loader setup. These things can be changed because the deploy is performed by an initramfs.

#Secrets

In this case, the secrets are resolved on the workstation triggering the deploy and then transferred to the server with the IMGBUILD. In larger environments that feature network-based secrets management systems, this step could be performed on the host itself.

#Network usage

A deployment requires relatively little bandwidth for the client triggering it. Only the IMGBUILD definition has to transferred to the server. All the packages are then pulled from the server, which presumably has a decent connection.

#Shit can blow up

It might be obvious, but still worth pointing out: this method of deployment provides ample opportunity to render a system unbootable. You should not attempt this on systems unless you have some means to restore an unbootable system, e.g. physical access, recovery systems, or vendor-supplied remote re-imaging.