Signing a Delegated Subdomain

If you are already familiar with DNSSEC this is quite easy: How to sign a delegated subdomain zone. For the sake of completeness I am showing how to generate and use the appropriate DS record in order to preserve the chain of trust for DNSSEC.

This blogpost is part of a series about DNSSEC. Refer to this list for all articles.


You already have a DNSSEC signed zone, in my example: Beside hostnames within this domain you have a delegated zone with its own nameservers (= NS records). Now you must not only sign this new zone, in my example:, but you must also preserve the chain of trust. This is done by the delegation signer DS record which is placed in the parent zone. I assume that you already have the delegated zone working, i.e., NS records for it, zone file (SOA), etc.

Signing the Subdomain Itself

(Just a recap from my previous blogposts.) That is: Generating the KSK and ZSK, adjusting its ownership to be readable by BIND, and inserting the NSEC3 parameters in order to use NSEC3 rather than NSEC:


Using the DS Record

Note that this process is exactly the same as for your primary domain. For your domain you already have sent the DS record to your parent zone (such as .de or .com). Now it’s much easier since you’re owning both, the domain (in my case: AND the subdomain ( That is:

1) Generate the DS record from the KSK you created for your subdomain. Use the small  dnssec-dsfromkey program with the -2 option to have only the SHA-256 output (refer to IANA: Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms):

This resource record has an owner name of the delegated subdomain ( and the following four fields (refer to RFC 4034 “Resource Records for the DNS Security Extensions” section 5: The DS Resource Record):

  • the key tag 17463 which identifies the KSK,
  • the algorithm used for the KSK 10 = RSASHA512 as used while creating the KSK above,
  • the digest type 2 = SHA-256 and
  • the digest of the KSK (and some more fields) itself.

2) Place this single DS record into your parent zone. After a reload you’re done. ;)


Note the “ad” flag for all of those queries. (Only when resolved by a DNSSEC validating resolver.) You can now query the NS records for your subdomain:

its DNSKEYs (KSK and ZSK):

as well as the DS record in the parent zone:

Querying a hostname within the delegated subdomain shows the “ad” flag as well (line 7), which proves its authenticity:

Testing NSEC3 with a unvalid name to show up the NSEC3 records works as well:


That’s it! Congrats.

Some more DNSViz

Of course you can use DNSViz again to graph the chain of trust. For my test hostname this looks like that:

During my implementation of this delegated subdomain I queried DNSViz after each step about the SOA record for the the subdomain which showed these graphs:

  1. Delegated zone was neither signed nor did the DS record exist
  2. Delegated zone was signed but the DS record did not exist
  3. Completely signed and secure

Featured image “Vorhängeschlösser mit Zahlenschloss” by Marco Verch is licensed under CC BY 2.0.

Leave a Reply

Your email address will not be published. Required fields are marked *