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