How to update DNS resource records
updating standard resource records
For most zones, the hidden primary DNS server is denis, with RcodeZero, Netnod and easyDNS providing public-facing secondary servers.
Zone files are managed via a git repository. Pushing commits into the git repository will invoke a post-commit hook that causes the recompilation and reload of the zone files.
Some subdomains (specifically www.debian.org; previously security.debian.org) are served by the autodns/geodns setup on geo{1,2,3}. Their zone files are managed by a separate git repository.
Note that denis runs both bind - for generating and serving our zones - and unbound - as the local resolver. unbound listens on localhost, with bind answering queries @denis.debian.org (locally, or from the secondaries).
updating DNSSEC records
When nagios complains about impending DS expiry, find the new key in /srv/dns.debian.org/var/keys/$zone/dsset and add it at the registrar (gandi) for forward zones, or ask the parent zone operator to add it (for reverse zones); the UBC IPv4 reverse zone (16.87.209.in-addr.arpa) is delegated to DSA at ARIN, and so we can manage the keys directly. Leave the old one in place for a day or so, after checking that dnsviz.net is happy with the new key. For the debian.org and 29.172.in-addr.arpa zones, also update the trust anchors in puppet.
fixing expired signatures
If DNSVIZ indicates that some signatures have expired, stop bind on denis, remove all of the generated files from /srv/dns.debian.org/var/generated/$zone (leaving just the zone file itself and the serial) and force a zone update so that the serial is bumped. This will force bind to re-sign the zone. Finally, restart bind and re-check the signatures.
untrusted anchors on newly boostrapped systems
If a host was puppetized less than 30 days before the debian.org trust anchor was replaced, it will not yet have had time to have bootstrapped trust in the new anchor. Checking /var/lib/unbound/debian.org.key on the host will reveal that the new anchor is still in the "ADDPEND" state.
To resolve this, stop unbound, replace the key with the file from Puppet, and start the service again.
Managing a new domain
Add the domain in the proper git repo
In domains.git, create a file per domain you want to manage. You can copy another one as a proper basis if useful. Commit the files and push the whole upstream.
Add the domains in our secondary DNS providers
We rely on rcode0, easydns and netnod.se/dnsnode as DNS providers for DSA-managed domains. Easydns seems to have some limit on the number of domains we can delegate them to handle, so for non-sensitive domains, don't bother adding them there, and stick to rcode0 and netnode/dnsnode.
Update the nameservers record on the registrar's part
Add the secondary providers' DNS server there, eg
- sec1.rcode0.net
- sec2.rcode0.net
- nsp.dnsnode.net
- dns4.easydns.info
Update auto-dns.git if using one of its services
Eg static.debian.org.service
Add the SSL certs needed
I used letsencrypt-domains.git which is the "deprecated method". Read the README there to know what to do, we'll update the docs with the new one when possible.
Domains are added in the domains file, and pushed to the repo, which will result in the certificate being generated.