Background

During this time, I've mainly used BIND, but have tried to focus more on the protocol mechanics and standards vs. a specific software solution.

I've also been running my own DNS servers (authoritative) for ~ 25 years as well. My primary domain (obviously where you are reading this now) is burn.net. I've had people tell me I should just punt this over to Cloudflare or one of the other services. But I like running my own DNS - pain and all. I like the control I have, as well as it giving me the chance to keep up on the latest standards and practices in the DNS world.

I started dipping my toe in the DNSSEC world around 2014 or so. Initially, just turning on DNSSEC validation in the resolvers I run. This let me see zones that were properly signed, how they behave, and how they break.

A few years ago I decided to put in the work at the other end of the equation - signing my own domains. At the time, this wasn't super user friendly. Lot's of manually generating keys, signing zones, etc. This has changed fairly recently in the BIND world with the introduction of "dnssec-policy".

Current State (dnssec-policy)

In short though, dnssec-policy lets you define a policy (or multiple policies) for your DNSSEC signed zones. It handles automatic key creation, CDS/CDNSKEY publishing, key rollovers and more.

The default policy is simply called "default". This is what I'm using. It has reasonable defaults for crypto algorithms, timers etc. It also uses a "CSK" (combined signing key) as opposed to the traditional separate KSK (key signing key) and ZSK (zone signing key).

Something to keep in mind about dnssec-policy: if you migrate from any pre-dnssec-policy setup (ex: auto-dnssec) - you need to be careful about this process. The zero-impact method involves creating a dnssec-policy that matches your current setup. Not only do the algorithms have to match, I believe all the timers do as well. If you do this properly, BIND should use your existing keys.

The other option I term "nuclear" is setting dnssec-policy and letting BIND create new keys (well one key (CSK) with the default policy). This is what I did :) In this scenario - you will have a DNSSEC outage for the time it takes you to get the new DS record into your registry and TTL expiration etc.

Key Rollover

Here's what's needed to make this happen:

• dnssec-policy (obviously)
• A registry/registrar that supports CDS/CDNSKEY
  • Your registry (or registrar or DNS provider) needs to support CDS/CDNSKEY. There are also methods of communicating the DS record upstream called CSYNC and _dsboot. I have not investigated either in depth so I won't cover them here.
  • All of these mechanisms allow the upstream to query and retrieve your DS record automatically. Otherwise, you need to manually log into their web portal, use their API, etc.
  • A great list of folks that support this is here: https://github.com/oskar456/cds-updates Please contribute there if you know of another provider that supports this.
  • I personally have moved my domains over to Domainnameshop. Their stuff works.
• Parental agent checking configured in BIND
  • BIND supports "parental agents". This is simply the list of nameservers that have delegated down to you. So for example if you have a .tech domain, the parental agents are [a|b|e|f].nic.tech.
  • By configuring these and setting them in your zone stanza - BIND will automatically check to see if the DS has been published for the current key.
  • I wrote a script and have some more details on how to set this up here.
• The actual rollover command
  • rndc dnssec -rollover -key $KEYID $ZONE

So the order of operations is:

1. You run the rollover command. BIND will create a new key, and modify the settings of the now predecessor key. After certain timing, BIND will publish CDS and CDNSKEY records.
2. Your reigstry/registrar/DNS provider will query and see the (new) CDS or CDNSKEY. After their validation period and timers, they will publish this in the registry.
3. At this point, you have a chain of trust that goes: upstream -> new key -> old key -> zone resource records.
4. BIND will check the parental agents to see if/when the DS is published. It will log a message to this effect and you can also see it in the .state file (more on that below).
5. BIND will handle gradually signing records directly with the new key over time, as well as retiring and eventually removing the old key.
6. When the old key is removed from the zone, the process is complete

To check the status of this process, I do the following:

• rndc dnssec -status $ZONE
• cat /path/to/key/files/$KEYFILE.state

Tools for checking your DNSSEC

• DNSViz
  • Hands down the best/most powerful tool.
• Verisign DNSSEC Analyzer
  • Another great tool. A bit more concise than DNSViz.
• Zonemaster
  • This tool checks your whole zone "health" in addition to checking DNSSEC.
• Command line: delv
  • Think of delv as the DNSSEC counterpart to dig.
  • I recommend running delv on a machine that is NOT your auth server. It will fetch all DNSSEC records and attempt to validate.
  • delv $ZONE # Simple validation of a zone (A record by default).
  • delv +mtrace $ZONE # Similar to dig +trace - walks the tree and shows each validation step/level.
  • Many more flags and arguments to delv, again similar to dig.

Updated: 20230105