DNS & BIND 9 (Linuxhotel Februar 2024)

• what is your interest in DNS?
• what is your prior knowledge of DNS?
• what do you want to learn about DNS?

• RFC 226 "STANDARDIZATION OF HOST MNEUMONICS" in 1971-09 was the first standardization of a naming convention for hosts on on the ARPANET.

• From 1970-1991 the Stanford Research Institution-Network Information Center was the information hub for the ARPANET including maintaining hosts.txt.
• The hosts.txt file
  • Contained IP addresses and names of all of the hosts on the Internet
  • Contained host information as well…
  • Produced twice per week and available via FTP
  • Changes, adds and deletes were sent via e-mail

• Problems with hosts.txt
  • Maintained by a single entity
  • Pulled (manually) from a single host
  • Namespace collisions
  • Consistency
• In 1983, it was determined that something had to be done

  	Davis Mills: RFC 799 (1981) - Internet Name Domains
  	Jon Postel & Zaw-Sing Su: RFC 819 (1982) - The Domain Naming Convention for Internet User Applications
  	Paul Mockapetris: RFC 882 & RFC 883 (1983) - DOMAIN NAMES - CONCEPTS and FACILITIES / DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION

• RFC 882 was obsoleted by RFC 1034 (1987-11) and RFC 883 was obsoleted by RFC 1035 (1987-11)
  • RFC 1034: DOMAIN NAMES - CONCEPTS and FACILITIES
  • RFC 1035: DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION (both: Paul Mockapetris)

• HOSTS.TXT was monolithic, one large file
• The DNS system is hierarchical
• parts of the name space are delegated to the owners of the name
• every owner controls the part of the name space she is owning
• every owner can sub-delegate downwards
• delegation goes from parent domain to child domain
• owner of parent domain can revoke delegation (and re-delegate to a different owner)

• The DNS delegation in the Internet has a specific structure. Other DNS systems (like the DNS used in mobile phone roaming, or local private DNS systems) can have different delegation rules
• RFC 920 defined the original structure of DNS delegation from the root zone

• DNS Query - what the client sends

• DNS Name Resolution

• DNS Resolver caching

• NXDOMAIN - the domain name does not exist.
• NOERROR/NODATA - the domain name exists, but not the RR type. AKA: NOERROR/NOANSWER.
• For NXDOMAIN and NOERROR/NODATA, the zone's SOA is returned in the authoritative section.
• The negative TTL is the minimum of SOA's TTL and the SOA's RDATA MIN field. (RFC 2308)
• BIND's default max-ncache-ttl is 10800 seconds (3 hrs).

• DNS Data is stored and sent in units of "DNS resource records" (or DNS RR)

• The fields of DNS resource records
  • owner: the domain name that owns the data. This is the index to the DNS database
  • TTL: the Time-to-Live, the time in seconds that this DNS data is guaranteed to be valid. This is used to timeout data in caches. It is also sometimes used by applications.
  • Class: The network infrastructure this data is useful in. In TCP/IP networks, this is typically IN for Internet protocol.
  • Type: The type of data, it can be A for IPv4 Address records, AAAA for IPv6 Addresses, TXT for free form text, NS for nameserver entries and many more
  • RData: record data, the data that is attached to the domain name. Depending on the type of record, the RData can have one to many fields
• we find DNS resource records
  • in DNS zone database files on authoritative DNS servers
  • in the caches of DNS resolver servers
  • in the output of a DNS query and troubleshooting tools
• on the wire, the data is transported in binary form (non readable for humans)
• DNS tools convert the DNS resource records from binary form into text form for human consumption

• A Resource Record Set (RRSet) is all RRs with identical: owner name, network class, TTL, and record type
• Each RR of a RRSet has different RDATA.
• A RRSet is not-explicit, and the RRs do not have to be contiguous in the zone file.
• All RRs in a RRSet are sent in a query response.
  • They may be returned in any order.
• The TTLs of all RRs in a RRSet must be identical.
  • Otherwise caching can lead to a single point of failure.
  • BIND enforces this by using the first seen TTL of the RRs.
• A valid DNS resource record set

• An invalid DNS resource record set (different TTLs, duplicate record data)

• the BIND 9 configuration on RedHat/CentOS systems is in /etc/named.conf. Other Unix/Linux systems might store the configuration file in a different place (like /etc/bind on Debian/Ubuntu)

• after changing the BIND 9 configuration file, and before activating the new configuration, we need to check the new configuration for any errors

  % named-checkconf
  

• only if no errors are reported reload/reconfig the DNS server
• reload with the BIND 9 rndc tool

  % rndc reconfig
  

• reload with systemctl

  % systemctl reload named
  

• reload old Unix style

  % pkill -HUP named
  

• A zone must have:
  • one SOA record
  • at least one NS record
• We’ll show all RRs in their complete form.

• A SOA RR defines configurations parameters for a zone.
• The owner name of a SOA RR matches the zone's name.
• The SOA must be the first RR in a zone file.
• The SOA is an internal RR that exists for DNS' own functionality.
• Four SOA RDATA fields are information for secondaries.
• One RDATA field is for resolvers.

dnslab.org. 86400 IN SOA (
   dns1.dnslab.org.            ; MNAME: primary server
   hostmaster.dnslab.org.      ; RNAME: responsible person
   2018061901                  ; SERIAL
   900                         ; REFRESH
   300                         ; RETRY
   604800                      ; EXPIRE
   900 )                       ; negTTL (officially:MINIMUM)

• A Day in the Life of two DNS Servers

• TTLs and the SOA timers can be entered as scaled values in most modern authoritative servers.
  • An integer value followed by:
    • s, for seconds
    • m, for minutes
    • h, for hours
    • d, for days
    • w, for weeks
• Example:

  1w2d5h3m20s =
    1 week + 2 days + 5 hours + 3 minutes + 20 seconds =
    795,800 seconds
  

SOURCE: https://www.ripe.net/ripe/meetings/ripe-55/presentations/koch-ripe203bis.pdf

"These recommendations are aimed at small and stable DNS zones. There are many legitimate reasons to use different values…"

• Comments in master file format begin with a semicolon (;) and extend to the end of the line.
• Example:

  ; important router addresses
  router1.example.com.  3600 IN A 192.0.2.1   ; gateway1
  router2.example.com.  3600 IN A 192.0.2.100 ; tunnel GW
  

• A RR must be written on one line.
• Records can be written over multiple lines using parentheses.
• The parentheses can be at any whitespace in the RR.
• The opening parenthesis must be on the first line.
• Example 1

  example.com.  86400  IN SOA  dns1.example.com. (
                           hostmaster.example.com.
                           2012111701  ; serial
                           86400       ; refresh
                           7200        ; retry
                           3600000     ; expire
                           3600 )      ; negTTL
  

• Example 2

  example.com. ( 86400  IN SOA  dns1.example.com.
                           hostmaster.example.com.
                           2012111701  ; serial
                           86400       ; refresh
                           7200        ; retry
                           3600000     ; expire
                           3600 )      ; negTTL
  

• Example 3

  example.com.  86400  IN SOA  ( dns1.example.com.
                           hostmaster.example.com.
                           2012111701 86400 7200
                           3600000 3600 )
  

• Example 4

  example.com.  86400  IN SOA ns1.test. admin.example. (
                      2012111701 86400 7200 3600000 3600 )
  

• BIND includes a tool to check a zone file for syntax errors and required missing data (e.g. no NS RR).
• It is recommended to always check a zone file and correct all errors before having named (re)load it.
• Syntax: named-checkzone <zonename> <filename>

  % named-checkzone example.com example.com.zonefile
  zone example.com/IN: loaded serial 2018072901  OK
  

• The NS record has two functions.
  • To define the authoritative servers for a zone.
  • To delegate to authoritative servers for a sub-domain.
• Like the SOA, the NS is an internal RR that exists for DNS' functionality.

• An A RR maps a domain name to an IPv4 address

  www.example.com.  86400 IN A 192.0.2.10
  

• One domain name can map to multiple A RRs.

  host.example.com.    3600 IN A 192.0.2.10
  host.example.com.    3600 IN A 10.0.10.2
  host.example.com.    3600 IN A 172.16.1.12
  

• The server returns all addresses (a RRSet).
• When a stub resolver returns multiple addresses to an application, the application should do something intelligent.
  • Many don’t :(

• The AAAA record maps a domain name to an IPv6 address

  www.example.com.  86400 IN AAAA 2001:db8:110:100:20:102f:ffeb:5380
  

• Many applications query for a AAAA RR before falling back to an A RR.
• When they get a response for the AAAA query, most will not try to lookup an IPv4 address.
• If the successfully resolved AAAA doesn't lead to an active server, an application will likely fail.
• So if a AAAA address exists, it must be available.
• The Happy Eyeball protocol addresses the problem when present: RFC 8305: Happy Eyeballs Version 2: Better Connectivity Using Concurrency

• The HTTPS record is a relativly new record. It's type number is 65 (aka TYPE65)
  • It has been first observed "in the wild" in Summer 2020
  • It is being used in the new Apple operating systems (iOS, iPadOS, macOS) since fall 2020
  • It is now the 3rd most queried DNS record in the Internet (after A and AAAA)
  • It is not yet (as of September 2021) an Internet Standard: Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) draft-ietf-dnsop-svcb-https
• The HTTPS delivers connection information for an HTTPS service
  • IPv4-Addresses of the service
  • IPv6-Addresses of the server
  • The public key of the server to be used to initiate an encrypted TLS "client hello"
  • Protocol selection: HTTP/2 (TCP) or HTTP/3 (QUIC)
  • One or more DoH-Resolver for the service
• Example of a HTTPS Record for a service offering HTTP/2 and HTTP/3 (preferred)

example.com 3600 IN HTTPS 1 . alpn=”h3,h2”

• Example of a HTTPS Record for a service with both IPv4 and IPv6 Addresses

example.com 3600 IN HTTPS 1 . alpn=”h3,h2” ipv4hint=”192.0.2.1” ipv6hint=”2001:db8::1”

• Benefits of the HTTPS records
  • Browser don't need to request explicit IPv6 and IPv4 Addresses (faster connection)
  • The HTTPS Records is a signal to the web-browser to only allow TLS secured/encrypted connections for this domain name. This prevents downgrade attacks
  • With the HTTPS Record it is possible to create Domain-Alias definitions for whole zones (not possible with the CNAME Record)
• The BIND 9 DNS server and tools (dig, host) support the HTTPS record since version 9.16.21 (September 2021)

• The CNAME record creates an alias from one domain name (the owner of the CNAME) to another.

  www.example.com.  86400 IN CNAME example.com.
  

• The TXT RR permits a free-form text to be associated with the domain name.

  mail.example.com.  86400 IN TXT "Mail Server for example Domain"
  

• TXT records may contain multiple strings, each up to 255 characters in length.
• These strings are concatenated by the DNS client
• RDATA may not exceed 65535 bytes in total.
• The TXT RR is often used for documentation purposes, for example:
  • Storing location information. (c.f. LOC record)
  • Documenting who is responsible for a particular host. (c.f. RP record)
  • This presumes the domain name is a host.
• New or experimental protocols often use TXT RRs before a dedicated RR type is assigned.
  • Jabber (XMPP)
  • Sender Policy Framework (SPF)
    • The SPF RR has been deprecated in favor of TXT RRs.
  • Domain Key Identified Mail (DKIM)

• The MX RR defines a mail exchange (SMTP Mail Server) for the domain name.

  <domain-name> <ttl> IN MX <preference> <mail transfer agent hostname>
  
  example.com.  86400 IN MX 10 mail.example.com.
  

  • Preference: An unsigned, unscaled 16 bit value (not hops, time or anything else).
    • lower value => higher preference
  • Domain name (host name) of an SMTP server.

• The SRV record gives the domain name of a server that provides the service encoded in the owner name.
  • It is a generalized version of the MX RR (which only supports SMTP).
  • Like the MX RR, the SRV has additional fields that govern how clients should access the service.
• Format:

  # Format: [owner]  [ttl]  [class]  SRV <priority> <weight> <port> <hostname>
  _ldap._tcp.example.com.   3600 IN SRV 10 100 389 dc.example.com.
  

  • Encoded service in the owner name. Here LDAP over TCP.
    • The service name is from: /etc/services
  • Priority: An unsigned, unscaled 16 bit value (Like the MX's preference.)
    • lower value => higher priority
  • Weight: Preference for RRs with equal priority.
    • Weight is a load distribution system.
  • The port the service is listening on. This allows running a protocol on a port that is not "well known".
  • Domain name (host name) of the server.

• a DNS installation constists of multiple components
  • DNS clients (smartphones, tablets, desktop, laptop, server, IoT devices etc)
  • DNS resolver (also named "Caching Server", "Smart Resolver", "recursive DNS Server"
  • authoritative DNS Server

• in managed networks (company, university) the IT department manages one or more dedicated DNS resolvers

• ISP (Internet Service Provider) customers often use the DNS resolvers provided by the ISP

• although sometimes problematic from privacy and security point of view, many users today use public DNS resolvers in the Internet

• some operating systems support operating a full DNS resolver on each system

• For redundancy reasons, each DNS zone has multiple authoritative servers (one primary, multiple secondaries holding copies of the zone database)

• For primary zones, the zone statement minimally defines:
  • The domain name of the zone.
  • The zone type (primary).
  • The zone data file.

  zone "example.com" {
       type primary;
       file "example.com";
  };
  

• For secondary zones, the zone statement minimally defines:
  • The domain name of the zone.
  • The zone type (secondary).
  • The IP address(es) of the primary name server(s).
  • A backup zone file (optional, but standard).

  zone "example.com" {
      type secondary;
      primaries { 192.0.2.10; 192.0.2.20; };
      file "example.com";
  };
  

• A secondary zone can have more than one primary (max 10).
• This adds robustness and allows secondaries that can't reach the primary (perhaps because of a firewall).

• If named.conf has no logging statement, BIND essentially defaults to use syslog.
• The default configuration is:

  logging {
        category default {
            default_syslog;
            default_debug;
        };
        category unmatched { null; };
  };
  

logging {
        channel default_syslog {
                syslog daemon;
                severity info;
                print-category yes;
        };

        channel lame_channel {
        file "log/lamers.log" versions 5 size 100m;
               severity info;
               print-time yes;
        };
        category lame-servers    { lame_channel; };

        channel security_channel {
        file "log/security.log" versions 10 size 100m;
                severity info;
                print-time yes;
        };
        category security    { security_channel; };

        // don't log dns queries all time
        // if you need querylogging for troubleshooting an issue
        // turn it on for needed time
        // rndc querylog
        // dont forget disable with  rndc querylog
        //
        // activate debugging with
        // rndc trace
        //
        // debug errors are logged to the category query-errors
        //
        // don't forget to turn it off again
        // rndc notrace

        channel query_channel {
        file "log/queries.log" versions 1 size 100m;
               severity info;
               print-time yes;
               print-severity yes;
        };
        category queries    { query_channel; };

        channel queryerror_channel {
        file "log/queryerrors.log" versions 5 size 100m;
               severity dynamic;
               print-time yes;
               print-severity yes;
        };
        category query-errors    { queryerror_channel;};

        channel resolver_channel {
        file "log/resolvers.log" versions 5 size 100m;
               severity info;
               print-time yes;
        };
        category resolver    { resolver_channel; };

        channel general_channel {
        file "log/general.log" versions 5 size 100m;
               severity info;
               print-time yes;
        };
        category general                { general_channel; };
        category unmatched              { general_channel; };
        category client                 { general_channel; };
        category config                 { general_channel; };
        category network                { general_channel; };
        category delegation-only        { general_channel; };
        category dispatch               { general_channel; };

        channel dnssec_channel {
        file "log/dnssec.log" versions 5 size 100m;
               severity info;
               print-time yes;
        };
        category dnssec    { dnssec_channel; };

        channel edns_channel {
        file "log/edns.log" versions 5 size 100m;
               severity info;
               print-time yes;
        };
        category edns-disabled    { edns_channel; };

        channel capacity_channel {
        file "log/capacity.log" versions 5 size 100m;
               severity info;
               print-time yes;
        };
        category database    { capacity_channel;};
        category rate-limit  { capacity_channel;};
        category spill       { capacity_channel;};
};

• Turn on logging for the feature that is misbehaving.
  • Enable the logging category that covers the feature.
  • Send the output where you can find it.
  • Too much logging can be as bad as no logging.
• Learn what normal logging looks like so that when something breaks, you recognize the abnormalities.
• Is BIND listening?
  • System tools such as lsof, ss, and netstat list currently open network sockets:

    % lsof -Poni :53
    COMMAND    PID            USER   FD   TYPE DEVICE OFFSET NODE NAME
    systemd-r 2509 systemd-resolve   18u  IPv4  32663    0t0  UDP 127.0.0.53:53
    named     3131           named   21u  IPv4  38238    0t0  TCP 127.0.0.1:53 (LISTEN)
    named     3131           named   22u  IPv6  38240    0t0  TCP [::1]:53 (LISTEN)
    named     3131           named  512u  IPv4  38236    0t0  UDP 127.0.0.1:53
    named     3131           named  513u  IPv6  38239    0t0  UDP [::1]:53
    

• dig has a number of options that aid in debugging
  • +trace - resolve from the root servers
  • +nssearch - retrieve SOA from all authoritative servers
  • +tcp - use TCP instead of UDP for queries
  • +norecurse - Do not set the "RD" bit on outbound query
  • +multiline - produce output in multi-line (extended) format

• DNS looking glasses are web interfaces for querying.
  • Like dig, they are DNS admin tools.
  • They can succeed when dig fails.
  • Some are simple a dig interface on a website.
  • Sometimes they are called, "web based dig."
• Many sites offer a looking glass.
  • These are frequently terrible: limited input options, limited RR types support, cropped or edited output, old dig versions, etc.
  • Even good ones cannot query your internal-only domains.
  • They are useful when dig is not available.
  • They can provide insight into geo-located responses, because they run somewhere else.
• Recommend Looking Glass:
  • https://dns.bortzmeyer.org/domain/[type]/[class]
• Recommended web based dig:
  • https://networking.ringofsaturn.com/Tools/dig.php
• Looking Glass: Looking At GeoIP
  • https://whatsmydns.net queries a domain name using resolvers worldwide. It exposes address variations based on location.
• Other options:
  • https://toolbox.googleapps.com/apps/dig
  • https://digdns.com ANY only, but many other tools included and good output.

• Now we have a second authoritative DNS server for our zone
• But it is not listed in the zone (Parent Child disagreement)
• We need to fix this

• $ORIGIN is a variable that is appended to non full qualified domain names (FQDN).
  • It applies to owner names and RDATA name fields.
  • The default $ORIGIN is the name of the zone.
  • @ allows the explicit use of the $ORIGIN value.

• A RR that begins with a white space inherits the most recently specified owner name.
  • This means that order matters in a zone file.
  • Be careful not to add a new RR with a new name before a RR inheriting its name.
  • A new owner name is always left justified.

  zoneNNN.dnslab.org.      30 IN NS   dns2.someotherzone.com.
                           30 IN NS   ns1
                           30 IN A    192.0.2.67
  

• A RR without a TTL is assigned the zone's default TTL.
  • The default is defined with the $TTL control statement.
  • $TTL can be used multiple times in a zone file.
  • The most recent $TTL is the default.

  $TTL 30
  zoneNNN.dnslab.org.      IN NS   dns2.someotherzone.com.
                           IN NS   ns1
                           IN A    192.0.2.67
  

• Note the different inheritance rules for the Owner Name and the TTL.
  • A RR without an owner name inherits the previous RR's name.
  • A RR without a TTL inherits the zone's default TTL.

• Without being explicitly assigned, a RR inherits its class from the zone’s definition.
  • For BIND, the definition is in named.conf.
  • IN is the default class. You are unlikely to create zones with any other class.

  @         30 SOA ns1 hostmaster 5 7200 3600 2592000 600
            30 NS  ns1
  ns1       30 A   192.0.2.100
  

• $INCLUDE reads another file into the zone file.
• If you have zones with identical data, $INCLUDE lets you avoid recreating and maintaining the same information.

   @         30 SOA ns1 hostmaster 5 7200 3600 2592000 600
             30 NS  ns1
             30 NS  dns2.someotherzone.com.
  ns1       30 A   192.0.2.100
  $INCLUDE "common.rr.txt"
  

• For reverse DNS lookup, the IP address must be converted into a domain name (because in DNS the query index is always a domain name)
  • In IP addresses, the hierarchy is from left to right (network part on the left of an IP address, host part on the right)
  • In domain names, the hierarchy is from right to left (Root-Zone and Top-Level domain on the right, host part on the left)
  • To map an IP address to a domain name, we reverse the order of all digits of the address, and add the second level domains in-addr.arpa. (IPv4) or ip6.arpa (IPv6)
    • For IPv4 = 192.0.2.100 -> 100.2.0.192.in-addr.arpa.
    • For IPv6 = 2001:db8:ff::1 -> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.F.F.0.0.8.B.D.0.1.0.0.2.IP6.ARPA
  • The domain name for an IP address is stored as a PTR (Pointer) record with the domain name in the record data

132.0.2.192.IN-ADDR.ARPA.    3600 IN PTR www.example.com.

• arpaname is a BIND tool for generating a PTR RR from an IP address.

  $ arpaname 10.4.13.132
  132.13.4.10.IN-ADDR.ARPA
  $ arpaname 2001:db8:a1:CAFE::fab
  B.A.F.0.0.0.0.0.0.0.0.0.0.0.0.0.E.F.A.C.1.A.0.0.8.B.D.0.1.0.0.2.IP6.ARPA
  

• dig supports a shortcut notation for reverse lookup queries with the -x switch:

  $ dig -x 192.168.1.36
  

• is the same as

  $ dig 36.1.168.192.in-addr.arpa PTR
  

• Reverse domains are delegated from the Regional Internet Registries (RIRs) and Local Internet Registries (LIRs)

• You need to request your reverse space be delegated to your authoritative servers by the entity that gave you IP address space (ISP, RIR, LIR etc)

• Zonefile for reverse zone for network block 192.168.1.0/24:

  $TTL 60
  $ORIGIN 1.168.192.in-addr.arpa.
  
  ;; the domain names of the authoritative name servers are always in
  ;; a "normal/forward" zone, not in the namespace of a reverse zone!
  
  @               SOA   nsNNNa.dnslab.org.    .    1001 1h 30m 40d 60
                  NS    nsNNNa.dnslab.org.
    		NS    nsNNNb.dnslab.org.
  
  ;; the Pointer Records point to the names of the machines
  1               PTR   beta.zoneNNN.dnslab.org.
  20              PTR   alpha.zoneNNN.dnslab.org.
  25              PTR   delta.zoneNNN.dnslab.org.
  100             PTR   gateway.zoneNNN.dnslab.org.
  

• Zone-Block in named.conf

  zone "1.168.192.in-addr.arpa" {
       type primary;
       file "1.168.192.in-addr.arpa";
  };
  

• You zone needs new delegation NS record for the subdomain trainer.zoneNNN.dnslab.org. There are two NS records, one for each authoritative DNS server of the delegated zone:

trainer.zoneNNN.dnslab.org.     IN NS  ns010a.dnslab.org.
trainer.zoneNNN.dnslab.org.     IN NS  ns010b.dnslab.org.

• Because this is a change in your zone, the SOA serial must be incremented, else the secondaries will not pick up the change
• The zonetransfer should be visible in the zone transfer logfile transfer.log
• The command dig zoneNNN.dnslab.org +nssearch should show the same SOA serial on both authoritative DNS server
• The test dig TXT trainer.zoneNNN.dnslab.org should return the text Hurra, die Delegation funktioniert!

• the classic DNS from 1983 was not designed with security in mind
• DNS cache poisoning
• Men-in-the-Middle data spoofing
• changes to the client DNS resolver configuration
• attacks of authoritative DNS servers
• DNSSEC can help

• the DNS security extension DNSSEC secures DNS data by augmenting the data with cryptographic signatures
  • the owner (administrator) creates a key pair of private and public key for each DNS zone (asymmetric crypto)
  • the owner/administrator signs all DNS data with the private key
  • the recipient of the data (DNS resolvers 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 correct owner (the owner of the private key)

• DNSSEC creates a chain of trust between the parent zone and the child zone

• Applications and DNS resolvers can follow the chain of trust to a configured trust anchor to validate the DNS data
• we will look into DNSSEC in more details later in this course* DNSSEC Intro :noexport:
• In DNSSEC, each zone has one or more key pairs.
  • The private key of each pair
    • Is stored securely (probably on a hidden primary)
    • Is used to sign zone data
    • Should never be published or stored in a RR
  • The public key of each pair
    • It should be public
    • Is stored in the zone data, as a DNSKEY record
    • Is used to verify zone data
• A private key signs the hashes of each RRSet in a zone.
• The public key is accessible through a standard RR.
  • Recursive servers or clients query for the public key RR in order to decrypt a hash.
  • The RR is known as the DNSKEY and covered below.

• stub zones are configured in the named.conf of a DNS resolver
• the backup file is optional and will be created

  zone "private.dns.zone.example" {
    type stub;
    primaries { <ip-addresses-of-primaries>; };
    file "private.dns.zone.example.stubzone";
  };
  

• If multiple resolvers use a forwarder, they benefit from the forwarder's cache.
• If the forwarder has better Internet connectivity than a resolver using it, the resolver benefits again.
  • This is particularly applicable for resolvers blocked by firewalls from reaching authoritative servers.

• Forwarding architectures that depend on a small number of forwards are brittle.
• Forwarding intercepts the standard resolution process and is harder to troubleshoot.
• Forwarding configuration is not replicated by zone transfer, where normal delegation is (named.conf vs. zone data information).
  • Forwarding must be configured on each resolver using it.

• If all forwarders fail, a RDNS server resolves normally (forward first mode).
• forward only; completely disables normal resolution. The default is forward first;
• If no forwarder returns an answer, the resolver returns: SERVFAIL

options {
  forwarders { <IP address>; <...> };
  forward only;   # The server can no longer be accurately called recursive!
};

• A forward zone configures the resolver to forward for one domain.
  • The domain "." is the equivalent of global forwarding.
  • Remaining queries are through the normal recursive process.
  • They are used primarily in intranets, were introduced in BIND 9.1, and are known as conditional forward in Microsoft DNS (introduced in Windows Server 2003).

• A forward zone should be directed to a recursive server that can resolve for the specified domain.
• However, a forward zone is often directly to the authoritative server of the zone.
  • Before stub zones were introduced, this was reasonable.
  • Today, stub zones are the best way to redirect to an authoritative server.

zone "example.com." {
     type forward;
     forwarders { 192.0.2.110; 192.0.2.120; };
};

• Forward zones apply to queries ending in the specified domain name.
• Queries for sub.example.com and ab.de.fg.example.com would be forwarded.

• reload <zonename>: after modifying a zone file.

  % rndc reload example.com
  

• reload: after modifying named.conf or any zone. It reloads named.conf and all zone files. It can be a significant load on a server with many zones.

  % rndc reload
  

• reconfig: reloads only named.conf. Newly defined zones are of course loaded.

  % rndc reconfig
  

• Avoid using rndc reload, when rndc reconfig will suffice!
• refresh <zonename>: refresh a zone from a secondary authoritative server. The SOA is queried and if the serial number has changed, a zone transfer is triggered.

  % rndc refresh example.com
  

• retransfer <zonename>: transfer, regardless of the serial number. This is for a server slaving a zone.

  % rndc retransfer example.com
  

• notify <zonename>: force notify messages for a zone, to trigger a refresh on the (known) secondaries. This is for a primary server of a zone.

  % rndc notify example.com
  

• Many websites offer domain name checking.
• These are most useful for your authoritative zones.
• Some checkers are broken, outdated, or simply bad.
• Two are excellent and recommended:
  • https://zonemaster.net (alternative: https://zonemaster.iis.se)
  • https://dnsviz.net

• authoritative DNS server and DNS resolver are separate functions in the DNS infrastructure
  • they have different security requirements
• while BIND 9 can operate in "hybrid" mode (default), it is strongly recommended to separate the two functions
  • can run on the same hardware with operating system containers or virtualisation
• benefits of separate authoritative and recursive DNS
  • required for DNSSEC validation of own zones
  • security configuration optimised for the function (for example query ACLs)
  • helps troubleshooting (logging)
  • easier maintenance (Updates)

• isolate the BIND 9 DNS server process from the operating system and other applications
  • reduces the impact of a security breach
  • classic Unix operating systems offer the chroot function to isolate a process into its own filesystem-tree
    • while many security tutorials still explain chroot, it might not be the best option available today
    • modern systems offer much richer isolation functions:
      • Linux container (LXC/LXD, Docker, Podman, systemd-nspawn, Firejail)
      • Linux GRSecurity Kernel enhanced "chroot" (https://grsecurity.net/features.php)
      • FreeBSD jails
      • Solaris/Illumnos "zones"

• classic DNS is vulnerable to a large number of attacks on the content of DNS answers
• DNSSEC (digital signatures on DNS data) guards against many of these attacks
• the DNS root-zone, all gTLDs and nTLDs and many ccTLDs are DNSSEC signed
  • many second level domains are also DNSSEC secured
• BIND 9 comes with a trust-anchor for the Internet Root-Zone built-in
• DNSSEC validation can be enabled with just one configuration line

  options {
          dnssec-validation auto;
  };
  

• enable DNSSEC validation on a DNS resolver
• test that DNSSEC validation is enabled:

  % rndc validation check
  DNSSEC validation is enabled (view _default)
  $ dig SOA . @127.0.0.1 +adflag
  ; <<>> DiG 9.4.2-P2 <<>> soa . @127.0.0.1 +adflag
  ;; global options:  printcmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46337
  ;; flags: qr rd ra >>ad<<; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0
  

• RFC 1034 defines the additional section in a DNS answer as "Carries RRs which may be helpful in using the RRs in the other sections."
  • in the default configuration, BIND 9 tries to be very helpful, sending additional information …
  • … creating larger than needed DNS answer packets
  • this is sometimes exploited by attackers in distributed denial of service attacks
• configure "minimal-responses" in BIND 9

  options {
     minimal-responses yes;
  };
  

• BIND 9 will only return the data required for the DNS protocol to work
• this reduces the "ammo" available to attackers

• a BIND 9 server getting an query with type ANY (QTYPE 255) will answer with all records matching the requested domain name and class
  • this can create large UDP DNS answer packets
• starting with BIND 9.11, BIND 9 can be configured to only return the first entry of an matching ANY query
  • this mitigates the problem without causing breakage of older software (qmail etc)

  options {
         minimal-any yes;
  };
  

• a DNS infrastructure with DNSSEC signed zones is more fragile
  • more complex configuration
  • most errors are fatal, the zone cannot be resolved anymore (this is a security feature of DNSSEC!)
• DNSSEC monitoring helps to detect issues before the DNS service is affected

• Men & Mice has compiled 15 essential monitoring test scripts
  • these scripts are simple (Bourne-) shell scripts that should work on any Unix/Linux system (and on Windows 10 with Linux-Sub-System or Windows with Cygwin)
  • the scripts are available in the Men & Mice Services Github repos https://github.com/menandmice-services/dns-monitoring-scripts
  • Please send pull-requests for fixes and additions
• the scripts are deliberately simple
• each script takes one input parameter
  • the domain-name of a delegated zone
• the scripts can be used from a cron-job
  • or embedded into an monitoring system.

• Test 1 - UDPv4 reachability - test for each authoritative server of the DNS infrastructure

  $ dig -4 test-domain +nssearch
  

• Test 2 - UDPv6 reachability - test for each authoritative server of the DNS infrastructure that it is reachable over UDP IPv6

  $ dig -6 test-domain +nssearch
  

• Test 3 - TCPv4 reachability - test for each authoritative server of the DNS infrastructure that it is reachable over TCP IPv4

  $ dig -4 test-domain +tcp +nssearch
  

• Test 4 - TCPv6 reachability - test for each authoritative server of the DNS infrastructure that it is reachable over TCP IPv6

  $ dig -6 test-domain +tcp +nssearch
  

• Test 5 - EDNS0 response size: tests that the server signals the correct EDNS0 response size. Size needs to be checked against the local policy. Usually 1220-1232 bytes.

  echo " == #5 - EDNS0 response size == "
  
  err=0
  ednspolicy=1232
  
  dig NS ${1} +short | while read server; do
    echo "Server: ${server} "
    ednsbuf=$(dig @${server} ${1} | grep "; EDNS:" | cut -d " " -f 7)
  
    if [ "${ednsbuf}" -eq "${ednspolicy}" ]; then
      echo " EDNS0-Bufsize is ${ednsbuf}, good "
    else
      err=1
      echo " EDNS0-Bufsize is ${ednsbuf}, out of policy range "
    fi
  done
  
  exit ${err}
  

• Test 6 - test that all authoritative server for a zone respond. Count is tested against the number of delegation authoritative servers for the zone.

  echo " == #6 - IPv4 zone response tests == "
  
  err=0
  # get TLD for the zone
  tld=$(echo ${1} | rev | cut -d'.' -f 1 | rev)
  # pick one TLD auth server
  tldns=$(dig NS ${1}. +short | tail -1)
  # query and count the delegation NS records for the zone
  parentnsnum=$(dig @${tldns} NS ${1} +short | wc -l)
  # query the authoritative DNS servers for the zone
  childnsnum=$(dig -4 ${1} +nssearch | wc -l)
  
  if [ "${parentnsnum}" -eq "${childnsnum}" ]; then
    echo "all authoritative DNS-Server answer"
  else
    err=1
    echo "Error: Mismatch"
    echo "Auth DNS-Servers in Delegation: ${parentnsnum}"
    echo "Auth DNS-Servers in answering: ${childnsnum}"
  fi
  
  exit ${err}
  

• Test 7 - test that all authoritative server for a zone respond via TCP. Count should be tested against the known good number of authoritative servers for the zone. The return code of the dig command should be checked for errors.

  echo " == #7 - IPv4 (TCP) zone response tests == "
  
  err=0
  # get TLD for the zone
  tld=$(echo ${1} | rev | cut -d'.' -f 1 | rev)
  # pick one TLD auth server
  tldns=$(dig NS ${1}. +short | tail -1)
  # query and count the delegation NS records for the zone
  parentnsnum=$(dig @${tldns} NS ${1} +short | wc -l)
  # query the authoritative DNS servers for the zone
  childnsnum=$(dig -4 ${1} +nssearch +tcp | wc -l)
  
  if [ "${parentnsnum}" -eq "${childnsnum}" ]; then
    echo "all authoritative DNS-Server answer"
  else
    err=1
    echo "Error: Mismatch"
    echo "Auth DNS-Servers in Delegation: ${parentnsnum}"
    echo "Auth DNS-Servers in answering: ${childnsnum}"
  fi
  
  exit ${err}
  

• Test 8 - test that all authoritative server for a zone have the same SOA serial. The return code of the dig command should be checked for errors.

  dig zone +nssearch
  

  • the SOA serial can be different for short amount of times after an update on the primary (propagation delay during zone transfer)
  • on a test interval of 5 minutes the test should issue a warning if the same SOA difference is seen in two successive tests
  • is the same SOA difference seen after three or more tests, an event of severity ERROR should be generated
• Test 8 - test that all authoritative server for a zone have the same SOA serial. The return code of the dig command should be checked for errors.

  echo " == #8 - SOA serial == "
  
  err=0
  oldsoaserial="0"
  
  dig ${1} +nssearch | while read serverres; do
    soaserial=$(echo ${serverres} | cut -d ' ' -f 4)
  
    if [ "${oldsoaserial}" -eq "0" ]; then
      oldsoaserial=${soaserial}
    else
      if [ "${oldsoaserial}" -eq "${soaserial}" ]; then
       echo "Match for ${soaserial}"
      else
       err=1
       echo "Mismatch for ${soaserial} != ${oldsoaserial}"
      fi
    fi
  done
  
  exit ${err}
  

• Test 9 - test for AA-Flag. Repeat this test for each authoritative server for the zone. Each server must respond with an AA-Flag.

  echo " == #9 - AA-Flag == "
  
  err=0
  
  dig NS ${1} +short | while read server; do
    echo "Server: ${server} "
    aaflag=$(dig @${server} ${1} SOA +norec | grep ";; flags" | cut -d " " -f 4 | cut -b 1-2)
  
    if [ "${aaflag}" = "aa" ]; then
      echo " AA-Flag found, good "
    else
      err=1
      echo " no AA-Flag, Server not authoritative "
    fi
  done
  
  exit ${err}
  

• Test 10 - test for Parent-Child NS-RRset. Tests that the NS-RRset in the parent zone (delegation) matches the NS-RRset in the zone data.

  echo " == #10 - test for Parent-Child NS-RRset == "
  
  if [ "$1" = "" ]; then
    echo "This test fails without param. Exiting..."
    exit 1
  fi
  
  err=0
  # get one authoritative server for the zone
  child_dns=$(dig NS ${1} +short | tail -1)
  # get TLD of Domain
  tld=$(echo ${1} | rev | cut -d'.' -f 1 | rev)
  # get one authoritative server for the TLD
  tldns=$(dig NS ${tld}. +short | tail -1)
  # query the delegation records
  parns=$(dig @${tldns} NS ${1} +norec +noall +authority | grep "IN.*NS" | sort)
  
  while read nsrec; do
    ns=$(echo ${nsrec} | cut -d ' ' -f 5)
    parentns="${parentns} ${ns}"
  done <<EOF
  ${parns}
  EOF
  
  # query the zone records
  childns=$(dig @${child_dns} NS ${1} +short +norec | sort)
  parentns=$(echo ${parentns} | tr ' ' '\n' | sort)
  
  echo "Parent delegation:"
  echo ${parentns}
  echo "Child zonedata:"
  echo ${childns}
  
  if [ "${childns}" = "${parentns}" ]; then
    echo "Parent/Child NS-RRSet matches"
  else
    err=1
    echo "Parent/Child NS-RRSet mismatch"
  fi
  
  exit ${err}
  

• Test 11 - test for DNSKEY RRset answer size. The full answer packet of the DNSKEY rrset should be below the IPv6 fragmentation payload limit (1232 byte)

  echo " == #11 - test for DNSKEY RRset answer size == "
  
  err=0
  maxsize=1232
  replysize=$(dig ${1} DNSKEY +dnssec +cd | grep ";; MSG SIZE" | cut -d " " -f 6)
  
  if [ "${replysize}" -le "${maxsize}" ]; then
    echo "Good, DNSKEY RRSet size is ${replysize} which is below or equal to ${maxsize}"
  else
    err=1
    echo "Bad, DNSKEY RRSet size is ${replysize} which is above ${maxsize}"
  fi
  
  exit ${err}
  

• Test 12 - RRSIG validity: check for the lifetime timestamps of RRSIGs in the zone. This test should be done for every important RRset in the zone (SOA, DNSKEY, MX, A/AAAA)

  dig zone soa +dnssec | egrep "RRSIG.*SOA" | cut -d " " -f 6
  dig zone soa +dnssec | egrep "RRSIG.*SOA" | cut -d " " -f 5
  

• compare the output with the current system time date "+%Y%m%d%H%M%S"
  1. issue an ERROR event, if the inception time is in the future
  2. issue an ERROR event, if the expiry time is in the past
  3. issue an WARNING event, if the expiry time will be reached in less than 5 days
  4. issue an ERROR event, if the expiry time will be reached in less than 2 days

  echo " == #12 - RRSIG validity == "
  
  if [ "$1" = "" ]; then
    echo "This test fails without param. Exiting..."
    exit 1
  fi
  
  err=0
  today=$(date "+%Y%m%d%H%M%S")
  inception=$(dig ${1} SOA +cd +dnssec | egrep "RRSIG.*SOA" | cut -d " " -f 6)
  expiry=$(dig ${1} SOA +cd +dnssec | egrep "RRSIG.*SOA" | cut -d " " -f 5)
  
  echo "Today    : ${today}"
  echo "Inception: ${inception}"
  echo "Expiry   : ${expiry}"
  
  if [ "${inception}" -gt "${today}" ]; then
    err=1
    echo "ERROR: RRSIG validity (${inception}) is in the future"
  fi
  
  if [ "${expiry}" -lt "${today}" ]; then
    err=1
    echo "ERROR: RRSIG validity (${expiry}) is in the past, DNSSEC signature has expired"
  fi
  
  twodaysahead=$(date +%s)
  twodaysahead=$((${twodaysahead}+172800))
  twodaysahead=$(date -u --date="@${twodaysahead}" "+%Y%m%d%H%M%S")
  
  if [ "${expiry}" -lt "${twodaysahead}" ]; then
    err=1
    echo "ERROR: RRSIG validity (${expiry}) will end in less than two days"
  fi
  
  fivedaysahead=$(date +%s)
  fivedaysahead=$((${fivedaysahead}+432000))
  fivedaysahead=$(date -u --date="@${fivedaysahead}" "+%Y%m%d%H%M%S")
  
  if [ "${expiry}" -lt "${fivedaysahead}" ]; then
    err=1
    echo "WARNING: RRSIG validity (${expiry}) will end in less than five days"
  fi
  
  exit ${err}
  

• Test 13 - DS Records - test the number and the content of the DS records in the parent zone. Issue a warning when the count or the content changes

  echo " == #13 - DS Records == "
  
  err=0
  
  if [ -f "$0.$1.saved.dscontent" ]; then
    oldds=$(cat $0.$1.saved.dscontent)
    olddscount=$(cat $0.$1.saved.dscount)
  else
    echo "First run. This result won't be meaningful until the next run.";
  fi
  
  ds=$(dig ${1} DS +short)
  echo "${ds}" > $0.$1.saved.dscontent
  
  dscount=$(dig ${1} DS +short | wc -l)
  echo "${dscount}" > $0.$1.saved.dscount
  
  if [ "${ds}" != "${oldds}" ]; then
    err=1
    echo "Warning: DS-Record has changed!"
  else
    echo "OK: DS-Record is the same as last time tested!"
  fi
  
  if [ "${dscount}" != "${olddscount}" ]; then
    err=1
    echo "Warning: number of DS-Record has changed!"
  else
    echo "OK: number of DS-Record is the same as last time tested!"
  fi
  
  exit ${err}
  

• Test 14 - DS Records and KSK - test that the DS-Record matches the KSK in the zone. The two values (Key-ID) must match.

  echo " == #14 - DS Records and KSK == "
  
  if [ "$1" = "" ]; then
    echo "This test fails without param. Exiting..."
    exit 1
  fi
  
  err=0
  
  dskeyid=$(dig ${1} DS +short +cd | cut -d " " -f 1 | tail -1)
  rrsigkeyid=$(dig ${1} DNSKEY +dnssec +short +cd | egrep "^DNSKEY" | grep "${dskeyid}" | cut -d ' ' -f 7)
  
  if [ "${dskeyid}" != "${rrsigkeyid}" ]; then
    err=1
    echo "Error: Key-Tag of DS-Records does not match the Key-Tag of RRSIG on DNSKEY"
  else
    echo "OK: Key-Tag of DS-Records does match the Key-Tag of RRSIG on DNSKEY"
  fi
  
  exit ${err}
  

• Test 15 - Count of DNSKEY records in the zone. The number can change during a key-rollover. Any change should create an WARNING event

  echo " == #15 - DNSKEY record count == "
  
  if [ -f "$0.$1.saved.dnskeycount" ]; then
    olddnskeycount=$(cat $0.$1.saved.dnskeycount)
  else
    echo "First run. This result won't be meaningful until the next run.";
  fi
  
  err=0
  dnskeycount=$(dig ${1} DNSKEY +cd +dnssec | egrep "DNSKEY.*2" | grep -v "RRSIG" | wc -l)
  
  echo "${dnskeycount}" > $0.$1.saved.dnskeycount
  
  if [ "${dnskeycount}" != "${olddnskeycount}" ]; then
    err=1
    echo "Warning: Number of DNSKEY-Record has changed!"
  else
    echo "OK: Number of DNSKEY-Record is the same as with last test!"
  fi
  
  exit ${err}
  

• the DNSSEC monitoring system should write an audit trail of DNSSEC zone changes:
  • changes to the DNSKEY records (KEY-ID and SOA Serial of the change)
  • changes to the DS-Record (KEY-ID and SOA serial of the parent zone)

• DNSSEC tools from .SE TLD: https://github.com/dotse/dnssec-monitor
• Verisign jdnssec-tools http://www.verisignlabs.com/dnssec-tools/
• YAZVS — Yet Another Zone Validation Script http://yazvs.verisignlabs.com/
• ldns-verify from the LDNS package http://www.nlnetlabs.nl/projects/ldns/
• Nagval - Nagios Plugin by JP Mens https://github.com/jpmens/nagval
• Key-Checker - Monitors Key-Rollover https://github.com/bortzmeyer/key-checker
• Mess with DNS https://messwithdns.net/

Prometheus is a very popular application for event monitoring and alerting. It records metrics in real-time in a time-series database using an HTTP pull model. It's written in Go and is Open Source.

For monitoring BIND, Prometheus requires a so-called exporter which provides metrics which Prometheus consumes, and we'll use bind_exporter for doing so. bind_exporter has to access BIND's metrics which named will make available via its statistics-channels{} feature.

dig @localhost dnslab.org a       # NOERROR
dig @localhost xyz.dnslab.org a   # NXDOMAIN
dig @localhost fail02.dnssec.works a  # SERVFAIL