DNS & BIND 9 DNSSEC Workshop

• This guide and the slides can be accessed online at https://dnssec.defaultroutes.org
• PDF Version for download: PDF-File
• Please replace the wildcard characters XX in the guide with your participant number. You can find your participant number in the table on this page

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

• Login to the DNS Resolver machine dnsr.zXX.dane.onl (Username user, password dnssec-2023)
• Become user root with sudo bash
• Install the BIND 9 DNS Server and the DNS lookup tools

  apt install bind9 dnsutils
  

• On Debian Linux, the BIND 9 DNS Server will automatically start. The BIND 9 service name is named (Name Daemon)

  systemctl status named
  

• By default, BIND 9 is configured as an DNSSEC validating full-resolver
• Try to answer the questions below by sending queries to the local BIND 9 DNS Resolver:
  • Is the domain dnssec.works DNSSEC secured?

    dig @localhost dnssec.works SOA
    

  • What is the negative Time To Live (TTL) value for negative answers from the zone dnssec.works?

    dig @localhost xyz.dnssec.works
    

  • What is the effective negative TTL for negative answers from the zone dnssec.works?
  • Does the domain name www.dnssec.works have an IPv4 and/or an IPv6 address?

    dig @localhost www.dnssec.works A
    dig @localhost www.dnssec.works AAAA
    

  • Does the domain name dnssec.works have a HTTPS record?

    dig @localhost dnssec.works HTTPS
    

  • Does the domain name dnssec.works does have a CAA record?

    dig @localhost dnssec.works CAA
    

• 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) https://tools.ietf.org/html/rfc7858
  • RFC 8484 "DNS Queries over HTTPS (DoH)" (DNS-over-HTTPS) https://tools.ietf.org/html/rfc8484
• 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.6 and up: Authoritative server and validating resolver
  • NSD from NLnet Labs: Fast authoritative server
  • Unbound from NLnet Labs :Fast and secure validating resolver
  • Windows 2012 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
    

  

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

• 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";
     dnssec-enable yes;
  };
  

• 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 zoneNNN.dnslab.org
  Generating key pair.........++++ ............................
  KzoneNNN.dnslab.org.+008+16239
  
  % more KzoneNNN.dnslab.org.+008+16239.key
  ; This is a zone-signing key, keyid 16239, for zoneNNN.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)
  zoneNNN.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 zoneNNN.dnslab.org
  Generating key pair...................................................
  KzoneNNN.dnslab.org.+008+04351
  
  % more KzoneNNN.dnslab.org.+008+04351.key
  ; This is a key-signing key, keyid 4351, for zoneNNN.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)
  zoneNNN.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 zoneNNN.dnslab.org.
  @             IN SOA serverNNN.dnslab.org.  hostmaster.zoneNNN.dnslab.org. (
                       1001 ; serial
                       1d   ; refreh
                       2h   ; retry
                       4w   ; expire
                       30m  ; negTTL
                    )
                IN NS serverNNN.dnslab.org.
                IN MX 10 mail.zoneNNN.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 KzoneNNN.dnslab.org.+008+*.key >> zoneNNN.dnslab.org
  

• Sign the zone file

  % dnssec-signzone -o zoneNNN.dnslab.org \
  	-k KzoneNNN.dnslab.org.+008+04351.private \
          zoneNNN.dnslab.org \
  	KzoneNNN.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
  zoneNNN.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

  zoneNNN.dnslab.org.      3600    IN SOA  serverNNN.dnslab.org. hostmaster.zoneNNN.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 zoneNNN.dnslab.org.
                                           jT+M9IhjViHkoLnC5/y+MaHYoxpcoyHvif7H
                                           sFESQfk7JBx654zb7OZ2LVxsmMnGtiqxkLlD
                                           l5nJtBJuWXMufPLks+qQb42YjdGgU6vf5WOI
                                           GkTyTMf0ZcNc3ULZZCMG/Vkf3Pak4O6He+cB
                                           xvdbDzOOaLcQqlKH8xY/ylmHawJTm8Mmcbb/
                                           1tL3B/Iv0SI9Lv+F/g+ajaA7fd3bcr0Vueol
                                           gOTJ3OZkIEoQFROrn5UMQ/fvbY7Go2TjDT7I
                                           GYMu )
                           3600    NS      serverNNN.dnslab.org.
                           3600    RRSIG   NS 8 3 3600 (
                                           20160303114542 20160202114542 16239 zoneNNN.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 zoneNNN.dnslab.org*
       23     133    1554 zoneNNN.dnslab.org
      130     314    5178 zoneNNN.dnslab.org.signed
      153     447    6732 total
  

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

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

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

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

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

  % rndc reload zoneNNN.dnslab.org
  

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

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

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

• 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 "/etc/bind";
      key-directory "/etc/bind/keys";
      dnssec-enable yes;
  };
  

• 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 /etc/bind/keys inline.zXX.dane.onl
  % dnssec-keygen -a RSASHA256 -b 2048 -K /etc/bind/keys -f KSK inline.zXX.dane.onl
  

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

  zone "inline.zXX.dane.onl" IN {
      type primary;
      file "inline.zXX.dane.onl";
      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 inline.zXX.dane.onl
  

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

  % tail /etc/bind/named.log
  31-Jan-2016 21:58:37.945 zone inline.zXX.dane.onl/IN (unsigned): loaded serial 1002
  31-Jan-2016 21:58:37.946 zone inline.zXX.dane.onl/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 inline.zXX.dane.onl
  % named-compilezone -f RAW \
      -o inline.zXX.dane.onl.txt \
         inline.zXX.dane.onl inline.zXX.dane.onl.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

• There is no AD Flag on queries for inline.zXX.dane.onl. There are no answers as well!
  • Delegation NS records and the DS record is missing from the parent zone zXX.dane.onl
• Edit the file zonefile.db and add a delegation NS record for inline.zXX.dane.onl and the DS record for inline.zXX.dane.onl

  inline.zXX.dane.onl.   IN NS authXX.dane.onl.
  

• Sign the parent zone zXX.dane.onl (manually signed) with dnssec-signzone (same command as many times before)
• Reload the new signed parent zone into the BIND 9 name-server, check for the AD flag on queries for inline.zXX.dane.onl

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

• Example of zone walking:

$ ldns-walk isc.org

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

• To use NSEC3 instead of NSEC for DNSSEC signing with a dynamic DNS zone an NSEC3PARAM record must exist in the zone before the zone is signed. For inline-signing use rndc

• Edit the zone file

% $EDITOR /etc/bind/inline.zXX.dane.onl

• Add the NSEC3PARAM record

inline.zXX.dane.onl. 0  IN NSEC3PARAM 1 0 0 -

• reload and resign the zone

% rndc reload
% rndc sign inline.zXX.dane.onl

• Add a NSEC3PARAM record to the zone

% nsupdate -l
> add dynamic.zXX.dane.onl. 0  IN NSEC3PARAM 1 0 0 -
> send
> quit

• Create the DNSSEC keys and sign the zone

% rndc sign dynamic.zXX.dane.onl

• An already signed dynamic zone can be switched to NSEC3 by using the rndc sign command

% rndc signing -nsec3param 1 0 0 - inline.zXX.dane.onl

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

% rndc signing -nsec3param none inline.zXX.dane.onl

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

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

• Single CSK
  • 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

zone "example.net" {
    dnssec-policy "one";
};

dnssec-policy "one" {
    keys {
        ksk lifetime 365d algorithm rsasha256 2048;
        zsk lifetime 60d  algorithm rsasha256 1024;
        csk lifetime P6M2T12H3M15S algorithm 13;
    };
};

• 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>;
};

• BIND 9.16/9.18 führt eine neue (bessere) Automatisierung der DNSSEC-Signierung von DNS-Zonen ein: während in den älteren BIND 9 Versionen die Key-Rollover mittels der Meta-Daten auf den Schlüssel-Dateien automatisiert werden konnten, können die Key-Rollover nun innerhalb der BIND 9 Konfiguration in einer KASP (Key-and-Signing-Policy) definiert werden. Der BIND 9.18 führt ggf. Key-Rollover automatisiert durch.
• Zonen, welche schon vor BIND 9.16 oder BIND 9.18 mit DNSSEC abgesichert waren sollen auf das neue KASP System migriert werden, da die alte DNSSEC-Automatisierung in BIND 9 abgekündigt ist und in einer zukünftigen Version von BIND 9 (9.19-dev, 9.20-release) nicht mehr verfügbar sein wird.
• Für eine erfolgreiche Migration ist es erforderlich, eine DNSSEC-KASP zu definieren, welche zu den bestehenden DNSSEC-Schlüsseln in der Zone passt (Algorithmus, Anzahl Schlüssel = CSK oder KSK/ZSK).
  • Erkennt der BIND 9 beim Laden der Zone ein Differenz zwischen den existierenden Schlüsseln und der neuen Policy, so wird BIND 9 die bestehenden Schlüssel nicht mehr benutzen und stattdessen neue Schlüssel erstellen und sofort die Zone mit den neuen Schlüsseln signieren. Dies kann zu einem Total-Ausfall der Zone führen, da der DS-Record in der Eltern-Zone nicht zu KSK/CSK der Zone passt.
  • Bei der Migration auf eine KASP-Konfiguration sollte die Lebensdauer der Schlüssel mit "unlimited" angegeben werden. Nach der erfolgreichen Migration kann die KASP-Konfiguration angepasst und die Lebensdauer der Schlüssel begrenzt werden.
  • Es ist sinnvoll, eine Migration von einer pre-KASP Konfiguration einer Zone auf eine Zone mit DNSSEC-KASP and einer Test-Zone zu üben.
  • Bei einer erfolgreichen Migration auf eine KASP-Konfiguration übernimmt der BIND 9 die bestehenden DNSSEC-Schlüssel und signiert die Zone weiterhin mit diesen Schlüsseln.
  • Werden neuen Schlüssel erzeugt und für die Signierung verwendet, so war die Migration nicht erfolgreich.
  • Bei der Benutzung eines hidden-primary DNS-Servers, sollte für die Aktivierung der KASP-Konfiguration die Kommunikation zwischen den aktiven Auth-Servern und dem hidden-primary unterbrochen werden, bis die erfolgreiche Migration bestätigt ist (in der Regel direkt nach dem Laden der neuen Konfiguration sichtbar).
  • Bei der Benutzung einer Infrastruktur ohne hidden-primary (der Primary ist aktiver DNS-Server in der Delegation) kann der Primary-Server temporär in einen "hidden-primary" umgewandelt werden (z.B. durch ein Block von UDP/TCP Port 53 in der Firewall). Der oder die restlichen DNS-Server werden die bestehende DNSSEC-Zone ohne Unterbrechung weiter ausliefern, bis die erfolgreiche Migration bestätigt ist und die Blockade in der Firewall aufgehoben wurde.
• Beispiel einer Pre-KASP-BIND 9 DNSSEC-Konfiguration. Die Schlüssel (ZSK/KSK) wurden manuell mit dnssec-keygen mit dem Algorithmus RSASHA256 erstellt:

  options {
     directory "/var/named";
     key-directory "keys";
  };
  
  zone "example.com" IN {
    type primary;
    file "example.com";
    auto-dnssec maintain;
    inline-signing yes;
  };
  

• Beispiel einer KASP BIND 9 DNSSEC-Konfiguration für diese Zone:

  dnssec-policy "base-dnssec" {
     keys {
       ksk lifetime unlimited algorithm RSASHA256;
       zsk lifetime unlimited algorithm RSASHA256;
     };
  };
  
  options {
     directory "/var/named";
     key-directory "keys";
  };
  
  zone "example.com" IN {
    type primary;
    file "example.com";
    dnssec-policy "base-dnssec";
    inline-signing yes;
  };
  

• Eine produktive KASP-Konfiguration mit ZSK-Rollover (aber keinem automatischem KSK-Rollover):

dnssec-policy "DNSSEC-ZSK-ROLL" {
       dnskey-ttl 60;
       keys { ksk lifetime unlimited algorithm ECDSAP256SHA256;
              zsk lifetime P30D      algorithm ECDSAP256SHA256;
            };
       max-zone-ttl 3600;
       publish-safety 1h;
       purge-keys P90D;
       retire-safety 1h;
       signatures-refresh 5d;
       signatures-validity 14d;
       signatures-validity-dnskey 14d;
       zone-propagation-delay 300;
 };

 zone "example.de" {
     type primary;
     inline-signing yes;
     dnssec-policy "DNSSEC-ZSK-ROLL";
     file "primary/example.de";
};

• Beispiel einer KASP BIND 9 DNSSEC-Konfiguration mit automatischem ZSK/KSK Rollover mittels CDS/CDNSKEY (Schweiz):

parental-agents "switch" {
   130.59.31.41;
   130.59.31.43;
   194.0.25.39;
   194.0.17.1;
   194.146.106.10;
   2001:620:0:ff::56;
   2001:620:0:ff::58;
   2001:678:20::39;
   2001:678:3::1;
   2001:67c:1010:2::53;
};

dnssec-policy "DNSSEC-AUTO" {
    keys {
        ksk lifetime P90D  algorithm ecdsap256sha256;
        zsk lifetime P45D  algorithm ecdsap256sha256;
    };
    max-zone-ttl 3600;
    parent-ds-ttl 600;
    parent-propagation-delay 2h;
    publish-safety 7d;
    retire-safety 7d;
    signatures-refresh 5d;
    signatures-validity 15d;
    signatures-validity-dnskey 15d;
    zone-propagation-delay 2h;
};

zone "example.ch" {
     type primary;
     allow-update { key dns-update; };
     allow-transfer { secondaries; };
     dnssec-policy "DNSSEC-AUTO";
     parental-agents {
        "switch";
     };
     file "primary/example.ch";
};

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

  

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)

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.