James's Ramblings

DNSSEC

Created: April 02, 2020

Very rough notes on DNSSEC from various sources.

RFC4033

https://tools.ietf.org/html/rfc4033

From the new DNSSEC features of BIND version 9.11 (NL) it is clear that this security technology is now mature and the implementation is nearing completion. The main addition of relevance in connection with authoritative name servers is the ‘dnssec-keymgr’ command. As suggested above, this Python-based wrapper combines the ‘dnssec-keygen’ and ‘dnssec-settime’ commands to form a tool for the automation of key management and rollovers.Automation involves the formulation of an overall policy or zone-specific policies in the file /etc/dnssec-policy.conf. The contents of that file are then used by ‘dnssec-keymgr’ (e.g. in the context of an hourly cron job) to generate new key pairs where required. After that, the new keys are automatically adopted using the previously described Auto-DNSSEC feature.The ‘dnssec-keymgr’ command will then be something like this:

dnssec-keymgr -K /etc/bind/keys/ -r /dev/random

The random generator and the key directory are specified in the ‘dnssec-keymgr’ script for use with the ‘dnssec-keygen’ command. Where appropriate, an alternative path can be specified for the configuration file using the ‘-c’ option. The key directory can also be specified in the policy file itself (e.g. for each zone).

The policy file ‘/etc/dnssec-policy.conf’ contains policy classes (‘policy '): profiles from which the settings can be inherited by policies of other classes. An algorithm policy ('algorithm-policy ') contains settings for an individual cryptographic algorithm. Finally, a zone policy ('zone ') contains the policy for a particular zone.The following is an example of a policy's contents:

  algorithm-policy RSASHA256 {
    key-size zsk 2048;
    key-size ksk 4096;
  };

  policy normal {
    algorithm RSASHA256;
    roll-period zsk 3mo;
    roll-period ksk 1y;
    pre-publish zsk 1mo;
    pre-publish ksk 1mo;
    post-publish zsk 1mo;
    post-publish ksk 1mo;
    coverage 6mo;
  };

  policy extra {
    algorithm RSASHA256;
    roll-period zsk 6mo;
    roll-period ksk 2y;
    pre-publish zsk 1mo;
    pre-publish ksk 1mo;
    post-publish zsk 1mo;
    post-publish ksk 1mo;
    coverage 1y;
  };

  zone example.nl. {
    policy normal;
    algorithm ECDSAP256SHA256;
  };

In the file above, the length of the (default) algorithm RSASHA256 is defined as 2048 bits for the ZSK pair and and 4096 bits for the KSK pair. That overrules the default setting, which is 2048 bits for both types. In addition, two policies are defined: ‘normal’ and ‘extra’ (the latter featuring longer time intervals). Finally, the ‘normal’ policy is used for the zone example.nl, but then in combination with the ECDSAP256SHA256 algorithm (number 13).

The following example illustrates how ‘dnssec-keymgr’ builds on the previously generated key files in the /etc/bind/keys/ directory in order to comply with the policy defined for example.nl:

[root@services]# dnssec-keymgr -K /etc/bind/keys/ -r /dev/random
# /usr/sbin/dnssec-settime -K /etc/bind/keys/ -I 20180503135334 \
#	-D 20180602135334 Kexample.nl.+013+59790
# /usr/sbin/dnssec-keygen -q -K /etc/bind/keys/ -S Kexample.nl.+013+59790 \
#	-r /dev/random -i 2592000

First, the timing information in the existing ZSK files (with key ID 59790) is modified. Then a corresponding key pair is generated.

The ‘dnssec-coverage’ command (also based on Python and available in BIND from version 9.9.3) can be used to check the remaining validity period of a zone’s existing and serial/overlapping key pairs collectively. The check enables you to verify that the zone’s signed status will not be interrupted (rendering your domain names unreachable for validating resolver users).

dnssec-coverage -K /etc/bind/keys/ -m 1d -d 1d -r 1w example.nl

When you use the ‘dnssec-coverage’ command, not only is the meta-data in the key files consulted, but information is also required regarding the maximum TTL (using the ‘-m’ option), the TTL for the DNSKEY records (using the ‘-d’ option) and the period until re-signing (using the ‘-r’ option). If you load the zone data from a file (using the ‘-f’ option), ‘dnssec-coverage’ will use the TTL information from the zone file itself.When no zone name is specified, ‘dnssec-coverage’ will return details of all the zones in the key directory. With the ‘-l’ option applied, the response will detail only those zones that require attention within a given period. Finally, there are the ‘-z’ and ‘-k’ options, which limit the check to, respectively, ZSK pairs only and KSK pairs only.The following example illustrates use of the command to check the coverage of the key files that we generated earlier for the domain example.nl:

[root@services]# dnssec-coverage -K /etc/bind/keys/ -m 1d -d 1d -r 1w example.nl PHASE 1–Loading keys to check for internal timing problems PHASE 2–Scanning future key events for coverage failures Checking scheduled KSK events for zone example.nl, algorithm ECDSAP256SHA256… Fri Feb 02 13:47:34 UTC 2018: Publish: example.nl/ECDSAP256SHA256/24497 (KSK) Activate: example.nl/ECDSAP256SHA256/24497 (KSK)

No errors found

Checking scheduled ZSK events for zone example.nl, algorithm ECDSAP256SHA256… Fri Feb 02 13:53:34 UTC 2018: Publish: example.nl/ECDSAP256SHA256/59790 (ZSK) Activate: example.nl/ECDSAP256SHA256/59790 (ZSK) Tue Apr 03 13:53:34 UTC 2018: Publish: example.nl/ECDSAP256SHA256/12391 (ZSK) Thu May 03 13:53:34 UTC 2018: Inactive: example.nl/ECDSAP256SHA256/59790 (ZSK) Activate: example.nl/ECDSAP256SHA256/12391 (ZSK) Sat Jun 02 13:53:34 UTC 2018: Delete: example.nl/ECDSAP256SHA256/59790 (ZSK)

No errors found

11.4 Zone status

In addition, from BIND version 9.10.0, you can use the ‘rndc zonestatus’ command to obtain a detailed statement of the status of a particular zone:

[root@services]# rndc zonestatus example.nl name: example.nl type: master files: db.example.nl serial: 2018012801 signed serial: 2018012803 nodes: 6 last loaded: Sun, 28 Jan 2018 19:54:50 GMT secure: yes inline signing: yes key maintenance: automatic next key event: Tue, 30 Jan 2018 13:14:01 GMT next resign node: ns1.example.nl/NSEC next resign time: Tue, 30 Jan 2018 18:48:44 GMT dynamic: no reconfigurable via modzone: no

11.5 Show zone

A related command is ‘rndc showzone’ (available from BIND version 9.11.0), which retrieves the current configuration settings for a given zone:

[root@services]# rndc showzone example.nl zone “example.nl” in { type master; file “db.example.nl”; auto-dnssec maintain; dnssec-dnskey-kskonly yes; inline-signing yes; key-directory “/etc/bind/keys”; serial-update-method date; sig-validity-interval 10 7; };

The latter example features two further configuration options not previously considered. When the (default) option ‘serial-update-method date’ is applied, the serial number of a dynamic DNS zone is increased by 1 every time that a change is made. The alternative to the default setting is ‘serial-update-method unixtime’, which causes the number of seconds since the UNIX epoch to be inserted instead of the serial number (unless the current serial number is equal to or greater than the number of seconds).The option ‘sig-validity-interval 10 7’ indicates that the digital signatures (the RRSIG records) generated for dynamic DNS zones have a validity period of ten days, and that they are automatically refreshed seven days before that period expires. If you do not specify a refresh value, a default value equal to a quarter of the validity period is used.The option ‘dnssec-dnskey-kskonly yes’ was considered earlier in the context of the use of the’dnssec-signzone’ command.

Implementation in BIND9

See the appropriate BIND9 Administrator Reference Manual. https://www.sidn.nl/en/dnssec/dnssec-signatures-in-bind-named: better.

Going from old at the start, to new at the end.

Step 1: named.conf

In named.conf or via include:

dnssec-enable yes;
dnssec-validation auto;

  • Recursion must be enable on forwarding/caching DNS servers.

  • dnssec-enable yes: enables the server to respond with DNSSEC information to clients.

  • It is also necessary to enable dnssec-enable yes on resolvers.

  • dnssec-validation auto;: uses BIND’s built-in managed keys. managed-keys {}; are kept up-to-date automatically.

  • dnssec-validation yes;: is an alternative to auto that involves using manually managed trusted-keys {};.

    yes is ineffectual unless the server has access to trust anchors from which to establish a DNSSEC-validated chain of trust.

  • dnssec-lookaside {auto|yes|no};: a legacy option used to configure Dynamic Lookaside Validation (DLV), an ISC service that dates from before the root zone was signed. This was made redundant in 2017 when the capability to sign the root zone was introduced.

Step 2: Generating Keys

  • We need to generate a KSK and ZSK key pair.

  • Various algorithms available, ECDSAP256SHA256, currently recommended.

KSK:

mkdir -p /etc/bind/keys/
cd /etc/bind/keys/
dnssec-keygen -f KSK -3 -a ECDSAP256SHA256 -r /dev/random <DOMAIN.COM>
Generating key pair.
K<DOMAIN.COM>.+013+11769

  • BIND versions older than 9.9.2 don’t support ECDSA. Use -a RSASHA256 -b 4096. ZSK is replaced a lot more often therefore -b 2048 is appropriate.

  • The ‘-3’ option verifies that the selected algorithm is compatible with NSEC3.

  • For DNSSEC key pairs, the ‘nametype’ and ‘class’ have to be the same as ZONE and IN, respectively. This is default.

ZSK:

dnssec-keygen -3 -a ECDSAP256SHA256 -r /dev/random <DOMAIN.COM>
Generating key pair.
K<DOMAIN.COM>.+013+59790

Step 3: Examine Key Files

In /etc/bind/keys/:

- `Kdomain.com.+013+11769.key`: KSK DNSKEY
- `Kdomain.com.+013+11769.private`: KSK secret (600)
- `Kdomain.com.+013+59790.key`: ZSK DNSKEY 
- `Kdomain.com.+013+59790.private`: ZSK secret (600)
  • 013: the algorithm used: ECDSAP256SHA256.
  • 5 digit number: random unique number used for visual id.

Step 4: Signing

dnssec-signzone -S -K /etc/bind/keys/ -g -a -r /dev/random \
	-o domain.com db.domain.com

Fetching ZSK 59790/ECDSAP256SHA256 from key repository.
Fetching KSK 11769/ECDSAP256SHA256 from key repository.
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                            ZSKs: 1 active, 0 stand-by, 0 revoked
db.domain.com.signed

  • The result is a signed zone file db.domain.com.signed, which includes not only the DNSKEY records, but also an RRSIG record for each resource record set (RRset), containing the digital signature for the RRset in question.

  • In addition, a chain of (signed) NSEC records is added, enabling the non-existence of a queried name (NXDOMAIN) to be reported using a DNSSEC-signed reply.

  • When the zone file is generated, a check is performed to verify that at least one valid, self-signed KSK is present, and that all the records are signed. The ‘-a’ option ensures that all digital signatures (RRSIG records) are also validated.

Step 5: Verification

dnssec-verify -o domain.com db.domain.com.signed

Step 6: Deploying the signed db file

Within a zone file:

zone "domain.com" {
  type master;
  file "db.domain.com.signed";
  #file "db.domain.com";
  };

In the shell:

rndc reconfig
rndc reload domain.com

Verification: dig @localhost +dnssec domain.com

  • Should return RRSIG records.

Smart Signing

If the ‘-S’ option (smart signing) is applied, the current public keys (the DNSKEY records as previously generated in the /etc/bind/keys/ directory) are included in the zone file (and signed). The date information in the key files is then used to specify which keys are currently live:

Created

Publish: DNSKEY records with a date in the past are published

Activate: DNSKEY records with a date in the past are published and used to sign the zone

Revoke: DNSKEY records with a date in the past are published as revoked (by setting a REVOKE flag); if such a record has a valid Publish date, it is also used to sign the zone

Inactive (Retire): DNSKEY records with a date in the past are published but not (or no longer) used to sign the zone

Delete (previously Unpublish): DNSKEY records with a date in the past are not published and not used to sign the zone

Revoke

  • Use dnssec-revoke.
  • Add -r to remove the key files at the same time.

Key Management

If no explicit date options are provided with the ‘dnssec-signzone’ command, only the Created, Publish and Activate fields are added (all three set to the time of creation, ‘now’). In principle, that is also sufficient for DNSSEC, since in protocol-technical terms key pairs have an administrative lifetime, not an absolute lifetime

In practice, however, key pairs are regularly rolled over. For KSK pairs, the rollover interval is typically a year or a few years. With ZSK pairs, rollovers usually take place once a month or once a quarter.

Having just generated a KSK pair and a ZSK pair, a second ZSK pair can be generated for a rollover by using the following command, for example:

dnssec-keygen -3 -a ECDSAP256SHA256 -P now -A +5w -r /dev/random domain.com

The effect of the options ‘-P now -A +5w’ is that the newly generated key pair is published immediately, but not activated for five weeks.

Automation

Smart signing makes it possible to automate key management and signing, and to interface with management software. That involves writing shell scripts and cron jobs that build on BIND named’s ‘dnssec-signzone’ and ‘dnssec-settime’ commands.

In addition, the ‘-S -i ' 'dnssec-keygen' options (from version 9.7.2) make it very straightforward to automate rollovers. Thus, the successor to a particular key pair (a 'linked key') is generated, ready for automatic rollover by means of the 'dnssec-signzone' smart signing mechanism.

No rollovers

If you wish, you can continue using the existing key pairs until they ultimately require replacement for security reasons (e.g. in connection with an incident) or because a new cryptographic protocol is adopted.

If the ‘-C’ option is applied, ‘dnssec-keygen’ generates ‘classic’ key files that do not contain any meta-data. That option can be useful if, for example, you want to generate new key pairs for processing by existing management software/scripts. DNSKEY records without date information are always added to the zone file by ‘dnssec-signzone’ and used for signing.

If you want a key pair that does contain meta-data, which is loaded but not published and used to sign the zone, you need to apply the ‘-G’ (Generate) option.

A Single Key Pair

Another simplification involves not having separate KSK and ZSK pairs, but using a single (KSK) pair. When the ‘-z’ option is applied, ‘dnssec-signzone’ uses the KSKs to sign all record sets (as opposed to only the DNSKEY records, including those for the ZSKs, which are used for signing in a stepped KSK/ZSK configuration).

The zone configuration option ‘update-check-ksk no’ has the same effect (from BIND named version 9.10.0 also for slave zones in combination with ‘inline-signing’).

The philosophy behind PowerDNS is that the complexity should be hidden from users (operators) as far as possible, and that everything that can be automated should be automated. Where the cryptographic keys are concerned, that implies using a single key pair as standard.

Regardless of what DNS server software you use, it will generally work well only if you rarely or never perform rollovers, or if the process is fully automated. That is because every KSK pair rollover involves multiple interactions with the operator of the superordinate domain in order to publish and delete DS records.

Using ‘Include’ to add DNSSEC records

With smart signing, the current public keys are automatically added to the zone file and signed. However, before smart signing was introduced, the DNSKEY records (the .key files) had to be ‘manually’ added to the zone file before they could be signed using ‘dnssec-signzone’. One method of manual addition was to add an $INCLUDE statement to the original zone file. The key pairs to be used for signing were specified at the point of use.It is still possible to get ‘dnssec-signzone’ to generate a separate file containing the DNSKEY records for the KSKs by applying the ‘-C’ option. That can be useful mainly where key material needs to be delivered to the operator of the superordinate domain – the final step in signing a domain.If you want all DNSSEC-specific records – DNSKEY, RRSIG, NSEC(3) and NSEC3PARAM – kept separate from the zone file, you need to apply the ‘-D’ option when using ‘dnssec-signzone’. The resulting file, db.example.nl.signed, can then be added to the existing zone file by using an $INCLUDE statement.

Auto-DNSSEC (Iteration 1)

From version 9.7.0, BIND named supports the ‘auto-dnssec’ zone configuration option. That involves internal use of BIND named’s Dynamic DNS facility (with the ‘local-ddns’ key) to sign an existing zone on-the-fly. The process described above can therefore be automated, doing away with a lot of the drudgery involved in manual re-signing and key management.Auto-DNSSEC supports two distinct levels of automation. If the option ‘auto-dnssec allow’ is activated, you simply have to generate (or place) the key pairs in the key directory before getting the zone (re-)signed using this command:

rndc sign domain.com

However, in this mode, the ‘rndc sign’ command will have to be used each time a key pair is rolled over or the signatures are nearing the end of their validity period.If you simply want to refresh the DNSKEY records in a zone in line with changes to the key directory, without simultaneously changing all the digital signatures, use the following command (available from BIND version 9.7.2):

rndc loadkeys domain.com

If you use the ‘auto-dnssec maintain’ option, the key directory is checked every hour for changes to the key pairs. Depending on the meta-data in the key files, each key pair is assigned the status ‘unpublished’, ‘published’, ‘active’, ‘expired’ or ‘withdrawn’. Thus, the published DNSKEY records are automatically kept up to date. In addition, the digital signatures (in the RRSIG records) can be reset where necessary. The effect of this option is therefore the same as the effect of including the ‘rndc sign’ command in a cron job, in combination with the ‘auto-dnssec allow’ option.With auto-DNSSEC, it is very easy to automate the rollover of ZSK pairs, simply by periodically putting the new keys in the key directory (using the ‘dnssec-keygen -S -i ' command). BIND named will automatically publish the new keys as DNSKEY records, and start using them for signing as soon as they become active. In principle, the process is the same for KSK pairs, except insofar as the associated key material has to be 'manually' registered with the superordinate domain.Precise control of the dynamic zone and the signing process is possible using the 'nsupdate -l' command. That functionality is significant mainly in relation to definition of the NSEC(3) parameters by injecting a NSEC3PARAM record into the zone information:

nsupdate -l update add example.nl NSEC3PARAM 1 1 100 1234567890

That procedure is followed because the default settings stipulate the use of NSEC, rather than the newer NSEC3.The (re-)signing process begins as soon as the command is sent, and the NSEC(3) chain is generated as well.The contents of the NSEC3PARAM record type are defined in RFC 5155 (section 4).Although the whole process of (re-)signing a zone can be directly controlled using nsupdate without the need for auto-DNSSEC (by successively adding the DNSKEY records and a NSEC3PARAM record to the zone), that possibility is not considered here.

In order to make use of auto-DNSSEC, the following option is added to the configuration file /etc/named.conf:

`key-directory “/etc/bind/keys”

Also, the ‘auto-dnssec maintain’ and ‘update-policy local’ options are added to each individual zone configuration:

’’’ zone “example.nl” { type master; file “db.example.nl”; auto-dnssec maintain; update-policy local; }; ‘’

The following command is then entered, so that BIND named loads the new configuration:

rndc reconfig

Whereas previously the name of the zone file ‘db.example.nl’ was replaced in the configuration file by the signed zone file ‘db.example.nl.signed’ generated using ‘dnssec-signzone’, the name of the original zone file is retained when the ‘auto-dnssec’ option is used. That is because signing of the zone information is an internal process.

When loading a zone file for the first time, with the DNSSEC keys already present, the file is signed automatically and no ‘rndc sign’ command is required.If the default frequency set for the ‘auto-dnssec maintain’ function (hourly) is inappropriate, you can adjust it using the configuration option ‘dnssec-loadkeys-interval’ (from BIND named version 9.10.0 also for slave zones in combination with ‘inline-signing’).If you want to undo the signing of a zone, place the option ‘dnssec-secure-to-insecure yes’ in the zone configuration.The option ‘auto-dnssec create’ was once reserved for telling BIND named to generate new key pairs to replace expired keys. That should have completed the automation of DNSSEC. However, the developers subsequently decided that the relevant functionality wasn’t appropriate for inclusion in named, so it was removed from the roadmap. With the arrival of version 9.11, it was replaced by the ‘dnssec-keymgr’ command (considered later in this article). 9.4 Signed zone files and journal files

With the new set-up, the automatically generated (signed) zone files – in our case the file db.example.nl.signed – are no longer in a directly readable form. In the interest of speed, zone files are now saved in a binary format (raw). If you do want to read them, use the following command:

named-checkzone -D -f raw -o - example.nl db.example.nl.signed

Otherwise dig:

dig @localhost axfr example.nl

In addition, a journal file – db.example.nl.jnl in our case – is maintained for each dynamic zone. Journal files are also in a binary format. They can be viewed using the following command:

named-journalprint db.example.nl.jnl

Automation: Inline Signing

From version 9.9.0 BIND also supports Inline-Signing. The inline signing function is a further development of auto-DNSSEC in combination with the ‘update-policy local’ option and no longer makes (inappropriate) use of dynamic DNS. The introduction of inline signing means that DNSSEC is also easy to set up on DNS servers that need to be static (e.g. because they receive their zone files from a database-driven back-end or some other type of DNS software).A typical set-up has a (hidden) master server that does the inline signing and then distributes the signed zone file to a number of (public) slave servers. Another possibility is to add a BIND named server to the DNS infrastructure as a bump-in-the-wire, and configure it for inline signing. However, a set-up of that kind could also be realised using OpenDNSSEC, which is specifically intended for that purpose. The configuration of OpenDNSSEC is considered in a separate other article (NL).

The configuration of a zone for Inline-Signing is almost exactly the same as configuring for auto-DNSSEC on the basis of dynamic DNS:

zone "domain.com" {
  type master;
  file "db.domain.com";
  auto-dnssec maintain;
  inline-signing yes;
  #update-policy local;
  };

The actual use of an inline signing installation is also as described above. The ‘rndc signing’ command is now available for the control initially exercised using the ‘nsupdate -l’ command. However, it is important to be aware of the difference between the ‘rndc signing’ command and the older ‘rndc sign’ command.The NSEC(3) parameters are now set using the ‘rndc signing -nsec3param’ command. That generates the NSEC3PARAM record that was previously injected into the zone information using an ‘nsupdate -l’ command. The (re-)signing process begins as soon as the ‘rndc signing -nsec3param’ command is sent, and the NSEC(3) chain is generated as well.You can check the current status of a zone using the following command:

[root@services]# rndc signing -list example.nl
Done signing with key 8160/RSASHA256
Done signing with key 19273/RSASHA256

Detailed Theory

  • DNSSEC creates a secure domain name system by adding cryptographic signatures to existing DNS records.

  • By checking its associated signature, you can verify that a requested DNS record comes from its authoritative name server and wasn’t altered en-route, opposed to a fake record injected in a man-in-the-middle attack.

  • DNSSEC adds a few new DNS record types:

    RRSIG - Contains a cryptographic signature DNSKEY - Contains a public signing key DS - Contains the hash of a DNSKEY record NSEC and NSEC3 - For explicit denial-of-existence of a DNS record CDNSKEY and CDS - For a child zone requesting updates to DS record(s) in the parent zone.

  • RRSIG, DNSKEY, and DS records are the most fundamental.

  • The first step towards securing a zone with DNSSEC is to group all the records with the same type into a resource record set (RRset). For example, if you have three AAAA records in your zone on the same label, they would all be bundled into a single AAAA RRset.

  • It’s actually this full RRset that gets digitally signed, opposed to individual DNS records.

  • Each zone in DNSSEC has a zone-signing key pair (ZSK): the private portion of the key digitally signs each RRset in the zone, while the public portion verifies the signature.

  • To enable DNSSEC, a zone operator creates digital signatures for each RRset using the private ZSK and stores them in their name server as RRSIG records.

  • The zone operator also needs to make their public ZSK available by adding it to their name server in a DNSKEY record.

  • When a DNSSEC resolver requests a particular record type (e.g., AAAA), the name server also returns the corresponding RRSIG.

  • The resolver can then pull the DNSKEY record containing the public ZSK from the name server.

  • Together, the RRset, RRSIG, and public ZSK can validate the response.

  • In addition to a zone-signing key, DNSSEC name servers also have a key-signing key (KSK).

  • The KSK validates the DNSKEY record in exactly the same way as our ZSK secured the rest of our RRsets in the previous section: It signs the public ZSK (which is stored in a DNSKEY record), creating an RRSIG for the DNSKEY.

  • Just like the public ZSK, the name server publishes the public KSK in another DNSKEY record.

  • Both the public KSK and public ZSK are signed by the private KSK. Resolvers can then use the public KSK to validate the public ZSK.

  • DNSKEY RRset and corresponding RRSIG records can be cached.

  • It’s difficult to swap out an old or compromised KSK. Changing the ZSK, on the other hand, is much easier. This allows us to use a smaller ZSK without compromising the security of the server, minimizing the amount of data that the server has to send with each response.

  • DNSSEC introduces a delegation signer (DS) record to allow the transfer of trust from a parent zone to a child zone. A zone operator hashes the DNSKEY record containing the public KSK and gives it to the parent zone to publish as a DS record.

  • Every time a resolver is referred to a child zone, the parent zone also provides a DS record.

  • To check the validity of the child zone’s public KSK, the resolver hashes it and compares it to the DS record from the parent.

  • If they match, the resolver can assume that the public KSK hasn’t been tampered with, which means it can trust all of the records in the child zone.

  • Note that any change in the KSK also requires a change in the parent zone’s DS record.

  • Changing the DS record is a multi-step process that can end up breaking the zone if it’s performed incorrectly.

  • First, the parent needs to add the new DS record, then they need to wait until the TTL for the original DS record to expire before removing it. This is why it’s much easier to swap out zone-signing keys than key-signing keys.

  • If you ask DNS for the IP address of a domain that doesn’t exist, it returns an empty answer—there’s no way to explicitly say, “sorry, the zone you requested doesn’t exist.” This is a problem if you want to authenticate the response, since there’s no message to sign. DNSSEC fixes this by adding the NSEC and NSEC3 record types. They both allow for an authenticated denial of existence.

  • NSEC works by returning the “next secure” record. Unfortunately, this solution allows anybody to walk through the zone and gather every single record without knowing which ones they’re looking for. This can be a potential security threat if the zone administrator was counting on the contents of the zone being private.

  • Because of this exposure of information, the NSEC3 record was created that adds a hashing mechanism so that the zone cannot be simply walked.

  • NSEC is simpler, and the simple answer to this question is operators should use NSEC when they don’t care about people crawling their domains. If you don’t care that someone might enumerate every name in your zone(zone walk), then use NSEC.

  • NSEC3 should be used in instances where zone operators care about others walking their entire zone. It’s downside is greater cryptographic overhead for recursive validators, and silghtly more complicated DNS configuration.

  • The DS record is signed just like any other RRset, which means it has a corresponding RRSIG in the parent. The whole validation process repeats until we get to the parent’s public KSK. To verify that, we need to go to that parent’s DS record, and on and on we go up the chain of trust.

  • However, when we finally get to the root DNS zone, we have a problem: there’s no parent DS record to validate against.

  • In the Root Signing Ceremony, several selected individuals from around the world come together and sign the root DNSKEY RRset in a very public and highly audited way.

  • The ceremony produces an RRSIG record that can be used to verify the root name server’s public KSK and ZSK. Instead of trusting the public KSK because of the parent’s DS record, we assume that it’s valid because we trust the security procedures around accessing the private KSK.