331.4 - DNS and Cryptography

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

Certificate-related records:
- CAA: DNS Certification Authority Authorization, constraining acceptable CAs for a host/domain
- TLSA: A record for DANE. RFC 6698 defines
  “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’”.
Security extensions-related records:
- DNSKEY: The key record used in DNSSEC.
  (Uses the same format as the KEY record.)
- DS: The record used to identify the DNSSEC signing key of a delegated zone
- NSEC: Part of DNSSEC—used to prove a name does not exist.
  (Uses the same format as the obsolete NXT record.)
- NSEC3: An extension to DNSSEC that allows proof of nonexistence for a name without permitting zonewalking
- NSEC3PARAM: Parameter record for use with NSEC3
- RRSIG: Signature for a DNSSEC-secured record set.
  (Uses the same format as the SIG record.)

CAA

DNS certification authority authorization

DANE

DNS-based authentication of named entities

DNS over HTTPS

DNS over TLS

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

SIDN:: BIND 9.11 and up: using cron jobs and scripts for maintenance is no longer recommended. The dnssec-keymgr wrapper in combination with a /etc/dnssec-policy.conf file can automate key management when triggered by a cron job.
Switch.ch:: BIND 9.16 usability for DNSSEC has improved considerably over previous versions. Keys are generated automatically, and DNSSEC merely has to be enabled (and optionally configured) in the named.conf[.local] file.

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.com
.       CAA 0 issue "ca.example.net"
.       CAA 0 iodef "mailto:security@example.com"

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
- comment 55280