DNS & BIND 9 DNSSEC Training

DNS is like chess

the rules are simple

but the chances to loose the game

are endless

• First developments 1981-1983
• Introduced into the Internet between 1983 and 1988
• Replacement for the static hosts.txt file
• Continuously updated and expanded
• Scales with the growth of the Internet
• Minimal built-in security

• The .alt TLD has been created for all applications that want to use a DNS style name resolution, but don't use the DNS protocol
• Applications that use DNS style names without the DNS protocol should use names under the .alt TLD to not collide with DNS names
• RFC 9476: https://www.rfc-editor.org/rfc/rfc9476.html

• The classic DNS from 1983 has not been designed with security in mind
• Attack vector: DNS cache poisoning
• Attack vector: Men-in-the-Middle data spoofing
• Attack vector: changes to the client DNS resolver configuration
• Attacks of authoritative DNS servers
• DNSSEC can help

• Cryptography has four purposes:
  • Confidentiality – keeping data secret
  • Integrity – Is it "as sent"?
  • Authentication – Did it come from the right place?
  • Non-Repudiation – Don’t tell me you didn't say that.
• DNSSEC implements: Authentication & Integrity
• The IETF has added confidentiality since 2016:
  • RFC 7858 "Specification for DNS over Transport Layer Security (TLS)" (DNS-over-TLS)
  • RFC 8484 "DNS Queries over HTTPS (DoH)" (DNS-over-HTTPS)
• DNS uses different authenticity and integrity techniques depending on the application.
• Symmetric Cryptography
  • Message Digests (aka: hashes, hash values, fingerprints)
  • Message Authentication Codes
• Asymmetric Cryptography
  • Digital Signatures

• Symmetric cryptography provides both integrity and authenticity.
• A single key is stored and used by both (all) parties.
  • The key encrypts and decrypts.
  • The key is a shared secret.
  • The system is known as pre-shared key (PSK).
  • Securely getting the key to all parties can be a challenge.
• Symmetric cryptography requires mutual trust.
  • "My security is good, but what about the other person's?"
  • If all sides are administered by one party, trust is a non-issue.
  • For DNS, Pre-Shared-Keys (PSK) work well:
    • between primary and secondary servers (TSIG).
    • for dynamic DNS updates (TSIG).
    • for controlling BIND 9 with rndc (TSIG).
  • For DNS, PSKs do not work well:
    • between DNS Resolver servers and authoritative DNS servers (DNSSEC).
    • between stub resolver & DNS Resolver servers (DNSSEC amongst other).

• In DNS, asymmetric cryptography is used for DNSSEC.
• This asymmetric cryptography section is a short overview.
• Asymmetric cryptography uses two keys, a pair.
  • Data encrypted with one key can only be decrypted by the other.
  • A key cannot decrypt what it encrypted!
  • One key of a pair is declared as public, the other as private.
  • The private key is highly sensitive, never shared, and must be well protected.
  • The public key is made widely available without concern for who knows it.
  • The technique is known as public key encryption.

    

• The DNS Security Extensions, described in RFC 2065 (old DNSSEC), allow a zone administrator to digitally sign zone data
• The base DNSSEC RFCs:
  • RFC 4033 to 4035 - Updates DNSSEC to DNSSECbis, published March 2005:
  • RFC 4033 - DNS Security Introduction and Requirements
  • RFC 4034 - Resource Records for the DNS Security Extensions
  • RFC 4035 - Protocol Modifications for the DNS Security Extensions
• The DNS security extension DNSSEC secures DNS data by augmenting the data with cryptographic signatures
  • The owner (administrator) creates a pair of private and secret keys for each DNS zone (asymmetric crypto)
  • The owner/administrator signs all DNS data with the private/secret key
  • The recipient of the data (DNS resolver or client operating system or application) will verify (validate) the data
    • That the data has not been changed on the server nor during transit
    • That the data comes from the owner (the owner of the private key)
  • DNSSEC signs data to guarantee authenticity and integrity.
    • It assures a client that a RRSet is from the proper authoritative sever and has not changed.
  • DNSSEC does not encrypt data to provide privacy.
    • Anyone can find out the RRSets you request.
• DNS Servers that support DNSSEC
  • BIND 9: Authoritative server and validating resolver
  • NSD from NLnet Labs: Fast authoritative server
  • Unbound from NLnet Labs :Fast and secure validating resolver
  • Windows DNS Server: Authoritative server and validating resolver
  • PowerDNS authoritative: Authoritative DNS Server with (optional) SQL Database backend
  • PowerDNS Recursor: a resolver with support for DNSSEC validation
  • Knot-DNS: fast authoritative DNS Server from nic.cz
  • Knot-DNS Resolver: recursive server with DNSSEC from nic.cz

• TSIG uses a keyed cryptographic hash algorithm, which requires that both endpoints share a key
• DNSSEC uses public key cryptography, which doesn't require shared keys
  • Zone data is signed by the zone administrator
  • This provides an end-to-end integrity check between producer (DNS Administrator) and consumer (Resolver, Application)

• DNSSEC signs RRSets, but alternatives were available to the designers:
  • An entire DNS message could be signed.
  • Just the answer section of a message could be signed.
  • Each RR in an answer could be signed.
• DNS messages and answer sections are dynamically generated when a query arrives. = The signatures would have to be dynamically generated.
• RRs and RRSets aren't modified when a query arrives at an authoritative server.
  • Signatures can be created when the zone is compiled.
• Signing each RRSet is most effectively and what is done.

• If an attacker breaks into the server with the master zone file, she can change any data, including the DNSKEY RRSet.
• The DNSKEY RRSet is signed by the zone's private key!
  • That signature, even when validated, proves nothing.
  • It's a circular problem.
• External validation is needed, but we can't look beyond DNS.
• DNSSEC creates a chain of trust between the parent zone and the child zone

• Applications and DNS resolver can follow the chain of trust to a configured trust anchor to validate the DNS data

• Even if a client does not explicitly request DNSSEC by setting the DO flag in a recursive query, it is protected.
  • It benefits from DNSSEC, if its recursive server is configured for DNSSEC.
  • The recursive server will return SERVFAIL if the requested RRSet proves unauthentic.
• DO Flag: DNSSEC OK
  • The client is requesting the authoritative server to return the RRSIG together with the queried RRSet.
    • The client is commonly a resolver, but it could be a stub resolver or application.
    • With EDNS the client also announces the UDP packet size it will handle.
    • If the DO flag is not set, RRSIGs are not returned by authoritative servers.
• AD Flag: Authentic Data
  • The resolver uses the AD flag to inform a DNSSEC-aware client that it has successfully authenticated the RRSet.
  • An unauthentic RRSet will not be sent to the client; the resolver returns SERVFAIL.
    • Without DNSSEC, SERVFAIL means an authoritative server isn't responding.
  • DO is client (resolver) to authoritative server, and AD is recursive resolver to client.
• CD Flag: Checking Disabled
  • An application or stub resolver can tell the recursive server that it will validate the DNSSEC information itself.
  • This is ideal where the recursive server can't be trusted.
    • A recursive server is often run by a third party, e.g. an ISP or Internet cafe, and therefore is not inherently trustworthy.
    • Additionally, the connection between the application or stub resolver with even a trusted recursive server, is likely insecure.
  • There is no way for a client to force a recursive resolver to use, or not use, DNSSEC.
  • CD with DO tells the recursive resolver to return the queried RRSet regardless of its authentication.
    • The CD flag is an excellent debugging resource.
    • For example, if a client receives SERVFAIL, requerying with dig can indicate if the problem is DNSSEC or not.

    $ dig example.com +cdflag
    

• CO Flag - Compact Answers OK
  • Compact Denial of Existence is a new DNSSEC extension that allows authenticated Denial of Existence with NSEC (and optionally NSEC3) for online signer
    • it also prevents Zone Walking, even with NSEC records
    • the CO Flag is send by an DNS resolver towards authoritative DNS-servers (primary or secondary) to inform the receiver that the sender does understand the new compact answers
    • the CO Flag is encoded inside the EDNS-Flag-space (alongside the DO-Flag)
  • Details: RFC 9824 Compact Denial of Existence in DNSSEC (September 2025)

  

• When the validator gets an RRSIG in a response, it needs the DNSKEY and DS RR to authenticate.
  • If validation fails, the signed RRs are discarded, and SERVFAIL error is returned to the client.
  • If no appropriate trust anchor exists, the RRSIG is ignored.
  • If the chain of trust is broken the signature is ignored.
• The steps in the following animation are simplified.
  • It only shows validation using one key per zone (SSK/CSK).
  • Commonly, a zone has ZSK & KSK, so there are additional steps.

• RFC 8914 - Extended DNS Errors defines a way to deliver additional error information in an DNS response. It is implemented in dig since version BIND 9.16.4. BIND 9.18 and other open source DNS-Server support EDE-Messages, as well as some DNS resolver on the Internet (like Cloudflare):

$ dig lame.defaultroutes.org soa @1.1.1.1                         <

; <<>> DiG 9.18.41 <<>> lame.defaultroutes.org soa @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29410
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 22 (No Reachable Authority): (at delegation lame.defaultroutes.org.)
;; QUESTION SECTION:
;lame.defaultroutes.org.		IN	SOA

;; Query time: 705 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Mon Nov 03 13:19:33 CET 2025
;; MSG SIZE  rcvd: 94

• Blog-Post: Extended DNS Errors used in DNS software and services

DNSSEC keys can be generated with different crypto algorithms. Some of these algorithms are obsolete and deprecated, others are not (yet) widely supported by deployed DNS software to be useful

• Every additional bit increases the strength of a DNSSEC against brute-force attacks to break the key
• Double the RSA key size results in
  • Generating signatures is up to eight times more work
  • Validation of DNSSEC signatures inside an DNS resolver up to 4 times more work
  • Size of key and signature records increases and can create operational issues

• For organizational reasons, DNSSEC splits the chain of trust inside a DNS zone onto two different keys: the Key-Signing-Key (KSK) and the Zone-Signing-Key (ZSK)

• For historical reasons, BIND 9 generates two signatures over the DNSKEY record set:
  • one signature generated with the KSK (required)
  • one signature generated with every active ZSK (optional)
• This can generate larger than good DNSKEY record answer messages
• BIND 9 can be configured to only generate a signature using the KSK

  options {
    [...]
    dnssec-dnskey-kskonly yes;
  };
  

• DNSSEC keys have an organisational lifetime (there is no technical limit on the lifetime, unlike with X.509 TLS certificates)
  • the administrator responsible for a DNSSEC-signed zone can decide when to change the DNSSEC keys
• Renewing the DNSSEC key material of a zone is called a key rollover
• Keys with weak algorithms or short key lengths should be changed (rolled) in shorter intervals
  • 1024bit RSASHA256 -> 30 days (ZSK)
  • 1536bit RSASHA256 -> 120 days (ZSK)
  • 2048bit RSASHA256 -> 360 days (KSK)
  • 2560bit RSASHA256 -> 720 days+ / 2 years+ (KSK)

• Zones with high security requirements should keep the DNSSEC keys "offline"
  • this requires manual DNSSEC signing
• Keys can be stored securely in Hardware Security Modules (HSM)
• HSM selection criteria for DNSSEC signing
  • Number of key storage slots
  • Timely support for new operating system releases (Linux distribution)
  • Timely support for new OpenSSL releases
  • Stability of the HSM-Driver
• Zones with medium to low security requirements should use a hidden-primary DNSSEC signer configuration
  • The DNSSEC signing authoritative server is not exposed to the Internet, it will not receive DNS queries
  • DNS secondary authoritative servers in the Internet will receive the DNSSEC signed zone from the hidden DNSSEC signer through DNS zone transfer
  • The DNSSEC key material is secured with operating system level permissions
  • With full automation of DNSSEC key-rollovers, the DNS server administrators don't need access to the DNSSEC keys
  • Login and access to the DNSSEC key files should be audited (Logging online and towards a remote log server)
• Zone content can be split across multiple zones or DNS server with DNS delegation
  • Every zone can have a different DNSSEC security level
  • Example: main zone example.com signed via a hidden-signer (keys not exposed to the Internet) has a sub-zone with e-mail address hashes (OPENPGPKEY and SMIMEA) in the zone securemail.example.com) which is secured with NSEC3-NARROW scheme and keys that are online on every authoritative server

• Since BIND 9.6 zones can be signed manually (BIND 9.6 was the first version to support the new DNSSEC version)
• Benefits:
  • The signing can be done offline on a machine not connected to any network, BIND 9 does not need to be running on the signing machine
  • The DNSSEC private keys can be stored on security devices such as Hardware Security Modules (HSM) and can be encrypted
  • The generated DNSSEC signed zone files are universal and can be used in any DNS server that supports DNSSEC signed zones
  • The parameters of the signing process can be tuned

• Drawbacks:
  • Manually signed zones need to be refreshed (re-signed) periodically so that the signatures do not expire
  • Any automation must be done through custom scripts

• Single CSK ("common signing key", also called a SSK - "single signing key")
  • ECDSAP256SHA256 (algo 13) with unlimited lifetime
  • RRSIG validity 14 days, refreshed 5 days before expiration
• NSEC
• Key timings:
  • DNSKEY TTL: 3600, max zone TTL: 86400 (1 day)
  • Key publish and retire safety times: 3600 (1 hour)
  • Propagation delay: 300 (5 minutes)
• Parent timings
  • DS TTL: 86400 (1 day)
  • Propagation delay: 3600 (1 hour)

• Prevent policy changes on upgrade by using an explicitly defined dnssec-policy, rather than default

dnssec-policy "one" {
    keys {
        ksk lifetime 365d algorithm rsasha256 4096;
        zsk lifetime 60d  algorithm rsasha256 1024;
    };
    dnskey-ttl 600;
    publish-safety PT2H;
    signatures-refresh 7d;

    nsec3param iterations 0 optout no salt-length 0;
};

dnssec-policy <string> {
    dnskey-ttl <duration>;
    keys { ( csk | ksk | zsk ) [ ( key-directory ) ]
        lifetime <duration_or_unlimited> algorithm <string> [ <integer> ]; ...
    };
    max-zone-ttl <duration>;
    nsec3param [ iterations <integer> ] [ optout <boolean> ] [ salt-length <integer> ];
    parent-ds-ttl <duration>;
    parent-propagation-delay <duration>;
    publish-safety <duration>;
    purge-keys <duration>;
    retire-safety <duration>;
    signatures-refresh <duration>;
    signatures-validity <duration>;
    signatures-validity-dnskey <duration>;
    zone-propagation-delay <duration>;
};

• A KSK with ECDSAP256SHA256 and no automatic key rollover
• A ZSK with ECDSAP256SHA256 and a rollover interval of 30 days
• Signatures are valid for 10 days
• Signatures will be refreshed after 8 days (2 day buffer)
• TTL of DNSKEY records is 2 hours
• Max TTL of other records in the zone is 1 day
• DNSSEC keys will be published one hour after they have become valid (publish-savety)
• DNSSEC keys will be kept in the zone one our after deactivation (retire-safety)
• Expired DNSSEC keys will be removed after 90 days
• Zone transfer between primary and secondary servers is 5 minutes (zone-propagation-delay)

dnssec-policy "example.eu" {
       dnskey-ttl 2h;
       keys { ksk lifetime unlimited algorithm ECDSAP256SHA256;
              zsk lifetime P30D      algorithm ECDSAP256SHA256;
            };
       max-zone-ttl 1d;
       publish-safety 1h;
       purge-keys P90D;
       retire-safety 1h;
       signatures-refresh 8d;
       signatures-validity 10d;
       signatures-validity-dnskey 10d;
       zone-propagation-delay 300;
 };

• Your zone zoneNN.dnslab.org. in the parent of p.zoneNN.dnslab.org
• In order to close the chain of trust, you must publish the DS-record for p.zoneNN.dnslab.org in your own zone zone.dnslab.org. The DS-record contains the hash of the main key of the zone (the KSK or CSK/SSK). The CSK can be found in /var/named/Kp.zoneNN.dnslab.org.+013+<CSK-ID>.key, and the DS-Record can be created with (replace ZZZZZ with the key-id):

  % dnssec-dsfromkey /var/named/Kp.zoneNN.dnslab.org.+013+ZZZZZ.key
  

• Add a delegation NS-Record into the parent zone zoneNN.dnslab.org

  p.zoneNN.dnslab.org.     IN NS nsNNa.dnslab.org.
  

• Add the DS-Record to the zone zoneNN.dnslab.org, increment the SOA serial number, resign the zoneNN.dnslab.org (the parent zone that does not use automation) with dnssec-signzone (same command used in the previous exercises).
• Reload the parent zone

  % rndc reload zoneNN.dnslab.org
  

• Try again to query a name from the zone p.zoneNN.dnslab.org, the AD flag should now appear.

• The RRSIG records in DNSSEC secure the positive answers from DNS (answers to queries where DNS records exist)
• But also negative answers need to be protected
  • without protection for negative answers, attackers could spoof negative answers to launch denial-of-service attacks. The attacker can make DNS clients believe that a DNS resource does not exist
• DNS knows two kinds of negative answers: NXDOMAIN and NODATA/NXRRSET
  • NXDOMAIN = the requested domain name does not exist
  • NODATA/NXRRSET = the requested domain name does exist, but the requested record type does not exist for this name
• DNS error messages such as SERVFAIL, FORMERR or REFUSED cannot be secured with DNSSEC (these errors indicate errors in the protocol or in the DNS server infrastructure). If the protocol is broken, DNSSEC can't work either.
• The solution: the NSEC records in the DNSSEC signed zone create a list of all existing data in the zone (domain names and records types for the domain names)
  • When returning a negative answer, the DNS server returns the negative answer containing the NSEC record (plus a signature for the NSEC record) which proves that the requested data does not exist in DNS

• The NSEC record is an elegant solution to the problem, but it has drawbacks:
  • It is now possible for outsiders to list the complete zone contents by following the NSEC record chain. This is called zone walking.
  • For most zones this is not a big problem, as the DNS zone content is public anyway (SOA, NS records, WWW-A, MX records)
  • But it can be an issue for zones with sensitive content (email addresses, hostnames of critical infrastructure, new product names that should no go public yet)
  • Operators of TLDs zones stay away from DNSSEC with NSEC, as it allows outsiders to record all changes to the TLD zone (new delegations and delegation removals)
  • The new compact authenticated denial of existance standard (RFC 9824) solves this issue.
• Example of zone walking:

$ ldns-walk paypal.com

• RFC 5155 (2008) defines the NSEC3 record as an alternative to NSEC
  • All modern DNS servers support NSEC3
  • The NSEC3 record works similarly to NSEC, with the difference that the link between the owner names is done using SHA1 hashes of the domain names instead of the clear text names
  • NSEC3 makes it harder, but not impossible, to list the zone content

• The NSEC3 record contains a number of parameters used for the NSEC3 operation
  • The hashing algorithm used (currently only SHA1 is defined)
  • Flags: allows for DNSSEC opt-out in delegations.
  • Number of hash iterations
  • A salt value

• Every zone with NSEC3 records contains an NSEC3PARAM record. This record holds information needed by authoritative DNS servers to generate NSEC3 records for negative answers
• Example: (SHA1, no flags, 20 iterations, salt value "ABBACAFE")

nsec3.dnslab.org.    0   IN  NSEC3PARAM 1 0 20 ABBACAFE

• The idea of the hash iterations in the NSEC3PARAM record was to allow the operator of the zone to fine tune the work required for calculating the hash
  • A higher number of iterations should make it harder for attackers to brute force break an NSEC3 domain name
  • A higher number also creates more CPU load for DNS resolvers that validate the NSEC3 records, making DNS name resolution slower
  • The iteration parameter of an NSEC3 signed zone should be re-evaluated from time to time (yearly) to adjust the value for the technical progress
• The salt should make it impossible for an attacker to pre-calculate rainbow tables for the zone
• The salt is a hexadecimal number, every hex digit contains 4 bit of information

• The iterations had more an negative impact on the CPU load of the authoritative DNS servers than preventing attacks
• The salt is not really needed, as each zone naturally has unique hashes so that a rainbow table for multiple zones is not possible

• RFC 9276 - Guidance for NSEC3 Parameter Settings (Best current practice) gives updates guidelines for NSEC and NSEC3 deployments
• The iterations value should be set to 0 (meaning 1 iteration of SHA1 hashing)
  • DNSSEC responses containing NSEC3 records with iteration counts greater than 150 are now treated as insecure by major DNS resolvers!
• As NSEC3 zones are inherently salted, the salt parameter should be set to -
• The current recommendation for NSEC3PARAM is 1 0 0 - (SHA1 Hash, no flags, 1 iteration, no salt)

• Most DNS zone can work with NSEC instead of NSEC3
  • Don't store names in DNS that should be secret (internal names, product names etc)
  • DNS is a service to publish data, not for hiding data

• RFC 7129 (also RFC 4470 and RFC 4471) describe a special variant of NSEC3 usage, called the narrow mode
  • With narrow mode, the NSEC3 records are not pre-calculated when the zone is signed, but they are created on the fly whenever a negative response is needed
    • To be able to calculate the signatures for such answers, every authoritative DNS server for the zone must have access to the private DNSSEC keys (at least the ZSK)!
• With NSEC3 narrow mode, the DNS server does not return an NSEC3 chain of existing records, but a synthetic NSEC3 record that proves that the requested name does not exist
  • This prevents zone walking, as the number of possible NSEC3 records returned is near infinite. It will exhaust the memory of the attacker that will try to store this NSEC3 chain
• Known implementations:
  • Phreebird (Dan Kaminski, Proof-of-Concept, not maintained)
  • PowerDNS Authoritative
  • Cloudflare CDN NSEC3 Narrow-Mode (closed source implementation)

• The DNSSEC key material is public
  • Including the signatures and the matching clear text (DNS record sets)
• The private key can get in un-authorized hands
  • By accident
  • By attacks on the signing server/HSM
  • When using online-signing, the private keys must be live on the signing DNS server
• The key length or the algorithm used is not considered secure for a longer amount of time (for example 1024bit RSA keys)

• The DNS is not consistent
  • DNS zone data can differ for some time between authoritative server of the same zone (delay in zone transfer)
  • DNS data is cached in DNS resolvers, operating systems, and applications
• During a DNSSEC key-rollover, the chain of trust must be un-broken at all times from all vantage points of the Internet

• RFC 6781 - DNSSEC Operational Practices, Version 2
• RFC 7583 - DNSSEC Key Rollover Timing Considerations

• DNSSEC keys do not have a technical lifetime, they don't expire
• The operational life time of DNSSEC keys is decided by the responsible administrator(s) and can be changed at any time
• The DNSSEC community has different views on KSK key rollovers
  • Often and regularly
  • Often but irregular (to not give attackers information when the system might be more vulnerable due to the key rollover)
  • Only if there is evidence that the key has been compromised or stolen

• The Zone-Signing-Key has no dependencies to external resources (such as the parent zone)
• A ZSK Rollover can be started at any time
• The 'pre-publication' rollover scheme is used for ZSK rollover

• The KSK has a dependency on its DS record in the parent zone
• For the KSK rollover we will use the 'double-signing' rollover scheme (the DNSKEY record set will get two signatures, from both, old and new, KSK)

• An algorithm rollover is used when the DNSSEC key algorithm of the zone needs to be changed
  • e.g. when switching from RSASHA256 to ECDSASHA256
• During an algorithm rollover, the KSK and ZSK will be changed at the same time using a double-signing rollover scheme
  • During such a roll over, the zone should be monitored for failures and over sized DNS answer messages
  • Link: DNSSEC algorithm rollover HOWTO by Tony Finch (Univ. of Cambridge)

• In an emergency, time is at an essence
• To save time on an KSK rollover, step one (publication) can be done ahead of time
  • This published extra key is called the standby key
  • It saves time, but makes the DNSKEY RRSet larger
• The standby key is not used during normal DNSSEC signing operation
• If there is a need to change the KSK in an emergency, the zone can almost immediately switch over to the standby key
• The standby key should be replaced (rolled) whenever the production KSK is rolled

• RFC 7344/8087 defines an automatic way to update the chain of trust towards the parent zone in an KSK key rollover
• The operator of the zone creates a new KSK for the zone and then publishes the new DS record or/and DNSKEY record for the parent zone in a CDS and/or CDNSKEY record in the zone
• The authoritative DNS server for the parent zone periodically polls the child zones for new CDS or CDNSKEY records
• Once a new CDS record is found, it will be validated against the current KSK and DS records, and if it is valid, it will be imported into the parent zone (replacing the DS record)
  • If a new CDNSKEY record is found in the child zone, the authoritative DNS server of the parent zone will validate the record, calculate the hash to get a DS record, and will then replace the DS record with the newly calculated DS record
• BIND 9 supports CDS and CDNSKEY since version 9.11
• The dnssec-cds utility can change DS records for a child zone based on CDS/CDNSKEY records
• CDS and CDNSKEY is already supported by some TLDs (Czech Republic .cz, Switzerland .ch, Lichtenstein .li, Sweden .se …)

  

• With automated DNSSEC delegation trust maintenance (RFC 8078), the parent domain operator (most often the TLD operator) will "scan" all child domains for new CDS/CDNSKEYs
  • This is resource intensive
  • It is done is intervals, for example 24 hours - changes to the CDS/CDNSKEY will propagate based on that interval - child zone operators need to wait multiple hours for the change to appear in the parent zone
• RFC 9859 - Generalized DNS Notifications (September 2025) extends the use of DNS notification (used for ages in DNS to inform secondary server of a new zone version to trigger a zone transfer) for other purposes
• One is to send a notify from the primary server of a child zone to the primary server of the parent zone to inform the parent zone of a new CDS/CDNSKEY
  • No need for the parent to scan all child domains
  • Faster propagation times (seconds instead of hours)
• Support for "Gerneralized DNS Notifications" is planned for BIND 9.22 (Q2/2026)

https://i.blackhat.com/USA-22/Thursday/US-22-Heftrig-DNSSEC-Downgrade-Attacks.pdf

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/9.0_release_notes/overview

• The hash algorithm SHA1 is weak
• It should be phased out for existing DNSSEC zones
• It should not be used for new DNSSEC deployments (use RSASHA256 or ECDSA)
• Double-Signing zones with SHA1 and other (stronger) algorithms does not help as downgrade attacks are possible

• UDP fragmentation can be used to attack DNS traffic
• There is a specific danger for DNS resolver that does not validate DNSSEC
  • But receive DNSSEC signed data, as DNSSEC signatures create large(r) DNS responses
• BSI Study: IP Fragmentation and Measures against DNS Cache Poisoning (Frag-DNS)

• Avoid old(er) Linux kernels that are vulnerable to MTU downgrade attacks through ICMP spoofing (Long-Term/Enterprise Kernel)
• Configure the authoritative DNS server with an maximum UDP answer size of 1232byte (EDNS0 Buffer Size)
• Make sure the authoritative DNS server does respond on TCP port 53 (See RFC 7766 - DNS Transport over TCP - Implementation Requirements)
• DNSSEC sign your zones so that resolvers can validate

• Enable DNSSEC validation
• Configure the authoritative DNS server with an maximum UDP answer size of 1232byte (EDNS0 Buffer Size)
• Make sure the DNS resolver can query DNS content over TCP
• Block fragmented DNS responses coming from the Internet in the Firewall (they should never occur with an EDNS0 buffer of 1232byte)
• RFC 9715 - IP Fragmentation Avoidance in DNS over UDP

DNSEC validation issues are often a problem with misconfiguration at the authoritative DNS server side of the domain, not an issue of the DNS resolver system. However to be able to debug DNSSEC issues, for example to decide if an NTA (negative trust anchor) should be inserted into the DNS resolver system to temporarily disable DNSSEC validation for a specific domain, the DNSSEC validation issue should be investigated first.

• Often DNSSEC validation issues are caused by operational issues (expired DNSSEC signatures, DS record and DNSKEY KSK mismatch etc)
  • Negative Trust Anchors can be used to disable DNSSEC validation for mis-configured domains
• Negative Trust Anchors are defined in RFC 7646 Definition and Use of DNSSEC Negative Trust Anchors
• Negative trust anchors (nta) disable DNSSEC validation for a specific domain for a certain amount of time
  • NTA can be used by operators in case a misconfiguration for a remote DNSSEC signed zone is detected. Care should be take to check that the DNSSEC validation failure is indeed a misconfiguration and not attack
• Domains with an NTA are processed as if there is no trust-anchor for that domain
• NTAs are stored and are persistent across BIND 9 restarts
• BIND 9 checks the domain periodically. Once the domain starts validating again, the NTA for the domain is removed
• NTAs have a lifetime (maximum one week) and expire automatically
• Example: adding an NTA (for 60 seconds):

% rndc nta -l 60 fail01.dnssec.works
Negative trust anchor added: fail01.dnssec.works/_default, expires 18-Aug-2016 13:52:19.000
% rndc nta -dump
fail01.dnssec.works: expired 18-Aug-2016 13:52:19.000
% ls -l /var/named/_default.nta
-rw-r--r--. 1 root root 44 Aug 18 13:51 /var/named/_default.nta
% cat /var/named/_default.nta
fail01.dnssec.works. regular 20160818115219

• Example: removing an NTA

% rndc nta -l 86400 fail02.dnssec.works  # add a NTA for 1 day
Negative trust anchor added: fail02.dnssec.works/_default, expires 19-Aug-2016 13:56:22.000

% rndc nta -dump
fail02.dnssec.works: expiry 19-Aug-2016 13:56:22.000

% rndc nta -r fail02.dnssec.works # remove the NTA
Negative trust anchor removed: fail02.dnssec.works/_default

% rndc nta -dump    # NTA is now gone

• Make sure your DNSSEC validating resolver supports DNSSEC negative trust anchor
• Test the negative trust anchor function
• Document how to add a negative trust anchor
• If your software does not support automatic removal of NTAs, implement an automation (connected to your DNS resolver monitoring)
• Do not implement automatic NTA additions, activating an NTA should only occur after human inspection of the DNSSEC validation problem
• Read the Internet Draft Recommendations for DNSSEC Resolvers Operators

• DNSSEC validation is time sensitive
  • The DNSSEC signatures have expire and inception (become valid) times that the DNS resolver must check
• Without a correct time on the DNSSEC resolver machine, DNSSEC validation might fail
• Recommendation: Implement automatic time synchronization for the DNSSEC resolver (NTP, PTP)
• Make sure the time synchronization has no dependency on (DNSSEC) DNS name resolution (no circular dependecy or chicken-and-egg-problem)
  • A great usecase for Precision Time Protocol (PTP https://en.wikipedia.org/wiki/Precision_Time_Protocol) if available in the network

• A DNSSEC validating resolver will respond with the DNS error SERVFAIL to the DNS client whenever it detects a mismatch in the DNSSEC chain of trust or a bogus or expired DNSSEC signature
  • SERVFAIL is not DNSSEC specific, there are many error situations that can result in an SERVFAIL response
  • The end user cannot detect that the DNS name resolution fails because of DNSSEC security and will blame the operator of the DNS resolver for the outage

• An authoritative DNS server with an NSEC3 DNSSEC signed zone must calculate one or more SHA1 hash(es) for every negative DNS response (NXDOMAIN or NODATA)
  • This yields the risk of Denial-of-Service attacks against the authoritative server due to CPU resource exhaustion

• Errors during the signing process
• Error while publishing/replacing the DS record in the parent zone
• Error while refreshing the DNSSEC signatures (RRSIG records)
• Errors during key rollover
• Operational issues because of too large DNS response packets (>1232 byte)
• DNSSEC validation issues because of messy DNS resolution path (CNAME redirections between DNSSEC signed and unsigned zones)
• DNS errors because of Parent/Child zone disagreement (NS records in parent zone delegation do not match NS records in the zone)

• Is DNSSEC a risk for the network?
  • Yes, but it is a risk that can be mitigated with planning, automation, and careful work
  • The DNSSEC benefits outweighs the risks

• DNS and DNSSEC Monitoring scripts: https://github.com/menandmice-services/dns-monitoring-scripts
• When parents and children disagree: Diving into DNS delegation inconsistency https://www.caida.org/publications/papers/2020/when_parents_children_disagree/

• A DNS zone having a DS-Record must be DNSSEC signed with that key
• In a split-horizon DNS, the interal DNS only covers the second-level domain (SLD), not the TLD
  • but the DS-Record will be looked up in top-level-domain (in the Internet)
• If a DNS resolver has a DS-record in the cache, and it receives DNS records from this zone without signatures (RRSig), it will not resolve these domain names (SERVFAIL error)

• Switching on DNSSEC (by placing a DS record in the parent zone) can be both exciting and frightening
  • Even with good preparation and testing on the authoritative server side, you can never sure what brokenness is out there in the Internet on the resolve side (misbehaving Firewalls, broken DNS load balancer, weird endpoint security, …)
• The "dry-run" IETF draft proposes a way to signal a DNSSEC test by using a special "dry-run" flag in the DS record placed into the parent zone
• DNS resolver supporting this extension that see the "dry-run" flag will try to validate the DNSSEC signed zone, but will not fail to resolve the zone but treat it insecure
  • All DNSSEC validation errors will be reported back to the operator of the DNS zone using the "DNS error reporting" function (see chapter above).
  • The idea is to first deploy a new DNSSEC signed zone in this "dry-run" mode, collect error messages (and positive feedback) over a period of time, and then remove the "dry-run" flag from the DS record to convert the zone into a validating DNSSEC zone
  • The current proposal is to have the flag in the digest/hash-algorithm field of the DS record
• A client can indicate (possibly via an EDNS flag) towards a DNSSEC validating resolver to have a "dry run" DNSSEC zone validated (with normal DNSSEC error reporting = SERVFAIL and extended DNS error)
• DNS resolver that does not support the "dry run" DNSSEC DS record will ignore it and will treat the zone as insecure (no DNSSEC validation)
• The "dry run" DNSSEC DS record can also be used to test drive a DNSSEC KSK key rollover without risks to break the zone
• Draft "dry run DNSSEC" (A draft is not yet a standard, and might never be): https://datatracker.ietf.org/doc/draft-yorgos-dnsop-dry-run-dnssec/
• This draft has not yet been implemented in production DNS server software
• This draft has not yet been adopted by the IETF working DNSOP working group, but people at the IETF liked the idea

• A new option manual-mode has been added to dnssec-policy.
  • The intended use is that if it is enabled, it will not automatically move to the next state transition, but instead the transition is logged.
  • Only after manual confirmation with rndc dnssec -step the transition is made
• This helps with migrations from older auto-dnssec maintain; configurations to DNSSEC policy based configurations
  • The administrator can check every step of the transition before it becomes active
• manual-mode DNSSEC will be availble in BIND 9.22.0 (Q2/Q3 2026)