Skip to content

DNS

How-to

Edit a zone

Editing a zone is straightforward:

  1. Clone the zone file repo (git-ssh.majava.org:public/config/dns), if you have not done so already.
  2. Edit the relevant file in zones/
  3. Commit and push the change. It will automatically be deployed.

Add a zone

Adding a zone is somewhat more complicated.

The basic workflow is rather simple, actually:

  1. In the DNS repo, add a zone file to zones/. Copy an existing one if necessary.
  2. Add the zone file to zones.yaml in the same repo.
  3. Commit and push the change.

Now your zone is live on the internal primary and on the internal secondaries. However, nothing is configured to route that zone to the internal servers. You need to either configure the internal recdns service to use the internal DNS servers, or add that zone to the public server and configure delegations, or both.

To add the zone to the internal recursors, add the zone to the profile::dns::recursor::stub_zones Hiera key in hieradata/roles/dns/recdns.yaml in the Puppet public repository, then run Puppet on recdns*.

To add the zone to the public servers, add the zone to the profile::dns::auth::public::zones Hiera key in the hieradata/roles/dns/auth/public.yaml file, run Puppet on the public DNS server, and then configure any external secondaries and the delegation and DNSSEC keys in the parent zone/registrar.

Manage DNSSEC keys

TODO

Wipe recursor cache

The easiest way is to run this via Cumin: 

$ sudo cumin "recdns*" "systemctl restart unbound"

Reference

Authoritative server architecture

In our architecture there are three types of servers:

  • The primary, aka ns-auth0.discovery. This is a single server that holds the actual zone files and also DNSSEC signing keys. The other servers use zone transfers and notifies to get a local copy of the zone.
  • The secondaries. These act as secondary authoritative servers for internal clients. They respond to the ns-auth1.discovery service address.
  • The public server, currently deanei.majava.org. (aka ns-auth-public.discovery). This single server acts as an authoritative server for public clients, and is also used to transfer zones to other secondary DNS providers.

These all run Bind on stock Debian.

TODO: document split views

Record auto-generation

TODO

Registrars

.fi domains are registered in the Traficom registry directly. Everything else is currently registered via Porkbun.

Discussion

DNSSEC

TODO: this needs updating after it turned out that Bind's automatic signing system bumps SERIALs in a way that messes up with the dnsgen serial generation algorithm.

We (will) use DNSSEC. The justification is basically that Bind can do most of that for us, a non-expiring KSK is fine for our use case, and the value we get from signing e.g. CAA records makes it worth it in the end.

Public secondary servers

We rely on a few public secondary DNS servers since there's only one deanei.

Security-wise this should be OK, as we DNSSEC sign our domains. In theory this means that the only major these host could do is to DoS us, hijacking traffic and moving it somewhere else not being possible. This seems like an acceptable risk as we generally trust the secondary providers anyway.

The services currently in use are:

ns-global

This is Kenneth Finnegan's hobby project. So far it's been very stable and we have not had any major issues. No TSIG support, however. Zone verification is via an email to the address listed in the currently live SOA record.

ns-global is in use for all non-.fi domains.

Hurricane Electric

HE is a major IP transit and datacenter provider. Their free DNS service also has been very stable. There's no indication they are planning to discontinue the service or do any evil things with it.

Zone verification is done by checking if the parent zone records point to HE nameservers, which means that to add a zone there you first need to point traffic there which is not ideal. You also can't update the primary without deleting and re-creating the zone.

HE DNS is in use for all non-.fi domains.

Traficom Anycast (z.fi)

Traficom offers an anycast secondary anycasted DNS service for registrars. Since we are one, we use it for our .fi domains. It works fine.

Question

It might be interesting to survey what secondary DNS services our friends are using, in case there are new services that we should consider adding to the rotation. One interesting thing to explore is DNS secondary swaps - we could act as a secondary for someone and that someone could act as a secondary for us.