Key Knowledge Areas:

  • Understand the concepts of DNS, zones and resource records
  • Understand DNSSEC, including key signing keys, zone signing keys and relevant DNS records such as DS, DNSKEY, RRSIG, NSEC, NSEC3 and NSEC3PARAM
  • Configure and troubleshoot BIND as an authoritative name server serving DNSSEC secured zones
  • Manage DNSSEC signed zones, including key generation, key rollover and re-signing of zones
  • Configure BIND as an recursive name server that performs DNSSEC validation on behalf of its clients
  • Understand CAA and DANE, including relevant DNS records such as CAA and TLSA
  • Use CAA and DANE to publish X.509 certificate and certificate authority information in DNS
  • Use TSIG for secure communication with BIND
  • Awareness of DNS over TLS and DNS over HTTPS
  • Awareness of Multicast DNS

Partial list of the used files, terms and utilities:

  • named.conf
  • dnssec-keygen
  • dnssec-signzone
  • dnssec-settime
  • dnssec-dsfromkey
  • rndc (including relevant subcommands)
  • dig
  • delv
  • openssl (including relevant subcommands)

Terms

CAA, DS, DNSKEY, NSEC, NSEC3, NSEC3PARAM, RRSIG, and TLSA records

list of DNS record types

  • CAA: DNS Certification Authority Authorization, constraining acceptable CAs for a host/domain
  • TLSA: A record for DNS-based Authentication of Named Entities (DANE). “The TLSA DNS resource record is used to associate a TLS server certificate or public key with the domain name where the record is found, thus forming a ‘TLSA certificate association’” (RFC 6698).

The TLSA RR (Resource Record) for a service is located at a DNS name that specifies certificate constraints should be applied for the services at a certain TCP or UDP port. At least one of the TLSA RRs must provide a validation (path) for the certificate offered by the service at the specified address.

Example:

     IP
     pro-                             se-      certificate
IP   to-                       record lec-     association
port col host                  type   tor      data (hex)
 __  ___ _____________________ ____   _   ________________
_25._tcp.somehost.example.net. TLSA 3 1 1 0123456789ABCDEF
                                    -   -
                    certificate usage   matching type

certificate usage:

  • 0: The certificate provided when establishing TLS must be issued by the listed root-CA or one of its intermediate CAs, with a valid certification path to a root-CA already trusted by the application doing the verification. Commonly called CA constraint, PKIX-TA.
    => refers issuing certificate authority
  • 1: The certificate used must match the TLSA record, and it must also pass PKIX certification path validation to a trusted root-CA. Commonly called service certificate constraint, PKIX-EE.
    => refers the server certificate, requires PKI path validation
  • 2: The TLSA record matches the certificate of the root CA, or one of the intermediate CAs, of the certificate in use by the service. The certification path must be valid up to the matching certificate, but there is no need for a trusted root-CA. Commonly called trust anchor assertion, DANE-TA.
    => refers some issuing certificate authority along the PKI path, requires PKI path validation up to that certificate authority only
  • 3: The TLSA record matches the used certificate itself. The used certificate does not need to be signed by other parties. This is useful for self-signed certificates, but also for cases where the validator does not have a list of trusted root certificates. Commonly called domain issued certificate, DANE-EE.
    => refers the server certificate, does not require PKI path validation

selector:

  • 0: select the entire certificate for matching
  • 1: select just the public key for certificate matching

matching type:

  • 0: the entire information selected is present in the certificate association data
  • 1: SHA-256 hash of the selected data
  • 2: SHA-512 hash of the selected data

certificate association data: actual data to be matched given the settings of the other fields

  • RRSIG (resource record signature): Contains the DNSSEC signature for a record set. DNS resolvers verify the signature with a public key, stored in a DNSKEY record.
  • DNSKEY: Contains the public key that a DNS resolver uses to verify DNSSEC signatures in RRSIG records.
  • DS (delegation signer): Holds the name of a delegated zone. References a DNSKEY record in the sub-delegated zone. The DS record is placed in the parent zone along with the delegating NS records.
  • NSEC (next secure record): Contains a link to the next record name in the zone and lists the record types that exist for the record’s name. DNS resolvers use NSEC records to verify the non-existence of a record name and type as part of DNSSEC validation.
  • NSEC3 (next secure record version 3): Contains links to the next record name in the zone (in hashed name sorting order) and lists the record types that exist for the name covered by the hash value in the first label of the NSEC3 record’s own name. These records can be used by resolvers to verify the non-existence of a record name and type as part of DNSSEC validation. NSEC3 records are similar to NSEC records, but NSEC3 uses cryptographically hashed record names to avoid the enumeration of the record names in a zone.
  • NSEC3PARAM (next secure record version 3 parameters): Authoritative DNS servers use this record to calculate and determine which NSEC3 records to include in responses to DNSSEC requests for non-existing names/types.
    Example: 
                       algorithm   iterations
                   (SHA-1) _   _
bcp.example. IN NSEC3PARAM 1 0 0 -
------------    ----------   -   -
zone            record    flag   salt
                type   (opt-out) (empty)

CAA

DNS certification authority authorization

DANE

DNS-based authentication of named entities

DNS over HTTPS

DNS over HTTPS

DNS over TLS

DNS over TLS

DNSSEC

domain name system security extensions

Multicast DNS

multicast DNS

TSIG

transaction signature

Files

named.conf

(Fedora: bind.x86_64)
/etc/named.conf

Utilities

dnssec-keygen

(Fedora: bind-dnssec-utils.x86_64)
man 8 dnssec-keygen

dnssec-keymgr (wrapper for dnssec-keygen, dnssec-settime)

(Fedora: bind-dnssec-utils.x86_64)
man 8 dnssec-keymgr

dnssec-signzone

(Fedora: bind-dnssec-utils.x86_64)
man 8 dnssec-signzone

dnssec-settime

(Fedora: bind-dnssec-utils.x86_64)
man 8 dnssec-settime

dnssec-dsfromkey

(Fedora: bind-dnssec-utils.x86_64)
man 8 dnssec-dsfromkey

rndc

(Fedora: bind.x86_64)
man 8 rndc

  • subcommands:
    • loadkeys ${zone}: fetch DNSSEC keys for the zone from the key directory and add them as DNSKEY records
    • reconfig: reload configuration from disk and load new zones, but existing zones are ignored
    • reload ${zone}: reload the specified existing zone
    • sign ${zone}: fetch DNSSEC keys for the zone from the key directory and add them as DNSKEY records, re-sign the zone if DNSKEY records were changed
    • signing [-${action}] ${zone}: list, modify, or remove DNSSEC signing state records for the zone

dig

(Fedora: bind-utils.x86_64)
man 1 dig

  • subcommands:
    • axfr or -t axfr: zone transfer
    • ixfr=${N} or -t ixfr=${N}: incremental zone transfer since serial number ${N}

delv

(Fedora: bind-utils.x86_64)
man 1 delv

openssl

(Fedora: openssl.x86_64)
man 1 openssl

Notes

BIND versions

BIND version Recommended configuration
9.11-9.14 Automated (re-)signing by means of Auto-DNSSEC (‘auto-dnssec maintain’) in combination with inline signing (‘inline-signing yes’)
Updates by means of ‘rndc signing’
Automated key management by means of ‘dnssec-keymgr’ and policy file /etc/dnssec-policy.conf (and a final cron job)
9.15 and above Automated (re-)signing by means of Auto-DNSSEC (‘auto-dnssec maintain’) [deprecated in favour of DNSSEC Policy], in combination with inline signing (‘inline-signing yes’)
Updates by means of ‘rndc signing’
Fully automated key management by means of DNSSEC Policy

source: SIDN

BIND DNSSEC authoritative configuration

  • general setup:
    • install BIND (9.11) and DNSSEC-related utilities (Fedora 31): sudo dnf install bind.x86_64 bind-dnssec-utils.x86_64 bind-utils.x86_64
    • configure BIND as authoratative DNS server: sudo sed -e "s@recursion yes@recursion no@" -i /etc/named.conf
    • configure DNSSEC support for BIND: 
      sudo grep -q 'dnssec-enable' /etc/named.conf || \
echo 'dnssec-enable yes;' | sudo tee -a /etc/named.conf

sudo grep -q 'dnssec-enable' /etc/named.conf && \
! sudo grep -q 'dnssec-enable yes;' /etc/named.conf && \
sudo sed -e "s@dnssec-enable .*@dnssec-enable yes;@" -i /etc/named.conf
  • adding a zone:
    • create zone file: sudo vim /var/named/db.example.net
    • include zone in BIND config: echo -e 'zone "example.net" {\n\ttype master;\n\tfile "db.example.net";\n};' | sudo tee -a /etc/named.conf
    • start BIND: sudo systemctl start named.service
    • confirm the zone is available (assuming A or CNAME record for www): dig @127.0.0.1 www.example.net A +short

DNSSEC key management and zone signing

  • key management:
    • ensure path to store keys exists: sudo mkdir -p /etc/named/keys
    • generate a key-signing key: sudo dnssec-keygen -3a ECDSAP256SHA256 -f KSK -K /etc/named/keys example.net
    • generate a zone-signing key: sudo dnssec-keygen -3a ECDSAP256SHA256 -K /etc/named/keys example.net
    • revoke a key: sudo dnssec-revoke -K /etc/named/keys Kexample.net.+013+49534.key (this will create a new set of files, leaving the original files untouched)
  • zone signing:
    • sign a zone: sudo dnssec-signzone -agK /etc/named/keys -o example.net -S /var/named/db.example.net
    • verify a zone: sudo dnssec-verify -o example.net /var/named/db.example.net.signed

Reloading zones after signing

  • update BIND config: sudo sed -e 's@file "db.example.net"@file "db.example.net.signed"@' -i /etc/named.conf
  • reload BIND config (excluding existing zones): sudo rndc reconfig
  • reload the signed zone: sudo rndc reload example.net

CAA configuration

  • Certificate Authority Authorization Records
    • CAA records are supported from BIND 9.10.1B
  • resource record syntax: RFC 6844 - The CAA RR Type
    • issuer critical flag:
      • 0 (i.e. !1): property tag can be ignored if not understood by the CA
      • 1: following property tag must be understood for the CA to issue a certificate
    • property tags:
      • issue $issuer_domain: CA identified as $issuer_domain is authorized to issue certificates
      • issuewild $issuer_domain: CA identified as $issuer_domain is authorized to issue wildcard certificates
      • iodef $URL: reports of (possible) problematic certificate requests may be submitted to $URL
  • example: 
    $ORIGIN example.net
.       CAA 0 issue "ca.example.net"
.       CAA 0 iodef "mailto:security@example.net"

DANE configuration

  • compose usage, selector, matching type field: RFC 6698 - The TLSA Resource Record
    • usage field:
      • 0: CA certificate (“CA constraint”)
      • 1: end entity certificate (“service certificate constraint”)
      • 2: trust anchor (“trust anchor assertion”)
      • 3: end entity certificate (“domain-issued certificate”)
    • selector field:
      • 0: full certificate
      • 1: SubjectPublicKeyInfo
    • matching type field:
      • 0: exact match
      • 1: SHA-256 hash
      • 2: SHA-512 hash
  • generate certificate hash: DNSSEC and Certificates
    • openssl x509 -in certfile.crt -outform DER | sha256sum
  • Let’s Encrypt with DANE
  • example: 
    _443._tcp.www.example.net. IN TLSA (
   0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
         7983a1d16e8a410e4561cb106618e971 )

TSIG configuration

BIND 9: Security Configurations - TSIG

BIND DNSSEC recursive configuration

  • BIND 9 - DNSSEC Guide - Validation
    • older style: 
      sudo grep -q 'recursion yes;' /etc/named.conf && \
sudo grep -q 'dnssec-enable yes;' && \
sudo grep -q 'dnssec-validation yes;' /etc/named.conf && \
sudo test ! -f /var/named/data/named.secroots && \
sudo systemctl start named.service && \
sudo rndc secroots
    • newer style: 
      sudo grep -q 'recursion yes;' /etc/named.conf && \
sudo grep -q 'dnssec-enable yes;' && \
sudo grep -q 'dnssec-validation yes;' /etc/named.conf && \
sudo sed -e "s@dnssec-validation .*@dnssec-validation auto;@" -i /etc/named.conf && \
systemctl is-active named.service && \
sudo rndc reconfig || \
sudo systemctl start named.service
  • DNSSEC validation - how can I tell if my server is doing it?
    • /etc/named.conf: dnssec-enable yes;
    • /etc/named.conf: dnssec-validation yes; (requires manually-configured trust anchors), or dnssec-validation auto;

BIND DNSSEC troubleshooting

  • Basic DNSSEC Troubleshooting
    • (dig output) aa flag: Authoritative Answer
    • (dig output) ra flag: Recursion Available
    • (dig input) +cd flag: Checking Disabled (disable DNSSEC validation)