DNS & BIND 9

• 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

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

• 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
• Option 1: reload with the BIND 9 rndc tool

  % rndc reconfig
  

• Option 2: reload with systemctl

  % systemctl reload named
  

• Option 3: reload old Unix style

  % pkill -HUP named
  

• The original DNS protocol had a size limit for DNS messages over UDP of 512 bytes
  • The aim was to prevent fragmentation on the network path
    • esp. in the early days of TCP/IP, fragmentation was slow

• RFC 1035 states in 2.3.4. Size limits:

  UDP messages 512 octets or less

• and in section 4.2.1 UDP usage:

  Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers). Longer messages are truncated and the TC bit is set in the header.

• One artifact of the size limit of the original DNS protocol is the number of authoritative DNS servers for the root zone in the Internet (aka Root-Server)
  • There are 13 logical Root-Servers (a.root-servers.net to m.root-servers.net)
  • This is because without IPv6 and without the later EDNS0, 13 DNS names and IPv4 addresses fit nicely into the 512 byte limit
• The thirteen names

$ dig -4 @a.root-servers.net NS . +noedns +nodnssec

; <<>> DiG 9.16.7 <<>> -4 @a.root-servers.net ns . +noedns +nodnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19932
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15
[...]
;; ANSWER SECTION:
.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
.			518400	IN	NS	c.root-servers.net.
.			518400	IN	NS	d.root-servers.net.
.			518400	IN	NS	e.root-servers.net.
.			518400	IN	NS	f.root-servers.net.
.			518400	IN	NS	g.root-servers.net.
.			518400	IN	NS	h.root-servers.net.
.			518400	IN	NS	i.root-servers.net.
.			518400	IN	NS	j.root-servers.net.
.			518400	IN	NS	k.root-servers.net.
.			518400	IN	NS	l.root-servers.net.
.			518400	IN	NS	m.root-servers.net.
[...]
;; Query time: 37 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Mon Oct 26 10:14:30 CET 2020
;; MSG SIZE  rcvd: 492

• When a DNS server needs to send a DNS response message larger than the UDP size limit, it will send an incomplete response with the TC "Truncated" flag set in the DNS header
  • The DNS client (could be a DNS resolver), will detect the TC flag and will repeat the query over TCP
    • There is no size limit on DNS responses over TCP
    • But TCP is not as fast as UDP, so this should be avoided
• Because the DNS protocol can switch from UDP to TCP on larger responses (> 512 byte), DNS servers (authoritative as well as DNS resolvers) should always support DNS over TCP
  • And the firewall should allow DNS port 53 on UDP and TCP

$ dig -4 larger.dnssec.works TXT +noedns
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.16.7 <<>> -4 larger.dnssec.works txt +noedns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64327
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
[...]

• In the mid 1990ies, there was new development around the DNS protocol
  • DNS security (DNSSEC)
  • Cryptographic Signatures (TSIG and SIG(0))
  • IPv6 Resource records
  • DNS as a distribution channel for cryptographic keys for applications
• The 512byte limit was becoming a hindrance

• The IETF created an extension to DNS, called EDNS0
  • RFC 2671 Extension Mechanisms for DNS (EDNS0) (1999-08) and RFC 6891 (2013-04)
• EDNS Version 0 (EDNS0) allows DNS messages sizes over UDP for up to 4096 bytes

• Besides lifting the limit on the maximum DNS response size, EDNS allows for additional DNS flags and payload:
  • DNSSEC OK Flag (DO)
  • RFC 7314 Expire Option
  • RFC 7828 TCP Keepalive Option
  • RFC 7830 Padding Option
  • RFC 7873 DNS cookies
  • RFC 8145 Signaling Trust Anchor Knowledge in DNSSEC
  • RFC 8914 Extended DNS errors

• The current version of EDNS is version 0
  • There had been discussions in the IETF on newer EDNS versions (such as EDNS1 https://datatracker.ietf.org/doc/draft-andrews-edns1/)
  • But so far no new EDNS version has been standardized

• Increase the query limits of BIND 9 until the new code in BIND 9 is published

• Authoritative DNS Servers in the Internet should not return private IPv4 (RFC 1918) or private IPv6 Addresses (link-local, local multicast or unique-local addresses)
  • But some malicious DNS server do
  • With the help of JavaScript (or other active components inside webpages) this enables an attacker to circumvent the security barriers of web-browser to access local machines
    • This Rebind Attack is also used by some popular websites such as eBay: eBay port scans visitors' computers for remote access programs https://www.bleepingcomputer.com/news/security/ebay-port-scans-visitors-computers-for-remote-access-programs/
    • Kimwolf: current (2025/2026) botnet build on DNS rebinding attack https://krebsonsecurity.com/2026/01/the-kimwolf-botnet-is-stalking-your-local-network/

• See Protecting browsers from dns rebinding attacks https://dl.acm.org/doi/10.1145/1315245.1315298
• BIND 9 supports rebind protection since Version 9.7.0.
• The option deny-answer-addresses lists the address ranges that are considered private and should not be returned as part of an A/AAAA response, except for the zones listed in except-from:

options {
 [...]
 deny-answer-addresses {
    10.0.0.0/8;        // RFC 1918
    172.16.0.0/12;     // RFC 1918
    192.168.0.0/16;    // RFC 1918
    127.0.0.0/8;       // Loopback IPv4 (careful!)
    ::1/128;           // Loopback IPv6 (careful!)
    fe80::/10;         // IPv6 Link-Local
    fc00::/7;          // IPv6 Unique-Local
   }
   except-from {
     "example.com";
     "internal.example.net";
     "mylocalnet.example";
   };
};

• Care should be particularly taken if using this option for addresses within 127.0.0.0/8. These addresses are obviously "internal", but many applications conventionally rely on a DNS mapping from some name to such an address. Filtering out DNS records containing this address spuriously can break such applications.

• Classic DNS resolver implementations are very talkative
  • Data is requested/supplied which (today) is not necessarily required by the DNS protocol

• The options min-cache-ttl and min-ncache-ttl can be used on a global level to control the minimum time a resource record should be cached for. This will overwrite TTLs in the received DNS resource records that have a TTL lower than the configured values.
• min-cache-ttl - This sets the minimum time for which the server caches ordinary (positive) answers, in seconds. For convenience, TTL-style time unit suffixes may be used to specify the value. It also accepts ISO 8601 duration formats.
  • The default min-cache-ttl is 0 seconds. min-cache-ttl cannot exceed 90 seconds and is truncated to 90 seconds if set to a greater value.
• min-ncache-ttl - To reduce network traffic and increase performance, the server stores negative answers. min-ncache-ttl is used to set a minimum retention time for these answers in the server in seconds. For convenience, TTL-style time unit suffixes may be used to specify the value. It also accepts ISO 8601 duration formats.
  • The default min-ncache-ttl is 0 seconds. min-ncache-ttl cannot exceed 90 seconds and is truncated to 90 seconds if set to a greater value.

• Having a local mirror copy of the root zone can speed up name resolution
  • It also helps with the privacy of DNS queries
• BIND supports a local copy of the root zone as defined in RFC 8806 "Running a Root Server Local to a Resolver"
• A default list of primary servers for the root zone is built into named, allowing the primaries statement to be omitted when configuring an IANA root zone mirror.

// Root Mirror Zone
zone "." {
        type mirror;
        file "root.zone";
};

• RFC 8767 - "Serving Stale Data to Improve DNS Resiliency" (March 2020) allows DNS resolver to keep and return cache entries that have expired (cached longer than their TTL) in case none of the zones authoritative DNS server can be reached.
  • This mitogates certain denial of service attacks against authoritative DNS servers and makes these attacks less attractive.
  • This RFC also suggest that DNS resolver should cap the maximum TTL for DNS resource records to 7 days.

• These are all the RRL option settings.

options {
  rate-limit {
    all-per-second <integer>;
    errors-per-second <integer>;
    exempt-clients { <address_match_element>; ... };
    ipv4-prefix-length <integer>;
    ipv6-prefix-length <integer>;
    log-only <boolean>;
    max-table-size <integer>;
    min-table-size <integer>;
    nodata-per-second <integer>;
    nxdomains-per-second <integer>;
    qps-scale <integer>;
    referrals-per-second <integer>;
    responses-per-second <integer>;
    slip <integer>;
    window <integer>;
  };
};

• rate-limit enables RRL. Default=0 (disabled)
• A bucket will be limited to 10 identical responses before rate-limiting is enforced.
  • Beyond 10: 1 query dropped, 1 truncated. (See slip).

options {
   rate-limit {
     responses-per-second 10;
   };
   [...]
};

• This is a perfectly valid configuration.
  • All other RRL settings have their default values.

• log-only disables RRL, but logs as if it were running.
  • Default=no
• The option is recommended before enabling RRL.
  • Use it to determine a responses-per-second value that doesn't limit normal querying.

rate-limit {
     responses-per-second 10;
     log-only yes;
};

• Slip sets if RLed queries are dropped or truncate.
  • It lets a legitimate IP get responses, even when it is being spoofed.
    • slip 0; drop all RLed queries. (Bad for legitimate clients.)
    • slip 1; Answer all RLed queries with TC=1. (All slip.)
    • slip 2; Slip every other query. (drop, truncate, drop,…)
    • slip 3; (drop, drop, truncate, drop, drop, truncate,…)

rate-limit {
      responses-per-second 10;
       slip 2;
};

• Buckets of grouped IP addresses.
  • Smaller buckets with fewer IPs, allow finer RRL control, but require more memory.
  • ipv4-prefix-length 32; would require tracking of every client independently and need a lot of memory.
  • The defaults of 24 and 56 reasonable.

rate-limit {
      responses-per-second 10;
       ipv4-prefix-length 24;
       ipv6-prefix-length 56;
};

• Rate limit a bucket to an absolute number of UDP queries.
  • Any responses, not only identical ones.
  • Slip is ignored. All queries over the limited are dropped.
  • Use with caution, clients can send a lot of independent valid queries.
  • The default is 0: disabled

rate-limit {
  all-per-second 50;
};

• Response tracking time-range, a rolling window.
  • Most importantly, it works as recovery time.
  • How long after a tripped rate-limiter goes below its threshold, before rate-limiting stops limiting.
  • The default, 15 seconds, is reasonable.

rate-limit {
      responses-per-second 10;
      slip 3;
      window 15;
};

• BIND has a rate-limit logging category.
  • The onset and end of rate-limiting are logged.
  • Periodic messages are logged in between.
  • The logging of rate-limiting ending is delayed ~60s.
  • Logging is at severity info.

logging {
  channel rrl { <OUTPUT SUPPRESSED>; };
  <OUTPUT SUPPRESSED>;
  category rate-limit { rrl; };
 };

• Sample log (formatted)

29-Aug-2018 19:40:58.250 would limit responses to 192.168.53.0/24
                         for zulu.zoneNNN.dnslab.org IN A  (0e0b52d9)
29-Aug-2018 19:40:58.250 client @0x7fb9a00c0010
                         192.168.53.252#59979 (zulu.zoneNNN.dnslab.org):
                         would rate limit slip response to 192.168.53.0/24
                         for zulu.zoneNNN.dnslab.org IN A  (0e0b52d9)
29-Aug-2018 19:40:58.258 client @0x7fb9a00c0010
                         192.168.53.252#54990 (zulu.zoneNNN.dnslab.org):
                         would rate limit drop response to 192.168.53.0/24
                         for zulu.zoneNNN.dnslab.org IN A  (0e0b52d9)

• QNAME: The queried domain-name triggers the policy.
  • This is the most common trigger.
  • No special label is required for the owner name.
• Client IP: The client's address triggers the policy.
  • The label .rpz-client-ip is used in the owner name.

• Response IP: The IP address in the RR triggers the policy.
  • This is only applicable to A & AAAA RRs.
  • It is only applicable to the Answer section of the DNS message.
  • The label .rpz-ip is used in the owner name.

• NSDNAME: Any NS referral in the path to getting a final response triggers the policy.
  • The label .rpz-nsdname is used in the owner name.
• NSIP: An IP address of a NS in the path of getting a final response triggers the policy.
  • The label .rpz-nsip is used in the owner name.

• Six actions are available when a policy is triggered:
  • Respond with local data trapping the query in a walled garden. (Most commonly this is a CNAME.)
  • Respond NXDOMAIN
  • Respond NOERROR/NODATA
  • Respond normally (passthru)
  • Respond with the TC flag
  • Drop the query
• The bold actions are most common.
• When more than one action could apply (e.g. NXDOMAIN and passthru), precedence rules select which is used. The rules are beyond the scope of this course.

• RPZ in named.conf

  options {
   [...]
   response-policy {
     zone "rpz-z01";
   }; // up to 32 RPZs
   [...]
  };
  
  [...]
  zone "rpz-z01" {type primary; file "rpz-z01.file";};
  [...]
  

• The response policy zone is not delegated and NS RRs are unused.
  • The draft RFC recommends the convention of using localhost.
• Other than the MNAME, all fields in the SOA should be valid and reasonable for the sake of any secondary using the RPZ.

$TTL 1h
$ORIGIN rpz-z01.
@  SOA localhost. pm.example.com. 1 4h 1h 8w 1h
   NS  localhost.

• The domain name below is being declared disreputable.
  • The owner names should NOT be FQDNs!
• A CNAME to the root, ., is RPZ's code for an NXDOMAIN action.

  $TTL 1h
  $ORIGIN rpz-z01.
  @                     SOA localhost. pm.example.com. 1 4h 1h 8w 1h
                        NS  localhost.
  evilstuff.com         CNAME        .      ; NXDOMAIN
  

• Wildcards usage in RPZ files is common.
  • Also match everything under evilstuff.com.

  *.evilstuff.com       CNAME .      ; NXDOMAIN
  

• A CNAME to *. is RPZ's code for a NODATA action.

  badplace.us           CNAME *.     ; NOERROR/NODATA
  *.badplace.us         CNAME *.     ; NOERROR/NODATA
  

• Local Data is a standard RR without any special RPZ encoding. Most commonly, a CNAME is used to point to a walled garden.

  vile.org              CNAME fbi.gov. ; redirect
  *.vile.org            CNAME fbi.gov. ; redirect
  

• A CNAME to the RPZ special target rpz-drop. makes the RDNS server to simply drop the query (no response is sent).
  • The querier will eventually time-out.

  yuck.reddit.com       CNAME rpz-drop.     ; drop
  

• A CNAME to the RPZ special target rpz-tcp-only. makes the DNS resolver server set the TC flag (truncated) in the response.
  • A legitimate querier will re-query over TCP. This is another tool to mitigate reflection attacks.

  innocent.com          CNAME rpz-tcp-only. ; truncate
  *.innocent.com        CNAME rpz-tcp-only. ; truncate
  

• To trigger on the querier's IP, use the .rpz-client-ip encoding. The IPv4 address is reversed like in a PTR RR, but an additional first label indicates the netmask.

  16.0.0.31.172.rpz-client-ip        CNAME   rpz-passthru.
  12.0.0.16.172.rpz-client-ip        CNAME   rpz-drop.
  32.1.0.0.127.rpz-client-ip         CNAME   rpz-passthru.
  

  • Drop traffic from all class B private clients 172.16/12 except the 172.31/16 block which is not subject to any policies. The 127.0.0.1 host is also except for policies, which is useful for testing.
• IPv6 addresses are reversed per four hex-digit field. Colons are replaced by periods. The double-colon for zero compression with "zz". Zero suppression and zero compression are required. The addresses shown are: 2001:db8:bad::/64 ::1/128

  64.zz.bad.db8.2001.rpz-client-ip   CNAME   rpz-drop.
  128.1.zz.rpz-client-ip             CNAME   rpz-passthru.
  

• If the given IP addresses appear in A or AAAA answer sections, an action is triggered.
  • In the example, the IPs are associated with dangers on the Internet, and get an NXDOMAIN response. 192.0.2.99/32 2001:db8:ea::/48

  32.99.2.0.192.rpz-ip               CNAME   .   ; NXDOMAIN
  48.zz.ea.db8.2001.rpz-ip           CNAME   .   ; NXDOMAIN
  

• If a referral contains ns1.badactor.ch or a referral's A RR is 198.51.100.1, the response will be NXDOMAIN.

  ns1.badActor.ch.rpz-nsdname        CNAME   .   ; NXDOMAIN
  32.1.100.51.198.rpz-nsip           CNAME   .   ; NXDOMAIN
  

• the full RPZ zone with different trigger and actions

$TTL 1h
$ORIGIN rpz-z01.
@ SOA localhost. pm.example.com. 1 4h 1h 8w 1h
  NS  localhost.
evilstuff.com         CNAME .                             ; NXDOMAIN
*.evilstuff.com       CNAME .                             ; NXDOMAIN
badplace.us           CNAME *.                            ; NOERROR/NODATA
*.badplace.us         CNAME *.                            ; NOERROR/NODATA
vile.org              CNAME fbi.gov.                      ; redirect
*.vile.org            CNAME fbi.gov.                      ; redirect
yuck.reddit.com       CNAME rpz-drop.                     ; drop
innocent.com          CNAME rpz-tcp-only.                 ; truncate
*.innocent.com        CNAME rpz-tcp-only.                 ; truncate
16.0.0.31.172.rpz-client-ip        CNAME   rpz-passthru.  ; permit
12.0.0.16.172.rpz-client-ip        CNAME   rpz-drop.      ; drop
32.1.0.0.127.rpz-client-ip         CNAME   rpz-passthru.  ; permit
64.zz.bad.db8.2001.rpz-client-ip   CNAME   rpz-drop.      ; drop
128.1.zz.rpz-client-ip             CNAME   rpz-passthru.  ; permit
32.99.2.0.192.rpz-ip               CNAME   .              ; NXDOMAIN
48.zz.ea.db8.2001.rpz-ip           CNAME   .              ; NXDOMAIN
ns1.badActor.ch.rpz-nsdname        CNAME   .              ; NXDOMAIN
32.1.100.51.198.rpz-nsip           CNAME   .              ; NXDOMAIN

• ioc2rpz community is a portal which provides free of charge DNS Firewall (or Response Policy Zone) feeds: https://ioc2rpz.net/
• The site https://dnsrpz.info maintains a list of providers of reputation data.
  • Different techniques are used to access the feed.
  • For example SpamHaus makes it available via zone transfer (AXFR/IXFR).
• Prices vary. Since 2018-02 SpamHaus has a free but very limited service: https://www.spamhaus.org/news/article/669

• Limited RPZ functionality is available without RPZ.
  • A DNS resolver server can be authoritative for zones to block or wall garden.
    • If there are 1000 zones, the server must be authoritative for all 1000.
    • With RPZ, only one zone is required.

• The following types must not be RPZ data:
  • SOA, NS, DNAME, all DNSSEC related records
• The logging category is rpz:

  category "rpz" { [...] };
  

• For dynamic DNS updates (DDNS), .rpz must be added at the end of the owner name if RPZ special labels are used:

  $TTL 30
  32.1.2.3.10.rpz-client-ip.rpz 30 CNAME rpz-passthru.
  

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

• Example BIND 9 query logging (BIND 9.16.21)

2021-11-10T11:49:36.349 info: client @0x770784d4 192.0.2.38#55719 (doh.defaultroutes.de): query: doh.defaultroutes.de IN A -E(0)D (192.0.2.212) [ECS 100.64.149.0/24/0]
2021-11-10T11:49:38.915 info: client @0x770784d4 100.64.15.30#40121 (doh.defaultroutes.de): query: doh.defaultroutes.de IN A -E(0)DC (192.0.2.212)
2021-11-10T11:49:39.195 info: client @0x770784d4 192.0.2.38#20977 (doh.defaultroutes.de): query: doh.defaultroutes.de IN AAAA -E(0)DC (192.0.2.212)
2021-11-10T11:49:39.347 info: client @0x770784d4 100.64.1.244#63082 (doh.defaultroutes.de): query: doh.defaultroutes.de IN A -E(0)D (192.0.2.212)
2021-11-10T11:49:41.455 info: client @0x770784d4 192.0.2.34#38949 (mailop.org): query: mailop.org IN A -E(0)DC (192.0.2.212) [ECS 100.64.2.0/24/0]
2021-11-10T11:49:41.809 info: client @0x770784d4 192.0.2.85#14795 (doh.defaultroutes.de): query: doh.defaultroutes.de IN A -E(0)D (192.0.2.212)

• The fields in one line of query log data

• 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)
  • The HTTPS and SVCB records are discussed in RFC 9460 "Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)" https://datatracker.ietf.org/doc/html/rfc9460
• 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 tool named-checkconf checks the syntax of the main configuration file named.conf
• Usage: named-checkconf [filename]
• The default file is named.conf in the sysconfdir when named was built

% named-checkconf /etc/named.conf
/etc/named.conf:10: missing ';' before 'zone'
/etc/named.conf:14: missing ';' before end of file

• named-checkconf -z also checks primary zone files.

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

• 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

• BIND's remote control tool, rndc, may use TSIG for authentication.
  • rndc-confgen creates a template configuration including keys.

• A TSIG can be used to secure zone transfers (e.g. primary to secondary).
  • The key must be configured on the server providing the zone and the server transferring it in.

key prim-sec-example.com {
	algorithm hmac-sha256;
	secret "pDCQLRGpPN0h9ksqHBnGBra3U15QwlpQI5aPNO5d5xE=";
};

zone "example.com" {
 type primary;
 file "example.com";
 allow-transfer { key prim-sec-example.com; };
};

• Note that both the key, and the key-name, must match on the sender and receiver.

key prim-sec-example.com {
	algorithm hmac-sha256;
	secret "pDCQLRGpPN0h9ksqHBnGBra3U15QwlpQI5aPNO5d5xE=";
};

# secondary zone
zone "example.com" {
 type secondary;
 file "example.com";
 primaries { 192.0.2.53 key prim-sec-example.com; };
};

• TSIGs can be use to secure all communication between servers (queries, notifies, zone-transfers …):

  key server1-server2 {
  	   algorithm hmac-sha256;
  	   secret "pDCQLRGpPN0h9ksqHBnGBra3U15QwlpQI5aPNO5d5xE=";
  };
  
  server 192.0.2.53 {   # <-- IP Address of the remote DNS server
    keys { server1-server2; };
  };
  

• On a primary authoritative server, allow-update {}; enables DDNS.
  • It also limits the updates to specifics keys or addresses.
  • Using a symmetric key (TSIG) is more secure, but IP addresses can be provided instead.

zone "example.com" {
	type primary;
	file "example.com";
	allow-update { key dhcp-server; };
};

• The allow-update clause is coarse, allowing DDNS to a zone completely, or not at all.
  • Complex policies are possible with update-policy.
    • Each update-policy allows DDNS for a set of RRs.

zone "example.com." IN {
    type primary;
    file "masters/example.com-zone";
    update-policy {
	    grant ddns-key zonesub ANY;
    };
};

• There are three update options for the SOA in dynamic zones:
  • serial-update-method ( date | increment | unixtime );
    • increment: simple bump (the default).
    • date: YYYYMMDDnn. nn starts at zero and increments.
    • unixtime: standard unixtime in seconds.
• The statement can be global in options { } or view { }, or specific to a zone { }.

• To avoid constant rewriting of the zone file, a BIND primary instead writes changes to a journal file:
  • The journal is known as a log and is not plain-text.
  • The journal's file name is the zone's, appended with .jnl.
  • The name and the max size of a journal are configurable.

zone "example.com" {
   type primary;
   file "example.com";
   allow-update { key dhcp-server; };
   journal "/fast-disk/example.com.jnl"
   max-journal-size 200M;
};

• The journal allows the server to recover the most recent version of the zone after a crash.
  • After loading the zone file, the server loads the journal.
  • A journal can be viewed with: named-journalprint <journalfile>
• Each line adds or deletes one RR.

% named-journalprint zone02.dnslab.org.jnl
del zone02.dnslab.org.	30	IN	SOA	server02.dnslab.org. hm.zone02.dnslab.org. 2016011308 7200 3600 5184000 30
del me.zone02.dnslab.org.	30	IN	TXT	"my birthday!  go me!"
add zone02.dnslab.org.	30	IN	SOA	server02.dnslab.org. hm.zone02.dnslab.org. 2016013100 7200 3600 5184000 30
add me.zone02.dnslab.org.	30	IN	TXT	"hi there"

• Periodically, an authoritative server writes the zone from memory to the zone file.
  • BIND writes 15 minutes after receiving an update.
  • When the primary writes the file, the format changes dramatically: the order is changed, comments are gone, and variable directives are gone.
• The logging category for dynamic updates: update

• Manual changes to a dynamic zone file are lost when the zone file is written!
  • The changes are never used in query responses.
• Manual changes can be made by freezing a zone, however freezing disabled DDNS!
  • Freezing should generally be avoided.
  • Use nsupdate to make changes to a dynamic zone.

• nsupdate is a BIND application for sending dynamic changes to a server.
  • It works both interactively and non-interactively.
  • In both modes, commands are one-per-line.
• The three main commands are:
  • update add
  • update delete
  • send
• update prepares RRs changes, send executes them.
• Note: ENTER by itself is the same as send
• Non-interactively, commands come from a file or STDIN.

$ nsupdate nsupdate.input.file

$ nsupdate < nsupdate.input.file

• Interactive mode:

$ nsupdate
>

• The interactive command show allows changes to be reviewed before being sent.
  • Here no updates have been prepared.

$ nsupdate
> show
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
>

• update add prepares a RR to be added to a zone.
  • All fields, except the Class must be provided.
  • TTL can be provided in a separate statement.

> update add a.example.com IN A 192.0.2.1
ttl 'IN': not a valid number
> update add a.example.com 3600 IN A 192.0.2.1
> ttl 3600
> update add a.example.com AAAA 2001:db8:0:deaf::1
> show
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
a.example.com.		3600	IN	A	192.0.2.1
a.example.com.		3600	IN	AAAA	2001:db8:0:deaf::1
> send

• update delete prepares RRs to be deleted.
  • Class is optional, and TTL, if provided, is ignored.
  • Providing all fields except TTL and Class deletes one RR.

> update delete b.example.com. 1800 A 192.0.2.99
> update delete example.net. MX 15 mailserver.example.net.
> show
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
b.example.com.		0	NONE	A	192.0.2.99
example.net.		    0	NONE	MX	15 mailserver.example.net.

• update delete Providing the RTYPE without RDATA, deletes a RRSet.

> update delete b.example.com. AAAA
> update delete c.example.com IN SRV
> show
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
b.example.com.		0	NONE	A	192.0.2.99
example.net.		  0	NONE	MX	15 mailserver.example.net.
b.example.com.		0	ANY	AAAA
c.example.com.		0	ANY	SRV
>

• update delete Omitting RTYPE and RDATA deletes all RRSets.

> update delete d.example.com.
> show
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
b.example.com.		0	NONE	A	192.0.2.99
example.net.	    0	NONE	MX	15 mailserver.example.net.
b.example.com.		0	ANY	AAAA
c.example.com.		0	ANY	SRV
d.example.com.		0	ANY	ANY

• Since BIND 9.9.0, the key word update is optional.

> delete  www.example.com. A
> add www.example.com. 600 A 192.0.2.80
> add www.example.com. 600 A 192.0.2.88

• send - Transmit the prepared updates to the authoritative server.
  • WARNING - hitting ENTER is the same as send!

> send

• answer - shows the results received from the server after a send.

> send
update failed: REFUSED
> answer
Answer:
;; ->>HEADER<<- opcode: UPDATE, status: REFUSED, id:  13117
;; flags: qr; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
>

• prereq nxdomain <domain name> - requires that "domain name" doesn't exist (no RRs of any type).

> prereq nxdomain www.example.com
> update add www.example.com 3600 CNAME example.com.
> send

• prereq yxdomain <domain name> - requires that "domain name" does exist.

> prereq yxdomain www.example.com
> update add web.example.com 3600 CNAME www.example.com.
> send

• server <servername or IP> [port] - specifies the authoritative server that will receive the update.
  • If not set, nsupdate uses MNAME from the SOA RR and port 53.
  • Generally, updates should be sent to the primary authoritative server.

> server ns0.example.com

• nsupdate -l sends all updates to localhost.
  • The MNAME is not checked, and server commands are ignored.
  • This is easy use, and is recommended if you are on the primary server
• local <IP address> [port] - specifies the outgoing IP address. This is useful for multi-homed machines, especially when IPv6 is used, and when the server limits updates to specific IPs.

> local 2001:db8:100:0:ff:aa01:42:12:feaa

• zone <zonename> - specify the zone to be changed.
  • This is necessary when the update is an NS or glue RR to be made in the parent zone.

$ nsupdate
> zone example.com.
> update add ns1.subdomain.example.com. 3600 IN A 192.0.2.53
> update add ns2.subdomain.example.com. 3600 IN A 203.0.113.53
> send

• ddns-confgen generates a TSIG configuration for secure dynamic updates (e.g. nsupdate).

> ddns-confgen
# To activate this key, place the following in named.conf, and
# in a separate keyfile on the system or systems from which nsupdate
# will be run:
key "ddns-key" {
	algorithm hmac-sha256;
	secret "kDyXolMZX2YyGjiRm008GOr4NFnZ5drrvLA0owKbLZo=";
};

# Then, in the "zone" statement for each zone you wish to dynamically
# update, place an "update-policy" statement granting update permission
# to this key.  For example, the following statement grants this key
# permission to update any name within the zone:
update-policy {
	grant ddns-key zonesub ANY;
};

# After the keyfile has been placed, the following command will
# execute nsupdate using this key:
nsupdate -k <keyfile>

• NOTIFY allows a primary authoritative server to inform its secondaries when a zone changes.
  • The secondary accept NOTIFY as a "pop" of the refresh timer.
• Therefore secondary servers typically transfer a zone far more frequently.
  • For large zones, this generates a huge amount of traffic.
  • For a very large zone, a transfer might not complete before the next dynamic update and the next NOTIFY!
• Each update to a zone can increment the serial number thereby triggering a NOTIFY.
• A server with the primary zone determines which servers are secondaries by looking at the zone's NS RRset.
  • A name in the NS RRSet that matches the MNAME, is not sent a NOTIFY.
• When a secondary receives a NOTIFY, it checks:
  • that it is for a zone for which it is authoritative.
  • that it came from a primary server for the zone.
  • that the SOA serial has increased.
• If the NOTIFY is accepted, the secondary immediately schedules a refresh of the zone.
• The secondary sends a NOTIFY to the other secondary servers.

  

• An Incremental Zone Transfer (IXFR) allows a client to query just the changes since a previous version.
  • This generally reduces the size (and duration) of the transfer considerably.
  • Like AXFRs (full zone transfer), IXFRs are sent to authoritative servers.
  • BIND secondaries and primary servers request and provide IXFRs by default.
• A server querying an IXFR sends a previous serial number for the zone.
  • For a secondary, this is its current serial number.
  • Secondary: "send me changes since version 14284171."
• The queried server responds with all changes since the IXFR's serial number.

• The next examples show BIND's response to an IXFR after the following update.
  • RFC 1995 allows several formats for the IXFR response

$ dig +short SOA dnslab.org
authoritative.dnslab.org. hostmaster.dnslab.org. 2013081127 7200 1800 3542400 30

% nsupdate -l
> update add zzz.dnslab.org 30 TXT "Zees"
> send
> quit

• Query with a known previous serial number.
  • IXFR responses always start with the current (newest) SOA RR. This is the same as AXFR.
  • IXFR responses always end with the current (newest) SOA RR. This is the same as AXFR.

$ dig +noall +answer dnslab.org ixfr=2013081127 @::1 | grep -Ev 'RRSIG|NSEC'
dnslab.org.		40	IN	SOA	authoritative.dnslab.org. hostmaster.dnslab.org. 2013081128 7200 1800 3542400 30
dnslab.org.		40	IN	SOA	authoritative.dnslab.org. hostmaster.dnslab.org. 2013081127 7200 1800 3542400 30
dnslab.org.		40	IN	SOA	authoritative.dnslab.org. hostmaster.dnslab.org. 2013081128 7200 1800 3542400 30
zzz.dnslab.org.		30	IN	TXT	"Zees"
dnslab.org.		40	IN	SOA	authoritative.dnslab.org. hostmaster.dnslab.org. 2013081128 7200 1800 3542400 30

• The second RR is always a SOA to delete. It is followed by additional RRs to delete (none in this case.)
  • This section continues until another SOA RR.
• After a section of deletes, comes a sections of adds that always begins with a SOA.
  • In this case there are two additions.

$ dig +noall +answer dnslab.org ixfr=2013081127 @::1 | grep -Ev 'RRSIG|NSEC'
dnslab.org.		40	IN	SOA	authoritative.dnslab.org. hostmaster.dnslab.org. 2013081128 7200 1800 3542400 30
dnslab.org.		40	IN	SOA	authoritative.dnslab.org. hostmaster.dnslab.org. 2013081127 7200 1800 3542400 30
dnslab.org.		40	IN	SOA	authoritative.dnslab.org. hostmaster.dnslab.org. 2013081128 7200 1800 3542400 30
zzz.dnslab.org.		30	IN	TXT	"Zees"
dnslab.org.		40	IN	SOA	authoritative.dnslab.org. hostmaster.dnslab.org. 2013081128 7200 1800 3542400 30

• The following example shows how BIND responds to an IXFR covering several versions.
• Example: A zone is at version 2. Not including SOA changes:
  • One RR is added. Now version 3.
  • One RR is deleted. Two added. Now version 4.
  • Two RR deleted. Now version 5.
  • Only the SOA is changed. Now version 6.

dig @<Auth-Server> <Domain-Name>  ixfr=2

FQDN [...]  SOA 6 7200 3600 5184000 30
FQDN [...]  SOA 2 [...]
FQDN [...]  SOA 3 [...]
FQDN [...]
FQDN [...]  SOA 3 [...]
FQDN [...]
FQDN [...]  SOA 4 [...]
FQDN [...]
FQDN [...]
FQDN [...]  SOA 4 [...]
FQDN [...]
FQDN [...]
FQDN [...]  SOA 5 [...]
FQDN [...]  SOA 5 [...]
FQDN [...]  SOA 6 [...]
FQDN [...]  SOA 6 7200 3600 5184000 30

• BIND authoritative servers use the journal to identify the changes necessary to respond to an IXFR.
  • A non-dynamic zone, doesn't have a journal.
  • Use ixfr-from-differences yes; in a zone stanza to create a journal for a non-dynamic zone.

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

• Adding or deleting new zones can be a challenge.
• In addition to updating the primary, every secondary needs to be modified.
• It is intensive work for installations with many secondaries, or with frequent zone additions & deletions.
• Many organizations have written scripts (or use tools like Ansible or SaltStack) for automatically modifying secondary DNS servers.
• A catalog zone provisions normal zones using standard DNS content and communication.
  • They are an ISC creation, new in BIND 9.11 (2016), and have been standardized by the IETF.
  • RFC 9432: DNS Catalog Zones
  • In addition to BIND 9, KnotDNS already has a fully functional implementation since version 3.0.0 (September 2020)
  • PowerDNS Authoritative Server supports catalog zones since 4.7.0 (https://doc.powerdns.com/authoritative/catalog.html)
  • NSD: supports RFC 9432 style catalog zones since version 4.9.0 (https://nsd.docs.nlnetlabs.nl/en/latest/catalog-zones.html)

• A catalog zone works like a normal DNS zone.
• A catalog zone is maintained on the primary server.
• It contains zone names and configuration metadata that should exist on secondaries.
• Zones added to the catalog zone are automatically provisioned on secondaries.
  • Zones in a catalog zone are member zones.
• A primary hosting a catalog zone, does not need to be updated to BIND 9.11 or later.
  • This is because catalog zones use standard DNS content and communication.
  • Secondaries need to be updated so they will use a catalog zone's content as provision information.
• A secondary will have a catalog zone for each primary.
  • Assuming the primary is configured with a catalog zone.

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

• A server needs to select which view to send to which clients.
• Each view has a match-clients ACL identifying which IP addresses associated with the view.
• A view without match-clients is a match for all IP addresses, equivalent to: match-clients { any; };
• The order of views in named.conf is critical.
  • A querier's source address is compared with match-clients of the first view, second, and so on.
  • When a match is found, that view is used.

options {
	    directory "/var/named";
	    recursion no;
};

acl internal-network  { !192.168.1.11; 192.168/16; };

view internal-view {
	    match-clients { internal-network; };
	    recursion yes;
	    zone "example.com" {
		    type primary;
		    // zone with private RFC 1918 addresses
		    file "internal/example.com-zone";
	    };
};

view external-view {
	    match-clients { any; };

	    zone "example.com" {
		    type primary;
		    // zone containing the public IP addresses
		    file "external/example.com-zone";
	    };
};

• A secondary without a view statement receives the one view that matches its source address.
  • A secondary not matching any view isn't sent any data.
• Secondaries hosting multiple views, adds to the complexity of zone-transfer configuration.
• To transfer multiple views a different TSIG key is used for each view or each zone.
• transfer-source and transfer-source-v6 set a secondaries IP address zone-transfer query.

• When changing a primary's server view, check if the change is required on the secondary as well.
  • named.conf is not transferred between servers.
  • View configuration must be synchronized manually.
• If a zone in multiple views share identical RRs, use $INCLUDE.
• Troubleshoot and test zone transfers with dig:

dig -b source.address @server example.com AXFR

• Example $INCLUDE usage with views:
  • Zonefile internal/example.com-zone

    $INCLUDE example.com-common
    dns1	  IN A	10.1.1.1
    mail	  IN A	10.1.2.10
    ldap	  IN A	192.168.1.100
    

  • Zonefile external/example.com-zone

    $INCLUDE example.com-common
    dns1	  IN A	192.0.2.1
    mail	  IN A	192.0.2.1
    ldap	  IN A	192.0.2.10
    

  • File example.com-common

    @		     IN SOA	dns1 hostmaster 2005010100 1d 2h 41d 1h
    @		     IN NS	dns1
    @		     IN MX	10 mail
    _ldap._tcp	IN SRV	0 0 ldap
    

• 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
  • https://dnsaudit.io

• 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

• opcode: query, notify, update, DSO … see IANA registry for DNS OpCodes
• status/rcode:
  • NOERROR - the operation was successful
  • NXDOMAIN - the domain name requested does not exist (or is not delegated)
  • SERVFAIL - some remote DNS server failure or DNSSEC validation failure
  • FORMERR - the query was not correct DNS
  • REFUSED - this server has an access control list that forbids the answer to this client
  • NOTIMPL - a feature used/requested that this server does not implement
  • BADCOOKIE - Bad/missing Server Cookie

  … see IANA registry for DNS RCODEs

• queryid: 16bit value to sort DNS answers to DNS queries
• flags: information on the query and the answer (see IANA registry for DNS Header Flags)
  • AA authoritative answer - answer is coming directly from an authoritative server
  • TC truncated - answer does not fit into the advertised UDP packet size, please re-query over TCP
  • RD recursion desired - this is a query from a client machine, please provide a full complete answer (no referral please)
  • RA recursion available - this answer comes from a DNS resolver that is willing to accept queries with RD flag set
• DNSSEC flags: AD- and CD-Flag
  • AD authentic data - the DNS resolver sending this answer has performed a successful DNSSEC validation on the data. If we trust the resolver, we can trust the data
  • CD checking disabled - a client asking a DNSSEC validating DNS resolver to not perform DNSSEC validation but to pass all DNSSEC data unaltered (even if the data is invalid). Used for troubleshooting DNSSEC issues.
• QUERY: number of query resource records (usually one)
• ANSWER: count of DNS resource records in the answer. Can be more than one. Can be zero if no data is available for the query.
• AUTHORITY: number of authority records in the answer. Can be a SOA-Record (for negative answers) or NS-Records for referrals or positive answers. Many modern DNS server only fill the authority section if required by the protocol to keep answer packets small
• ADDITIONAL: additional resource records that not have been requested but might help with the name resolution, and the EDNS (Extended DNS) OPT-Record (see RFC 6891 Extension Mechanisms for DNS (EDNS(0))

• EDNS Version 0 is the current version
  • new Versions are being discussed in the IETF
• additional EDNS flags. DO - DNSSEC OK, this DNS client supports DNSSEC records
• maximum UDP answer packet size in byte as negotiated between dig and the DNS server/resolver. Current default is 4096, must be between 512 and 4096. The default changed to 1232 on DNS flag day 2020
• RFC 8914 - Extended DNS Errors defines a way to deliver additional error information in an DNS response. It is already implemented in the latest versions of dig since version BIND 9.16.4. Some DNS resolver on the Internet (like Cloudflare) do support EDE messages:

  

• The answer section contains zero (if there is no data available), one or more DNS resource records that match the query

• if present, the authority section contains the authoritative name server that hosts the content delivered in the answer. For negative (NXDOMAIN/NOERROR-NODATA) answers, the authority section contains the SOA record of the zone that is authoritative for the negative answer.

• if present, the additional section contains additional DNS records that have not been explicitly requested, but might help in the name resolution process. Because the additional section can be misused in attacks, modern DNS server software minimizes the additional section data.
• If EDNS data is available, it is also in the additional section, but dig displays this data in the OPT pseudo-section

• the footer contains the size (in bytes) of the answer packet, the DNS server that has send the answer, the time it took to receive the answer and the time and date of the DNS communication

• usually dig sends the query to the DNS resolver configured in the operating system (file /etc/resolv.conf on Unix/Linux)
• with the @ syntax the query can be sent to other DNS servers (resolver or authoritative server)

• command line switches can alter the query sent by dig.
  • +multi formats the output in human readable form (wrapped for 80 column terminal)
  • +norec sends a query without RD flag (non-recursive or iterative query)

• the switch +dnssec requests DNSSEC data from the upstream server
• the switch +cd sends the CD (checking disabled) flag to disable upstream DNSSEC validation (if the target of the query is a DNS resolver)

• dig can initiate a zone transfer from an authoritative server that contains the zone database (primary or secondary server)
• the data is printed in the Master Zone Format and can be used to start a new zone database file
• Example: list top level domains with DNSSEC delegation:

  $ dig @f.root-servers.net AXFR . +noidnout | \
    grep DS | \
    grep -v RRSIG | \
    cut -d "." -f 1 | \
    uniq
  

Day 2

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

• $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!