A technical reference for the Domain Name System and the Berkeley Internet Name Domain — protocols, configuration, record types, security, and troubleshooting.
Understanding the phone book of the internet
The Domain Name System (DNS) is a hierarchical, distributed database that translates human-readable domain names (such as example.com) into machine-readable IP addresses (such as 93.184.216.34). Without DNS, users would need to memorize numeric IP addresses for every website they visit.
DNS data is not stored in one place. It is distributed across millions of name servers worldwide. No single server holds all DNS records — each is authoritative for its own portion (zone) of the namespace.
The DNS namespace is organized as an inverted tree. The root is at the top, followed by Top-Level Domains (TLDs), second-level domains, and so on. Each level delegates authority to the level below it.
DNS resolvers cache responses based on the TTL (Time To Live) value. This dramatically reduces query load and latency. Most DNS lookups are resolved from cache without contacting authoritative servers.
DNSSEC adds cryptographic signatures to DNS records, allowing resolvers to verify that responses have not been tampered with. This protects against cache poisoning and man-in-the-middle attacks.
libc) that sends DNS queries from applications. It typically forwards queries to a configured recursive resolver.8.8.8.8) that resolves queries on behalf of clients by traversing the DNS tree from root to authoritative.A tree rooted at a single dot
. (root)
│
┌─────────────────┼─────────────────┐
│ │ │
.com .org .net
│ │ │
┌─────┼─────┐ ┌───┴───┐ ┌───┴───┐
│ │ │ │ │ │ │
google example amazon wikipedia apache cloudflare ...
│ │ │
┌──┴──┐ │ ┌──┴──┐
│ │ │ │ │
www mail www en de
│ │ │ │ │
A rec MX A rec A rec A rec
Every fully qualified domain name (FQDN) ends with a dot representing the root. When you type www.example.com, the FQDN is actually www.example.com. (with trailing dot). Each label between dots can be up to 63 characters long, and the total FQDN can be up to 253 characters.
The root zone is managed by IANA (under ICANN) and served by 13 root server identities (A.root-servers.net through M.root-servers.net). In reality, these are distributed across 1,700+ instances worldwide using anycast routing. The root zone file is relatively small and only contains delegations to TLD servers.
TLDs fall into several categories: gTLDs (generic: .com, .org, .net, .info), ccTLDs (country-code: .uk, .de, .jp), sTLDs (sponsored: .edu, .gov, .mil), and new gTLDs (.app, .dev, .cloud). Each TLD is operated by a designated registry operator (e.g., Verisign for .com).
How a domain name becomes an IP address
User types ┌──────────────┐
www.example.com ──────────► │ Stub │
│ Resolver │
└──────┬───────┘
│ Query: www.example.com?
▼
┌──────────────┐
┌── │ Recursive │ ◄── Checks cache first
│ │ Resolver │
│ └──────┬───────┘
│ │
Cache miss ───┘ │ Step 1: Query root server
▼
┌──────────────┐
│ Root Server │ ─── "I don't know, but
│ (.) │ ask .com servers"
└──────────────┘
│ Returns NS for .com
▼
┌──────────────┐
│ TLD Server │ ─── "I don't know, but
│ (.com) │ ask example.com NS"
└──────────────┘
│ Returns NS for example.com
▼
┌──────────────┐
│ Authoritative │ ─── "Here's the answer:
│ (example.com) │ 93.184.216.34"
└──────────────┘
│
▼
Response cached (TTL)
Answer returned to client
The client demands a complete answer. The recursive resolver must either return the answer or an error — it cannot return a referral. This is the typical mode between stub resolvers and recursive resolvers.
The server returns the best answer it has, which may be a referral to another server. The querier is then responsible for following the referral. This is how recursive resolvers talk to authoritative servers.
Originally specified in RFC 1035, inverse queries mapped an answer back to a question (e.g., IP to name). This was replaced by the much more practical reverse DNS system using PTR records in the in-addr.arpa and ip6.arpa zones.
The building blocks of DNS data
Every DNS record follows the format: name TTL class type rdata. The class is almost always IN (Internet). Here are the essential record types:
| Type | RFC | Purpose | Example |
|---|---|---|---|
A | 1035 | Maps a name to an IPv4 address | www IN A 93.184.216.34 |
AAAA | 3596 | Maps a name to an IPv6 address | www IN AAAA 2606:2800:220:1:... |
CNAME | 1035 | Canonical name (alias) for another name | blog IN CNAME www.example.com. |
MX | 1035 | Mail exchange server with priority | @ IN MX 10 mail.example.com. |
NS | 1035 | Authoritative name server for the zone | @ IN NS ns1.example.com. |
PTR | 1035 | Pointer for reverse DNS lookups | 34 IN PTR www.example.com. |
SOA | 1035 | Start of Authority — zone metadata | See zone file example below |
TXT | 1035 | Arbitrary text (SPF, DKIM, DMARC, etc.) | @ IN TXT "v=spf1 mx -all" |
SRV | 2782 | Service locator (port, priority, weight) | _sip._tcp IN SRV 10 60 5060 sip.example.com. |
CAA | 8659 | Certificate Authority Authorization | @ IN CAA 0 issue "letsencrypt.org" |
NAPTR | 3403 | Naming Authority Pointer (ENUM, SIP) | Used in VoIP and ENUM applications |
DNSKEY | 4034 | Public key for DNSSEC | Contains the zone signing key |
DS | 4034 | Delegation Signer for DNSSEC chain | Hash of child zone's DNSKEY |
RRSIG | 4034 | DNSSEC signature over an RRset | Cryptographic signature data |
SVCB | 9460 | Service Binding (general) | Modern alternative to SRV |
HTTPS | 9460 | HTTPS-specific service binding | @ IN HTTPS 1 . alpn="h2,h3" |
The SOA record is mandatory for every zone and defines key parameters:
example.com. IN SOA ns1.example.com. admin.example.com. (
2024010101 ; Serial number (YYYYMMDDNN format)
3600 ; Refresh — secondary checks primary every 1 hour
900 ; Retry — if refresh fails, retry every 15 min
1209600 ; Expire — secondary stops serving after 14 days
86400 ; Minimum TTL — negative caching TTL (1 day)
)@. So admin.example.com. actually means admin@example.com. If the local part contains a dot, escape it with a backslash: first\.last.example.com.Administrative boundaries in DNS
A domain is a subtree of the DNS namespace (e.g., example.com and everything below it). A zone is a contiguous portion of the namespace managed by a single administrator. Zones are defined by delegation — when you create NS records for sub.example.com, you create a new zone with its own SOA and authority.
The domain example.com might contain the subdomain internal.example.com, but if internal.example.com is delegated to different name servers, they are in separate zones.
AXFR (Full Zone Transfer, RFC 5936): The secondary server requests the entire zone from the primary. Used for initial synchronization.
IXFR (Incremental Zone Transfer, RFC 1995): Only the changes since a given serial number are transferred. Far more efficient for large zones with small changes.
NOTIFY (RFC 1996): The primary server immediately notifies secondaries when the zone changes, rather than waiting for the SOA refresh interval.
$ORIGIN example.com.
$TTL 86400
; === SOA Record ===
@ IN SOA ns1.example.com. hostmaster.example.com. (
2024010301 ; Serial
3600 ; Refresh (1 hour)
900 ; Retry (15 minutes)
1209600 ; Expire (2 weeks)
86400 ; Minimum / Negative Cache TTL
)
; === Name Servers ===
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
; === Mail ===
@ IN MX 10 mail.example.com.
@ IN MX 20 mail-backup.example.com.
; === A Records ===
@ IN A 93.184.216.34
ns1 IN A 93.184.216.1
ns2 IN A 93.184.216.2
www IN A 93.184.216.34
mail IN A 93.184.216.10
; === AAAA Records ===
@ IN AAAA 2606:2800:220:1:248:1893:25c8:1946
www IN AAAA 2606:2800:220:1:248:1893:25c8:1946
; === CNAME Records ===
blog IN CNAME www.example.com.
ftp IN CNAME www.example.com.
; === TXT Records ===
@ IN TXT "v=spf1 mx ip4:93.184.216.0/24 -all"
_dmarc IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
; === SRV Records ===
_sip._tcp IN SRV 10 60 5060 sip.example.com.
; === CAA Record ===
@ IN CAA 0 issue "letsencrypt.org"The most widely used DNS server software
BIND (Berkeley Internet Name Domain) is an open-source DNS server originally written at the University of California, Berkeley in the 1980s. Now developed and maintained by the Internet Systems Consortium (ISC), BIND is the reference implementation for DNS and runs on the majority of the internet's name servers.
BIND 9 was a complete rewrite focused on modularity, security, and modern features. It consists of the named daemon (the actual server), rndc (remote control utility), and various zone management tools like dnssec-keygen and named-checkzone.
named — The DNS daemon itselfrndc — Remote Name Daemon Controldig — DNS lookup utilitynslookup — Legacy query toolhost — Simple DNS lookupnamed-checkconf — Validate config syntaxnamed-checkzone — Validate zone filesdnssec-keygen — Generate DNSSEC keyssudo apt update
sudo apt install bind9 bind9utils bind9-doc
sudo systemctl enable named
sudo systemctl start namedsudo dnf install bind bind-utils
sudo systemctl enable named
sudo systemctl start named
sudo firewall-cmd --add-service=dns --permanentThe named.conf file in depth
BIND is configured through named.conf (typically in /etc/named/ or /etc/bind/). The configuration file uses a C-like syntax with nested blocks.
// ==============================================
// BIND 9 Configuration — /etc/named/named.conf
// ==============================================
// Access Control Lists
acl "trusted" {
10.0.0.0/8;
172.16.0.0/12;
192.168.0.0/16;
localhost;
localnets;
};
options {
directory "/var/named";
pid-file "/run/named/named.pid";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
// Listen on interfaces
listen-on port 53 { 127.0.0.1; 10.0.1.1; };
listen-on-v6 port 53 { ::1; };
// Recursion — only for trusted clients
recursion yes;
allow-recursion { "trusted"; };
allow-query { any; };
allow-transfer { none; };
// Forwarding
forwarders {
8.8.8.8;
1.1.1.1;
};
forward only;
// DNSSEC
dnssec-validation auto;
// Performance tuning
max-cache-size 256M;
max-cache-ttl 3600;
max-ncache-ttl 300;
// Rate limiting (anti-DDoS)
rate-limit {
responses-per-second 10;
window 5;
};
// Query logging (disable in production)
querylog no;
};
// Logging configuration
logging {
channel default_log {
file "/var/log/named/default.log" versions 5 size 50m;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel query_log {
file "/var/log/named/queries.log" versions 3 size 100m;
severity info;
print-time yes;
};
channel security_log {
file "/var/log/named/security.log" versions 5 size 50m;
severity dynamic;
print-time yes;
};
category default { default_log; };
category queries { query_log; };
category security { security_log; };
};
// TSIG key for zone transfers
key "transfer-key" {
algorithm hmac-sha256;
secret "bWFzdGVyLXNlY3JldC1rZXktZm9yLXRyYW5zZmVycw==";
};
// Primary zone
zone "example.com" {
type primary;
file "zones/db.example.com";
allow-transfer { key "transfer-key"; };
also-notify { 10.0.2.1; };
notify yes;
};
// Secondary zone
zone "partner.com" {
type secondary;
file "zones/db.partner.com";
primaries { 203.0.113.10 key "transfer-key"; };
};
// Reverse DNS zone
zone "1.0.10.in-addr.arpa" {
type primary;
file "zones/db.10.0.1";
allow-transfer { key "transfer-key"; };
};
// Root hints
zone "." {
type hint;
file "named.ca";
};aclDefines named lists of IP addresses/networks. Reusable throughout the configuration. Built-in ACLs include any, none, localhost, and localnets.
optionsGlobal server settings: listening interfaces, recursion behavior, forwarders, cache size, DNSSEC, rate limiting, and file paths. These are the defaults unless overridden per-zone.
loggingDefines channels (output destinations) and categories (types of messages). Channels can write to files, syslog, stderr, or null. Essential for debugging and security monitoring.
zoneDefines each DNS zone the server is responsible for. Types include primary (authoritative master), secondary (slave), forward, stub, hint (root), and mirror.
keyDefines TSIG shared secrets used for authenticating zone transfers, dynamic updates, and rndc communication. Always use hmac-sha256 or stronger.
viewEnables split-horizon DNS — different clients see different zones/records based on their source IP. Useful for serving different internal vs. external records.
Practical zone file configurations
$ORIGIN 1.0.10.in-addr.arpa.
$TTL 86400
@ IN SOA ns1.example.com. hostmaster.example.com. (
2024010101 3600 900 1209600 86400 )
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
; PTR records — map IP to hostname
1 IN PTR ns1.example.com.
2 IN PTR ns2.example.com.
10 IN PTR mail.example.com.
34 IN PTR www.example.com.view "internal" {
match-clients { "trusted"; };
recursion yes;
zone "example.com" {
type primary;
file "zones/internal/db.example.com";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "example.com" {
type primary;
file "zones/external/db.example.com";
};
};app.example.com to a private IP (10.0.1.50) for direct access, while external users resolve it to the public IP (203.0.113.50) through a load balancer. Views must be defined in order — first match wins.# Using nsupdate with TSIG key
nsupdate -k /etc/named/keys/update-key.key <<EOF
server 10.0.1.1
zone example.com
update delete dynamic-host.example.com A
update add dynamic-host.example.com 300 A 10.0.1.100
send
EOFGoing beyond the basics
RPZ lets BIND act as a DNS firewall. You define policies that override normal DNS responses for specific domains — blocking malware domains, redirecting phishing sites, or implementing walled gardens. RPZ zones use special record types like CNAME to . (NXDOMAIN) or CNAME to *.rpz-passthru.
; Block a malware domain
malware.bad-site.com CNAME .
; Redirect phishing to warning page
phish.example.com A 10.0.0.100
; Passthrough (whitelist)
safe.example.com CNAME *.rpz-passthru.Catalog zones automate provisioning of zones on secondary servers. Instead of manually adding zone statements to every secondary's config, you add the zone to a "catalog" zone on the primary. Secondaries automatically pick up and serve the new zone.
catalog.example.com. IN SOA . . 1 3600 900 1209600 86400
catalog.example.com. IN NS invalid.
version.catalog.example.com. IN TXT "2"
; Add a member zone
<unique-id>.zones.catalog.example.com. IN PTR newzone.com.The rndc utility lets you control a running BIND instance without restarting:
rndc reload # Reload all zones
rndc reload example.com # Reload specific zone
rndc flush # Flush entire cache
rndc flushname bad.com # Flush specific name
rndc status # Server status
rndc querylog on # Enable query logging
rndc dumpdb -all # Dump cache to file
rndc signing -list example.com # List DNSSEC keys
rndc retransfer example.com # Force zone transfertcp-clients for environments with many TCP queriesDNSSEC, DoH, DoT, and threat mitigation
DNSSEC adds a chain of trust from the root zone to each signed domain. Zone owners sign their records with private keys; resolvers verify signatures using the corresponding public keys published in DNS.
Root Zone (.)
├── DNSKEY (KSK + ZSK) ── Signed by root KSK
├── RRSIG over DNSKEY
└── DS record for .com ──── Hash of .com's KSK
│
▼
.com TLD Zone
├── DNSKEY (KSK + ZSK) ── Validated via DS in root
├── RRSIG over DNSKEY
└── DS record for example.com
│
▼
example.com Zone
├── DNSKEY (KSK + ZSK) ── Validated via DS in .com
├── RRSIG over each RRset
├── A record + RRSIG ──── Verifiable!
└── NSEC/NSEC3 ────────── Proof of non-existence
KSK = Key Signing Key (signs DNSKEY RRset)
ZSK = Zone Signing Key (signs all other RRsets)
DS = Delegation Signer (links parent to child)
# Generate Key Signing Key (KSK)
dnssec-keygen -a ECDSAP256SHA256 -f KSK example.com
# Generate Zone Signing Key (ZSK)
dnssec-keygen -a ECDSAP256SHA256 example.com
# Sign the zone
dnssec-signzone -A -3 $(head -c 1000 /dev/urandom | sha1sum | cut -b 1-16) \
-N INCREMENT -o example.com -t db.example.com
# Or use BIND's inline-signing (automatic)
# In named.conf:
zone "example.com" {
type primary;
file "zones/db.example.com";
dnssec-policy "default";
inline-signing yes;
};Attack: An attacker sends forged responses to a resolver, replacing legitimate records with malicious ones (e.g., Kaminsky attack).
Mitigations: DNSSEC validation, source port randomization, 0x20 encoding (mixed-case query names), response rate limiting.
Attack: Open resolvers are abused to amplify traffic towards a victim. A small query with a spoofed source IP generates a large response sent to the victim.
Mitigations: Disable open recursion, implement RRL, BCP 38 (ingress filtering), use allow-recursion ACLs.
Attack: Data exfiltration by encoding data in DNS queries/responses (e.g., encoded-data.evil.com TXT queries).
Mitigations: Monitor for unusual query patterns (high volume, long labels, high entropy), limit TXT record query rates, use RPZ.
Attack: Taking control of a domain by exploiting weak registrar security, expired domains, or social engineering the registrar.
Mitigations: Registrar lock, DNSSEC, two-factor authentication, registry lock services, monitoring for unauthorized changes.
Encrypting and evolving DNS for the modern internet
RFC 8484 — Encapsulates DNS queries in HTTPS requests to port 443. Provides confidentiality and makes DNS indistinguishable from regular web traffic. Supported by major browsers (Firefox, Chrome, Edge) and resolvers (Cloudflare, Google, Quad9).
curl -sH 'accept: application/dns-json' \
'https://cloudflare-dns.com/dns-query?name=example.com&type=A'RFC 7858 — Wraps standard DNS wire format in TLS on port 853. Easier to implement than DoH and simpler to deploy on existing infrastructure. Can be blocked by networks since it uses a dedicated port.
kdig +tls @1.1.1.1 example.com A
# Or with dig (BIND 9.18+)
dig +tls @1.1.1.1 example.com ARFC 9250 — Uses QUIC (UDP-based) on port 853 for encrypted DNS. Combines the privacy of DoT with the performance benefits of QUIC: 0-RTT connection resumption, multiplexed streams, and reduced latency.
RFC 9230 — Adds a proxy layer between client and resolver so that the proxy knows the client but not the query, and the resolver knows the query but not the client. Full privacy separation.
| Protocol | Port | Transport | RFC | Privacy | Firewall Visibility |
|---|---|---|---|---|---|
| Classic DNS | 53 | UDP/TCP | 1035 | None | Fully visible |
| DoT | 853 | TLS | 7858 | Encrypted | Identifiable by port |
| DoH | 443 | HTTPS | 8484 | Encrypted | Blends with HTTPS |
| DoQ | 853 | QUIC | 9250 | Encrypted | Identifiable by port |
| ODoH | 443 | HTTPS+Proxy | 9230 | Client-resolver unlinkable | Blends with HTTPS |
Every command you need for DNS diagnostics — click the copy button to copy any command
example.com with your target domain.Part of BIND utilities. The most powerful and flexible DNS query tool. Outputs full DNS response details including headers, flags, and all sections.
A domain's HTTPS suddenly stops resolving through your recursive resolver — clients get SERVFAIL. You query the authoritative server directly and it works fine. This is the classic symptom of a DNSSEC validation failure. Here is the full dig session that diagnoses it, with every output field explained.
dig app.example.com A returns SERVFAIL from your resolver (10.0.1.1), but dig @ns1.example.com app.example.com A returns the correct IP. This means the record exists but something in the validation chain is broken. We run dig +dnssec +multiline to inspect the raw DNSSEC data from the authoritative server.(1 server found) means the @ns1.example.com hostname resolved to one IP. If you see (2 servers found), dig will try both (IPv4 and IPv6).+cmd means the command header is printed (default on). Other globals like +all or +noall would appear here. This line confirms which output sections are active.opcode: QUERY — standard query (vs. IQUERY, STATUS, NOTIFY, UPDATE).status: NOERROR — the authoritative server returned success (RCODE 0). Other values: NXDOMAIN (3), SERVFAIL (2), REFUSED (5), FORMERR (1).id: 41562 — 16-bit transaction ID matching query to response (RFC 1035 §4.1.1). Mismatches indicate spoofed responses.qr = Query Response (this is a response, not a query)aa = Authoritative Answer — the server is authoritative for this zone. This is key: it proves we're getting data from the source, not a cache.rd = Recursion Desired — we asked for recursion (our side), but there's no ra flag because this authoritative server doesn't offer recursion.ad (Authenticated Data) means DNSSEC was NOT validated by this server. No tc (Truncated) means the response fit in one UDP packet.version: 0 — EDNS version (always 0 currently).flags: do — DNSSEC OK bit is set. This means we asked the server to include DNSSEC records (RRSIG, NSEC, etc.) in its response. Set by our +dnssec flag.udp: 1232 — the server's advertised UDP payload size. 1232 bytes is the current recommended maximum (RFC 8085, DNS Flag Day 2020) to avoid IP fragmentation. If the response exceeds this, the server sets the tc (truncated) flag and the client retries over TCP.QNAME QCLASS QTYPE. Note the trailing dot — this is the FQDN. IN = Internet class (virtually always). A = IPv4 address record. If this doesn't match your query, something intercepted or rewrote it.NAME TTL CLASS TYPE RDATA.300 = TTL in seconds (5 minutes). This is the remaining TTL at query time — it counts down from the zone's configured value. If you query your caching resolver, this number decreases on each query until the record expires and is re-fetched.203.0.113.50 = the IPv4 address (RDATA). This is the actual answer.A — type covered (this signature signs the A RRset).13 — algorithm: ECDSAP256SHA256 (modern, good). Common values: 8=RSA/SHA-256, 13=ECDSA/P-256, 15=Ed25519.3 — labels: number of labels in the owner name (app.example.com = 3). Used to detect wildcard expansion (if actual labels > this count, it was a wildcard match).300 — original TTL the zone was signed with.20250315120000 — signature expiration (March 15, 2025 12:00 UTC).20250213120000 — signature inception (Feb 13, 2025).12345 — key tag identifying which DNSKEY signed this. A resolver uses this to find the matching public key.example.com. — signer's name (the zone that holds the DNSKEY).aa flag). If querying a recursive resolver and the answer came from cache, this section would typically be empty. The 3600s TTL (1 hour) controls how long resolvers cache the delegation.Query time: 24 msec — round-trip time to the server. >100ms suggests network issues or geographic distance. 0ms means it came from local cache.SERVER: 93.184.216.1#53 — IP and port of the server that replied. (ns1.example.com) is the name we queried. (UDP) confirms the transport protocol used.MSG SIZE rcvd: 478 — response size in bytes. If this exceeds the EDNS UDP buffer (1232), the response would be truncated and retried over TCP. Responses >512 bytes require EDNS0 support.The authoritative server returns NOERROR with a valid A record. So the data is fine. The problem is in the RRSIG at marker 7 above. Let's investigate the key tag and check the matching DNSKEY:
12345, but the only ZSK published in the zone has key tag 67890. This means a ZSK rollover happened — the zone was re-signed with a new key, but the old DNSKEY (12345) was already removed from the zone before the old RRSIG expired.256 = Zone Signing Key (ZSK). Bit 7 set (Zone Key) + bit 15 clear.257 = Key Signing Key (KSK). Bit 7 set + bit 15 set (Secure Entry Point).3 = protocol (always 3 for DNSSEC, per RFC 4034 §2.1.2).13 = algorithm number (same as the RRSIG).app.example.com A still references key 12345, but resolvers can no longer find that key in the DNSKEY RRset — so signature verification fails and they return SERVFAIL.rndc sign example.com or wait for inline-signing to catch up. To prevent this in the future, always follow the pre-publish or double-signature rollover method (RFC 6781 §4.1) — keep the old DNSKEY published until all its RRSIGs have expired.dig +cd @10.0.1.1 app.example.com A — bypasses DNSSEC validation on your resolver. If this returns NOERROR while the normal query returns SERVFAIL, the problem is definitively DNSSEC.delv @ns1.example.com app.example.com A +vtrace — walks the full chain of trust and reports exactly where validation fails.dig example.com DNSKEY +short — list all published keys to compare against RRSIG key tags.Available on virtually all operating systems including Windows. Supports both interactive and non-interactive modes. While considered deprecated on Unix, it remains the go-to tool on Windows systems.
A streamlined utility for quick DNS lookups with clean, human-readable output. Ideal for shell scripts and fast checks. Part of the BIND utilities package.
Specialized tools for DNSSEC validation, modern output, and network diagnostics.
dig +sigchase.apt install ldnsutils.apt install knot-dnsutils.Commands for managing BIND named daemon, validating configurations, and controlling the server.
dig +cd to bypass DNSSEC validation for diagnosisdelv +vtrace for detailed DNSSEC chain validationrndc flushnamed-checkzone$ORIGIN directive — unqualified names get it appendedmax-cache-size in optionsprefetch to proactively refresh popular recordsdig +stats to check query time from different serversallow-transfer ACLs on primary — must list secondary IP or keyrndc retransfer to force-retry, check logs with journalctl -u nameddig @ns1.example.com), then a public resolver (dig @8.8.8.8). Differences between them reveal where the problem lies — caching, delegation, or the zone data itself.The standards that define DNS