DNSSEC is a set of security extensions to DNS that provides the means for authenticating DNS records. It allows to prevent malicious activities like cache poisoning, phishing, and other attacks.
The purpose of DNSSEC is to protect Internet clients from counterfeit DNS data by verifying digital signatures embedded in the data.
How it works
DNSSEC creates a specific record with a digital signature for every resource record. The key peculiarity of a digital signature is the use of public key cryptography to ensure that DNS records are authentic. Every member of the system can check the signature, however, only those having the secret key can sign new or modified data.
Public keys are published as a DNSKEY resource record along with other resource records. A sequence of records that identifies public keys is called a chain of trust. The key authenticity is checked with its digests (fingerprint, hashes) that are sent to the parent zone as DS-records. Digests of the parent zone public keys are also sent to the corresponding parent zones. The chain of trust is built up to the root zone which public key and digests are published in the official documents of ICANN.
DNSSEC uses 2 types of keys:
ZSK (Zone Signing Key) — this key is used to sign records within the zone;
KSK (Key Signing Key) — this key is used to sign keys.
We recommend that you set larger values of the key length and update period for KSK than ZSK. A ZSK-key is used every time the domain zone is modified or updated. Using a short key makes it easier to sing a domain, and a short update period ensures a high level of security. KSK-keys are used only to sign the keys, that's why they are used not so often as ZSK. A long key does not affect the efficiency. Besides, it is safe to specify a long update period for a long key. A long update period of KSK-keys allows sending DS-records to the parent zone more rarely.
To avoid DNSSEC key compromising, the keys are updated. The keys are updated in steps so that slave servers and DNS caching servers have enough time for synchronization with the primary DNS server.
KSK-key update algorithm:
.1DS-records of a new KSK-key is published in the parent zone. In ISPmanager the next KSK-key is created right after the domain is signed or the old KSK-key is removed. A user may publish the DS-record of the new key beforehand. To update the KSK-key correctly in ISPmanager, you need to publish the DS-record of the new key in the parent zone one month before the KSK-key is updated;
.2Changing the KSK-key. The active KSK-key is changed into a new one. In ISPmanager the key is changed 2 weeks before the KSK-key is updated;
.3Removing DS-records of the old key from the parent zone. ISPmanager generates a new key allowing users to perform the required operations in the parent zone: delete the DS-record of the old key and add the DS-records of a new key.
ZSK-key update algorithm:
.1Creating and publishing a new ZSK-key in the domain zone. This operation is performed in ISPmanager 2 weeks before the key is changed. A new key is not used for signing the domain;
.2Changing the ZSK-key. A newly published ZSK-key is get activated. The old ZSK-key is no longer used for signing domains;
.3Deleting the old passive ZSK-key. This operation was performed 2 weeks after the ZSK-key was changed.
Note
When you set up DNSSEC, the package size will be enlarged. When exceeding 512 bytes, DNS will use TCP. Some routers do not allow to run DNS through TCP (port 53 is closed).
When exceeding the MTU limit, DNS will be filtered. MTU is the maximum transmission unit of one package that can be transmitted without fragmentation. The optimum MTU size is 1500 bytes.