DNS & BIND - Betrieb und Sicherheit (Linuxhotel)

• The Zonefile (your zone will have different IPv4 and IPv6 addresses)

$TTL 60
@          IN SOA       nsNNNa.dnslab.org. hostmaster.zoneNNN.dnslab.org. 1001 1h 30m 41d 30
           IN NS        nsNNNa.dnslab.org.
           IN NS        nsNNNb.dnslab.org.
           IN MX        10 primary
           IN MX        20 secondary
primary    IN A         192.0.2.53
           IN AAAA      2001:db8:100::53
secondary  IN A         192.0.2.153
           IN AAAA      2001:db8:200::53
text       IN TXT       "DNS Leap Ahead!"

• The primary zone configuration on nsNNNa

zone "zoneNNN.dnslab.org" {
    type primary;
    file "zoneNNN.dnslab.org";
};

• Starting with BIND 9.20.0, outgoing zone transfers are no longer enabled by default. An explicit allow-transfer ACL must now be set at the zone, view, or options level to enable outgoing transfers.
  • Here we use a simple "allow all" ACL (restoring the old, pre-BIND-9.20 behavior. We will learn later in the course how to secure zone transfer with cryptographic keys (TSIG).
• The primary zone on nsNNNa

zone "zoneNNN.dnslab.org" {
    type primary;
    file "zoneNNN.dnslab.org";
    allow-transfer { any; };
};

• The secondary zone on nsNNNb

zone "zoneNNN.dnslab.org" {
    type secondary;
    primaries { <ipv6-address-of-primary>; <ipv4-address-of-primary>; };
    file "zoneNNN.dnslab.org";
};

• A Pre-Shared Key (PSK) could be used to encrypt a message.
• If it decrypts, confidentially, integrity, and authenticity are assured.
• However, confidentiality was not a design goal (of DNSSEC).
• Encrypting everything is computationally expensive.
• The alternative is more complicated but less expensive.

• Creating a hash of the message is a light-weight alternative to encrypting everything.
  • A hash is also known as a hash value, a message digest (MD) or a fingerprint.
• The sender runs a cryptographic hashing algorithm on the message to produce a fixed-length hash.
  • The message and hash are sent over an insecure path.
• As the sender did, the receiver hashes the message.
• If the hashes match, the message was not modified. Message integrity is proven.
• However, the receiver does not know if the message and hash were both replaced: Message authenticity is unknown.
• Confidentiality is not provided.

• Hashing, with a symmetric key added to the input, efficiently provides integrity and authenticity.
  • There is no confidentiality.
  • A MAC is a fingerprint (MD, hash) created with the message and a PSK as input.
  • The MAC described here, is a keyed HMAC (Hash-based message authentication code).
    • It is used by DNS.

• Although HMACs efficiently assure both the sender's authenticity, and the message's integrity, not all applications can use (pre)shared keys.
  • "Am I really seeing the website mybank.example?"
  • "Is the email I'm reading really from Edward Snowden?"
  • "Is this RRSet actually for theguardian.com?"

• PK encryption is used for privacy, to assure only the intended receiver can read a message.
  • Data integrity is also assured.
  • Used in DNS-over-TLS and DNS-over-HTTPS
• PK encryption is used for authenticity, assuring the recipient, that the message came from a specific sender.
  • This is known as signing a message.
  • Data integrity is also assured.
  • Used in DNSSEC, as well in DNS-over-TLS and DNS-over-HTTPS

• To assure authenticity, a sender encrypts a message with her private key.
  • Anyone decrypting the message with the public key is assured it came from the holder of the private key.
• The message is encrypted, but there is no privacy.

• For efficiency, the message itself is not encrypted.
  • The message is first hashed to create a fingerprint.
  • The fingerprint is encrypted.
  • The signed fingerprint is a digital signature (aka encrypted fingerprint and encrypted hash).

• 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

• The RFC 9567 - DNS Error Reporting describes a way for DNS resolver software to report DNS name resolution error conditions back to the operator of the authoritative DNS zone
• This function is similar to DMARC reporting in email
• The errors reported are based on "Extended DNS Errors (EDE, RFC 8914)"
• The reporting is done within the DNS protocol
  • Authoritative DNS server can opt-in for error reports using an EDNS option
  • Authoritative DNS Server can select to receive only error conditions or also positive feedback (on successful name resolution)
  • To report an error, the reporting resolver encodes the error report in the QNAME of the reporting query. The reporting resolver builds this QNAME by concatenating the _er label, the extended error code, the QTYPE and the QNAME that resulted in failure, the label _er again, and the reporting agent domain
  • The resulting domain name (QNAME) is then used to query for a NULL resource record, which will report back the error condition
  • The reporting agent domain is usually different from a production domain. The reporting agent domain should not be DNSSEC signed, as only the queries are of use and the responses do not need to be secured
  • The authoritative DNS server will respond with a NODATA/NXRRSET response, which will be cached by the resolver (the negative TTL on this response will set the error report interval, as new reports for the same error will only be send once the TTL has expired)
• Example (taken from the RFC):
  • The domain broken.test is hosted on a set of authoritative servers. One of these serves a stale version. This authoritative server has a severity level of 1 and a reporting agent configured: a01.reporting-agent.example.
  • The reporting resolver is unable to validate the broken.test RRSet for type A, due to an RRSIG record with an expired signature.
  • The reporting resolver constructs the QNAME _er.7.1.broken.test._er.a01.reporting-agent.example and resolves it. This QNAME indicates extended DNS error 7 occurred while trying to validate broken.test type 1 (A) record.
  • After this query is received at one of the authoritative servers for the reporting agent domain (a01.reporting-agent.example), the reporting agent (the operators of the authoritative server for a01.reporting-agent.example) determines that the authoritative server for the broken.test zone suffers from an expired signature record (extended error 7) for type A for the domain name broken.test. The reporting agent can contact the operators of broken.test to fix the issue.
  • Error Reporting is currently available in Unbound (Version 1.23 - April 2025) and will be available in the upcoming BIND 9.22.x versions (Q1/Q2 2026).

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

• These are the steps to manually sign a zone for BIND 9
• For older BIND 9 versions, enable DNSSEC in the named.conf configuration file

  options {
     directory "/var/named";
  };
  

• Create a Zone-Signing-Key (ZSK)
  • This requires good real entropy (randomness) in the operating system. If the key creation process takes too long (more than a minute for a key), there might not be enough entropy in the system. In such case a hardware random number generator or a software entropy gathering daemon (such as haveged) can help

  % dnssec-keygen -a RSASHA256 -b 1536 zoneNN.dnslab.org
  Generating key pair.........++++ ............................
  KzoneNN.dnslab.org.+008+16239
  
  % more KzoneNN.dnslab.org.+008+16239.key
  ; This is a zone-signing key, keyid 16239, for zoneNN.dnslab.org.
  ; Created: 20160202121320 (Tue Feb  2 13:13:20 2016)
  ; Publish: 20160202121320 (Tue Feb  2 13:13:20 2016)
  ; Activate: 20160202121320 (Tue Feb  2 13:13:20 2016)
  zoneNN.dnslab.org. IN DNSKEY 256 3 8 AwEAAc1xFtt40wPEx4TVB7h8Ac7HvMZuF1LIqESU/0HUUzDT2rkujMdL
  z0fgJJQVStYIbb1fXN0/PmKayEpj5ScbT7WU9Bef6b49uG1PwhsaftRr
  /udr3DEA6MTEdRqkl8K+E3P9hFj4XKxus45MYVSPaXZg3TcIQK3xpXC8
  sKISny43cQaJpm12oBtKsANlA25KRJC8soP1s/GqLSnArWDMN/YGqvs0
  QECulpm2Nh1uULZfzwga8515xizyx5yAl/sgWQ==
  

• Generate a Key-Signing-Key with the same DNSSEC algorithm used for the ZSK

  % dnssec-keygen -a RSASHA256 -b 2048 -f KSK zoneNN.dnslab.org
  Generating key pair...................................................
  KzoneNN.dnslab.org.+008+04351
  
  % more KzoneNN.dnslab.org.+008+04351.key
  ; This is a key-signing key, keyid 4351, for zoneNN.dnslab.org.
  ; Created: 20160202121714 (Tue Feb  2 13:17:14 2016)
  ; Publish: 20160202121714 (Tue Feb  2 13:17:14 2016)
  ; Activate: 20160202121714 (Tue Feb  2 13:17:14 2016)
  zoneNN.dnslab.org. IN DNSKEY 257 3 8 AwEAAcmn/QkiCne922gBBBuJJOnq9jnG2yYbB10zBS2SgUCUxlZfM2ja
  PAyubB2V+QhFsKf0VKUsVGl28JWAMcG1NGitj+nna4sGwvmeumj70DbG
  ZzynwcFknEZG1Swn2bM/OFmlMS2WV3luzDYKnLeZgvN5geB6ZetONlpP
  H9am3MRmExNIxoFb5NEcUlCzxSUI5GzjPZtGmCtDoNKrGE5nsssCgrjw
  ec6hbeXLOjP9JiQ3egF3+PJHLUOjuqXKwSofHw4jV4Rqc3eP+uAHk5Wp
  iH/BNW7c7lJ9IP+jZYZ3dp3SkO2qU8BOVV4fcm1L+IVcA9jwuuPaOV53
  j9L8fCTL/Uk=
  

• This is the content of the unsigned DNS zone

  $TTL 3600
  $ORIGIN zoneNN.dnslab.org.
  @             IN SOA serverNN.dnslab.org.  hostmaster.zoneNN.dnslab.org. (
                       1001 ; serial
                       1d   ; refreh
                       2h   ; retry
                       4w   ; expire
                       30m  ; negTTL
                    )
                IN NS serverNN.dnslab.org.
                IN MX 10 mail.zoneNN.dnslab.org.
  www           IN A  192.168.53.199
  mail          IN A  192.168.53.199
  

• Add the public part of the ZSK and KSK to the zone (be careful with the shell redirection!) or use master file $INCLUDE syntax.

  % cat KzoneNN.dnslab.org.+008+*.key >> zoneNN.dnslab.org
  

• Sign the zone file

  % dnssec-signzone -o zoneNN.dnslab.org \
          -k KzoneNN.dnslab.org.+008+04351.private \
          zoneNN.dnslab.org \
  	 KzoneNN.dnslab.org.+008+16239.private
  Verifying the zone using the following algorithms: RSASHA256.
  Zone fully signed:
  Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                        ZSKs: 1 active, 0 stand-by, 0 revoked
  zoneNN.dnslab.org.signed
  

• Zone signing tool syntax:

  dnssec-signzone -o <origin> -k <KSK-private> <zone-file> <ZSK-private>
  

  • If the error message dnssec-signzone: fatal: SOA is not signed (keys offline or inactive?) is displayed, then the KSK and ZSK have been given in the wrong order
  • Additional options for dnssec-signzone
    • -j sec Jitter, variation in seconds of the signature validity
    • -M maxttl - specifies the maximum allowed TTL in the signed zone. Higher TTL values will be capped to this number.
    • -s starttime - start of validity of the signatures
    • -e endtime - expire time of the signatures
    • -N SOA-format - format of the SOA serial number
      • keep do not modify the current SOA serial number
      • increment increment the current SOA by one
      • date set the SOA serial number to today's date in YYYYMMDDnn format
      • unixtime use the Unixtime (seconds since 1.1.1970) as the SOA serial
    • -x only create one signature for the DNSKEY record set (using the KSK)
    • -n numcpus use this amount of CPU cores for signing
    • -t print performance statistics after signing
• The signed zone is stored in a new file with the name of the original zone file and the extension .signed

  zoneNN.dnslab.org.      3600    IN SOA  serverNN.dnslab.org. hostmaster.zoneNN.dnslab.org. (
                                           1001       ; serial
                                           86400      ; refresh (1 day)
                                           7200       ; retry (2 hours)
                                           2419200    ; expire (4 weeks)
                                           1800       ; minimum (30 minutes)
                                           )
                           3600    RRSIG   SOA 8 3 3600 (
                                           20160303114542 20160202114542 16239 zoneNN.dnslab.org.
                                           jT+M9IhjViHkoLnC5/y+MaHYoxpcoyHvif7H
                                           sFESQfk7JBx654zb7OZ2LVxsmMnGtiqxkLlD
                                           l5nJtBJuWXMufPLks+qQb42YjdGgU6vf5WOI
                                           GkTyTMf0ZcNc3ULZZCMG/Vkf3Pak4O6He+cB
                                           xvdbDzOOaLcQqlKH8xY/ylmHawJTm8Mmcbb/
                                           1tL3B/Iv0SI9Lv+F/g+ajaA7fd3bcr0Vueol
                                           gOTJ3OZkIEoQFROrn5UMQ/fvbY7Go2TjDT7I
                                           GYMu )
                           3600    NS      serverNN.dnslab.org.
                           3600    RRSIG   NS 8 3 3600 (
                                           20160303114542 20160202114542 16239 zoneNN.dnslab.org.
                                           ColPExa9EdSA1Nt1DsEtX5qjYzNWA8vUl8ef
                                           oJG409V6BX4JJsK7RJGCGlmqDIA7HO1IQKug
                                           64N+fD/IuVjqHsPxc/YtP1sdnnLjYK0rHgG7
                                           kMMkoqU7Ta/l/laKKd3jcI/kh66dOsTwYrEC
                                           aykvfzYCnVj/rxwEomu2aTbPh/Nt7V2OEXDT
                                           EqlmpS34yQ3LvYfnSTTipLYZNS/2kL7NRuEo
                                           1gId5PD/IMAKSpTqfilW1bQUf+CYJF/CGgF5
                                           KRIx )
  

• Compare the file sizes. The signed zone is much larger

  % wc zoneNN.dnslab.org*
       23     133    1554 zoneNN.dnslab.org
      130     314    5178 zoneNN.dnslab.org.signed
      153     447    6732 total
  

• Adjust the zone definition in named.conf to load the new signed zone

  zone "zoneNN.dnslab.org" IN {
      type primary;
      file "zoneNN.dnslab.org.signed";
  };
  

• Check the new BIND 9 configuration. The output should indicate that the zone is now DNSSEC signed

  % named-checkconf -z
  zone zoneNN.dnslab.org/IN: loaded serial 1001 (DNSSEC signed)
  

• Load the DNSSEC signed zone into the BIND 9 DNS server

  % rndc reload zoneNN.dnslab.org
  

• Send the DS record for the KSK to the operator of the parent zone

  % cat dsset-zoneNN.dnslab.org.
  zoneNN.dnslab.org.  IN DS 16239 8 1 C0213 ... 0373A
  zoneNN.dnslab.org.  IN DS 16239 8 2 EAC59 ... E694690565680E3F6D201 E2650EAE
  

• 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

• Below is an example of an custom DNSSEC policy in BIND 9.16+ named "one"

  dnssec-policy "one" {
      keys {
          ksk lifetime 365d algorithm rsasha256 4096;
          zsk lifetime 60d  algorithm rsasha256 1024;
      };
  };
  
  zone "example.net" {
      file "example.net.zone";
      dnssec-policy "one";
  };
  

  • keys specify roles instead of specific keys
  • lifetime specifies duration or unlimited
  • algorithm uses mnemonic or number

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.

• To use 'inline-signing', BIND 9 needs to be able to find the DNSSEC key files. A key-directory should be specified globally (for all zones) or in each DNSSEC zone configuration

  options {
      directory "/var/named";
      key-directory "/var/named/keys";
  };
  

• The new configuration should be checked and then loaded into the BIND 9 DNS server

  % named-checkconf -z
  % rndc reconfig
  

• The next step is to create the ZSK and KSK for the zone
  • the parameter -K specifies the directory in which the keys will be created

  % dnssec-keygen -a RSASHA256 -b 1536 -K /var/named/keys inlineNN.dnslab.org
  % dnssec-keygen -a RSASHA256 -b 2048 -K /var/named/keys -f KSK inlineNN.dnslab.org
  

• Inline signing is activated in the zone definition with inline-signing yes;

  zone "inlineNN.dnslab.org" IN {
      type primary;
      file "inlineNN.dnslab.org";
      inline-signing yes;
      auto-dnssec maintain;
  };
  

• Check the configuration and re-load BIND 9, then sign the zone

  % named-checkconf -z
  % rndc reconfig
  % rndc sign inlineNN.dnslab.org
  

• As rndc sign does not report errors, the log files should always be checked for error messages (missing keys, permission issues)

  % tail /var/named/named.log
  31-Jan-2016 21:58:37.945 zone inlineNN.dnslab.org/IN (unsigned): loaded serial 1002
  31-Jan-2016 21:58:37.946 zone inlineNN.dnslab.org/IN (signed): loaded serial 1003 (DNSSEC signed)
  

• The content of the signed zone will be written into a file with the same name as the original zone file but with the extension .signed. The file content is in binary "raw" format
• In addition to the signed file BIND 9 will create a journal file with the extension .jnl (for IXFR zone transfers) and a backup of the journal with the extension .jbk
• The original zone file will not be changed!
• The DNSSEC signing will take place in memory and the signed zone will be written to disk no later than 15 minutes after the signing has taken place
• With rndc sync the new signed zone data can be forced to disk immediately
• The signed zone file in "raw" format can be converted to readable text format with named-compilezone

  % rndc sync inlineNN.dnslab.org
  % named-compilezone -f RAW \
      -o inlineNN.dnslab.org.txt \
         inlineNN.dnslab.org inlineNN.dnslab.org.signed
  

• Changes to the zone file can now be done as normal to the unsigned zone file.
  • After each change the SOA serial needs to be incremented (also as normal)
  • When signing the zone, BIND 9 will also increment the SOA serial. For inline signed zones, it is normal that the SOA serial returned by the DNS server is higher than the SOA serial in the zone file

• 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)

• Edit the zone file

% $EDITOR /var/named/inline.zoneNN.dnslab.org

• Add the NSEC3PARAM record

inline.zoneNN.dnslab.org. 0  IN NSEC3PARAM 1 0 0 -

• reload and resign the zone

% rndc reload
% rndc sign inline.zoneNN.dnslab.org

• Add a NSEC3PARAM record to the zone

% nsupdate -l
> add dynamic.zoneNN.dnslab.org. 0  IN NSEC3PARAM 1 0 0 -
> send
> quit

• Create the DNSSEC keys and sign the zone

% rndc sign dynamic.zoneNN.dnslab.org

• An already signed inline-signed zone can be switched to NSEC3 by using the rndc signing command. This is the only supported mech- anism for using NSEC3 with inline-signing zones. Parameters are specified in the same format as an NSEC3PARAM resource record.

% rndc signing -nsec3param 1 0 0 - inline.zoneNN.dnslab.org

• It is possible to switch back to NSEC with a similar command

% rndc signing -nsec3param none inline.zoneNN.dnslab.org

• There are no timing issues when switching between NSEC and NSEC3

$ dig zoneNN.dnslab.org DNSKEY +dnssec +multi

$ dig inline.zoneNN.dnslab.org DNSKEY +dnssec +multi

$ dig dynamic.zoneNN.dnslab.org DNSKEY +dnssec +multi

• With manual signing, only sign the DNSKEY-RRSet with a signature from the KSK (and not, as done by default with BIND 9 signing tools, with KSK and ZSK)

% dnssec-signzone -x -o <zone-name> -k <KSK-private-file> <zone-file> \
    <ZSK-private-file>

• To only sign with KSK when using dynamic zones or inline-signing, use the following setting in the BIND 9 configuration file /etc/named.conf

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

• 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

• A DNSSEC key rollover can be automated with BIND 9 since BIND 9.7.2 and with the configuration parameter auto-dnssec maintain in the zone definition
• With BIND 9.8.0 and later the command dnssec-keygen can create a successor key for an existing DNSSEC key
• The following time definitions are possible on DNSSEC keys with BIND 9
  • Publish - time at which the key will be imported into the zone and will be visible
  • Activation - time at which the key will be used to create signatures in the zone
  • Retirement/Inactive - time at which the key will not be used anymore to create signatures in the zone
  • Deletion - time at which the key will be removed from the zone
  • Revocation - time at which the key is being revoked and the revoke flag has been set on the key (KSK only)
• These timing values can be set on creation time with dnssec-keygen or later modified with dnssec-setime
• The format for all timing values is YYYYMMDD or YYYYMMDDhhmmss
• Timing values can also be specified relative to the current time, the offset can be specified as +X (positive offset) or -X (negative offset) and a suffix. Example: -P +10d (10 days from now)
• Possible suffixes for relative time values
  • y - years
  • mo - month
  • d - days
  • h - hours
  • mi - minutes
• For these timing values, years always have 365 days and a month is always 30 days
• The following parameters are used to set the timing values on keys (use with dnssec-keygen and dnssec-settime):
  • -P <Date/Offset> - publish time of the key
  • -A <Date/Offset> - activation time of the key
  • -R <Date/Offset> - Revoke time of the key
  • -I <Date/Offset> - Retire/Inactivation time of the key
  • -D <Date/Offset> - Deletion time of the key

• When creating a new key for an already signed zone, the parameter -S for the command dnssec-keygen can be used to specify the current key for the zone
  • dnssec-keygen will then create a successor key that matches the current key (same key algorithm, same key length)
  • The activation time of the new key will be set to the delete time event of the current key
    • The current key must therefore have a deletion event set
• The dnssec-keygen parameter -i is used to define the pre-publication time of the new key
  • The publication time will be set to "activation event minus pre-publication". The time duration of pre-publication must be higher than the TTL of the DNSKEY DNS RRset, so that the new key will be in the caches once it will become active and starts creating signatures

• It is possible to fully automate a ZSK rollover with a script and using the BIND 9 timing values on DNSSEC keys
  • the script should be executed periodically (per systemd timer or cron-job)
• A KSK rollover can be automated if the registrar offers an API to submit the DS record to the parent zone operator, or through RFC 7344/8087 (see below)

• Set the retire and delete times on the current key
• Create the successor key with pre-publish and activation time events

• 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)