Maintenance Tasks

Zone data is signed and the parent zone has published your DS records — at this point your zone is officially secure. When other validating resolvers lookup information in your zone, they are able to follow the 12-step process as described in the section called “How Does DNSSEC Change DNS Lookup (Revisited)?” and verify the authenticity and integrity of the answers.

There is not that much left for you to do, as the DNS administrator, at an ongoing basis. Whenever you update your zone, BIND will automatically resign your zone with new RRSIG and NSEC or NSEC3 records, and even increment the serial number for you.

That leaves DNSKEY records. Just like passwords and underwear, keys should be changed periodically. There are arguments for and against rolling keys, which are discussed elsewhere. If you decide to change your keys, we recommend changing your ZSK pair anually, and your KSK pair every five years. This is also known as a key rollover.

Why annually for the ZSK? That's just a convenient length of time that probably coincides with your domain name registration/renewal cycle; And every five years? That's also a generic length of time, one which happens to be the same as the root key's rollover schedule. Some people feel or have the need to do it more frequently, while some argue that there is no need for key rolling. We discuss those considerations in the section called “Key Rollovers”. But assuming you do not have special security requirements, nor host a high-valued zone, rotating your ZSK every year and KSK every five years should suffice. We also provide detailed step-by-step examples of each rollover in the section called “Rollover Recipes”.

ZSK Rollover

Assuming you are rolling your ZSK every year on January 1st, below is the timeline of what should happen:

  1. December 1st, a month before rollover date:

    • Change timer on current ZSK
    • Generate new ZSK
    • Publish new DNSKEY
  2. January 1st, day of rollover:

    • New ZSK used to replace RRSIGs for the bulk of the zone
  3. February 1st, a month after rollover date:

    • Remove old DNSKEY from zone
    • DNSKEY signatures made with KSK are changed

This may look like a lot of work, but with inline-signing and auto-dnssec, most of these are automated. The only things that need to be done manually are just the first two items:

  • Change timer on current ZSK
  • Generate new ZSK

For an example of how to execute a ZSK rollover, please see the section called “ZSK Rollover Recipe”.

KSK Rollover

KSK rollover is very similar to ZSK, with the addition of interacting with the parent zone. In fact, as you can see below, the timeline looks nearly identical to the ZSK rollover, with the addition of interaction with parent zone:

  1. December 1st, a month before rollover date:

    • Change timer on current KSK
    • Generate new KSK and DS records
    • Upload new DS records to parent zone
  2. January 1st, day of rollover:

    • Use new KSK to sign all DNSKEY RRset, this generates new RRSIGs
    • Add new RRSIGs to the zone
    • Remove old RRSIGs from zone
  3. February 1st, a month after rollover date:

    • Remove old KSK DNSKEY from zone
    • Remove old DS records from parent zone

Unfortunately, as of this writing, KSK rollover involves a lot of manual steps. As described above, the only automated tasks are the ones that occur on the day of the rollover (January 1st), everything else needs to be done manually. To see an example of how to perform a KSK rollover, please see the section called “KSK Rollover Recipe”.