In order to support DNSSEC in Traffic Router, Traffic Portal provides some actions for managing DNSSEC keys for a CDN and associated Delivery Services. DNSSEC keys consist of a KSK which is used to sign other DNSKEY records as well as a ZSK which is used to sign other records. DNSSEC keys are stored in Traffic Vault and should only be accessible to Traffic Ops. Other applications needing access to this data, such as Traffic Router, must use the Traffic Ops API to retrieve this information.
In order for Traffic Ops to successfully store keys in Traffic Vault, at least one Traffic Vault server needs to be configured in Traffic Ops.
Go to CDNs and click on the desired CDN.
Click on the Generate DNSSEC Keys button.
A modal will pop up asking you to confirm that you want to proceed.
Input the required information (reasonable defaults should be generated for you). When done, click on the green Generate button.
Depending upon the number of Delivery Services in the CDN, generating DNSSEC keys may take several seconds.
You will be prompted to confirm the changes by typing the name of the CDN into a text box. After doing so, click on the red Confirm button.
In order for DNSSEC to work properly, the DS Record information needs to be added to the parent zone of the CDN’s domain (e.g. If the CDN’s domain is ‘ciab.cdn.local’ the parent zone is ‘cdn.local’). If you control your parent zone you can enter this information yourself, otherwise you will need to work with your DNS team to get the DS Record added to the parent zone.
Enabling and Disabling DNSSEC on a CDN¶
Once DS Record information has been added to the parent zone, DNSSEC needs to be activated for the CDN so that Traffic Router will sign responses. Go to the CDN details page for this CDN, and set the ‘DNSSEC Enabled’ field to ‘true’ (or ‘false’ to disable DNSSEC), then click the green Update button.
DNSSEC should now be active (or inactive, if disabled) on your CDN and Traffic Router should be signing responses. This should be tested e.g. with this dig(1) command:
dig edge.cdn.local. +dnssec.
When KSK expiration is approaching (default 365 days), it is necessary to manually generate a new KSK for the TLD and add the DS Record to the parent zone. In order to avoid signing errors, it is suggested that an effective date is chosen which allows time for the DS Record to be added to the parent zone before the new KSK becomes active.