DNS NXDOMAIN Error Debugging

Symptoms

An NXDOMAIN response (DNS response code 3) is a definitive negative answer from an authoritative nameserver confirming that the queried name does not exist in the DNS namespace. Unlike a timeout or SERVFAIL, NXDOMAIN is not an ambiguous error — the server is asserting with authority that the name is absent. Users and systems encounter this in several distinct forms depending on the tool or application involved.

Common indicators include:

• dig output:

  status: NXDOMAIN

  in the HEADER section with an empty ANSWER section and a AUTHORITY section containing only the SOA record
• nslookup:

  ** server can't find mail.solvethenetwork.com: NXDOMAIN

• Browser:

  DNS_PROBE_FINISHED_NXDOMAIN

  or

  ERR_NAME_NOT_RESOLVED

• ping / curl:

  ping: mail.solvethenetwork.com: Name or service not known

• Application logs (Node.js):

  getaddrinfo ENOTFOUND api.solvethenetwork.com

• Postfix logs:

  Host or domain name not found. Name service error for name=mail.solvethenetwork.com type=A: Host not found

• Python requests:

  requests.exceptions.ConnectionError: [Errno -2] Name or service not known

A baseline diagnostic using

dig

against the authoritative nameserver looks like this:

$ dig mail.solvethenetwork.com @10.10.0.53

; <<>> DiG 9.18.24 <<>> mail.solvethenetwork.com @10.10.0.53
;; QUESTION SECTION:
;mail.solvethenetwork.com.      IN      A

;; AUTHORITY SECTION:
solvethenetwork.com.    3600    IN      SOA     ns1.solvethenetwork.com. infrarunbook-admin.solvethenetwork.com. 2024040501 3600 900 604800 300

;; Query time: 2 msec
;; SERVER: 10.10.0.53#53(10.10.0.53)
;; MSG SIZE  rcvd: 101
;; status: NXDOMAIN

The presence of

NXDOMAIN

in the status line combined with no ANSWER section and only an AUTHORITY section containing the SOA record is the canonical fingerprint of a definitive non-existence response. The root causes below explain why this happens and exactly how to resolve each scenario.

---

Root Cause 1: Record Does Not Exist

Why It Happens

This is the most straightforward cause. The DNS record being queried — whether an A, AAAA, CNAME, MX, TXT, or any other type — was simply never created in the zone. This commonly occurs after provisioning a new service, migrating a workload to a new host, or spinning up a new hostname without completing the DNS configuration step. It also occurs when a record is deleted intentionally but the application referencing it is not updated.

How to Identify It

Query the authoritative nameserver directly to bypass any caching resolvers, then perform a zone transfer to enumerate every record and confirm the absence:

$ dig mail.solvethenetwork.com @10.10.0.53 +noall +answer
(no output — confirms NXDOMAIN from authoritative)

$ dig axfr solvethenetwork.com @10.10.0.53
; <<>> DiG 9.18.24 <<>> axfr solvethenetwork.com @10.10.0.53
solvethenetwork.com.    86400   IN  SOA   ns1.solvethenetwork.com. infrarunbook-admin.solvethenetwork.com. 2024040501 3600 900 604800 300
solvethenetwork.com.    86400   IN  NS    ns1.solvethenetwork.com.
solvethenetwork.com.    86400   IN  NS    ns2.solvethenetwork.com.
www.solvethenetwork.com.  3600  IN  A     10.10.0.80
ns1.solvethenetwork.com.  86400 IN  A     10.10.0.53
ns2.solvethenetwork.com.  86400 IN  A     10.10.0.54
solvethenetwork.com.    86400   IN  SOA   ns1.solvethenetwork.com. infrarunbook-admin.solvethenetwork.com. 2024040501 3600 900 604800 300

No

mail

entry appears anywhere in the zone transfer output, confirming the record was never added.

How to Fix It

Add the missing record to the zone file on the primary nameserver, increment the serial number, validate, and reload:

# /etc/bind/zones/solvethenetwork.com.zone — add the missing A record
$TTL 86400
@   IN  SOA ns1.solvethenetwork.com. infrarunbook-admin.solvethenetwork.com. (
        2024040502 ; serial — incremented
        3600       ; refresh
        900        ; retry
        604800     ; expire
        300 )      ; negative cache TTL

; existing records ...
mail    IN  A   10.10.1.25   ; <-- added

$ sudo named-checkzone solvethenetwork.com /etc/bind/zones/solvethenetwork.com.zone
zone solvethenetwork.com/IN: loaded serial 2024040502
OK

$ sudo rndc reload solvethenetwork.com
zone reload up-to-date

$ dig mail.solvethenetwork.com @10.10.0.53 +short
10.10.1.25

---

Root Cause 2: Wrong Zone File Edited

Why It Happens

BIND and other DNS server implementations serve multiple zones from multiple files. Administrators sometimes edit an inactive copy of a zone file — a stale backup, a differently-named file, or the zone file on a secondary nameserver instead of the primary. The change is never picked up because it was never applied to the authoritative source. This is especially common in environments where zone files are managed manually. Variants include editing

.bak

files, editing the wrong environment's zone in a split-horizon setup, or SSHing to the wrong host.

How to Identify It

Check

named.conf

to confirm which file is actually serving the zone, then compare the file on disk to what BIND loaded:

$ grep -A5 'solvethenetwork.com' /etc/bind/named.conf.local
zone "solvethenetwork.com" {
    type primary;
    file "/etc/bind/zones/solvethenetwork.com.zone";
    allow-transfer { 10.10.0.54; };
};

$ ls -lh /etc/bind/zones/
-rw-r--r-- 1 bind bind 1.1K Apr  5 09:12 solvethenetwork.com.zone
-rw-r--r-- 1 root root 1.3K Apr  5 11:47 solvethenetwork.com.zone.bak

The

.bak

file was modified more recently than the active zone file. Confirm the discrepancy with diff:

$ diff /etc/bind/zones/solvethenetwork.com.zone \
       /etc/bind/zones/solvethenetwork.com.zone.bak
< ; serial 2024040501 — no mail record
> mail    IN  A   10.10.1.25   ; serial 2024040502 — mail record present here, not active

You can also dump BIND's in-memory database to confirm what was actually loaded:

$ sudo rndc dumpdb -zones
$ grep 'mail' /var/cache/bind/named_dump.db | grep solvethenetwork
(no output — record not in memory)

How to Fix It

Apply the change to the correct zone file, increment the serial, and reload:

$ sudo vi /etc/bind/zones/solvethenetwork.com.zone
# Increment serial: 2024040501 -> 2024040502
# Add: mail    IN  A   10.10.1.25

$ sudo named-checkzone solvethenetwork.com /etc/bind/zones/solvethenetwork.com.zone
zone solvethenetwork.com/IN: loaded serial 2024040502
OK

$ sudo rndc reload solvethenetwork.com
zone reload up-to-date

Going forward, delete stale backup copies or enforce a naming convention that makes the active file unambiguous. Using a version-controlled deployment workflow (Ansible, Git + CI) eliminates this entire class of error.

---

Root Cause 3: Typo in the Query

Why It Happens

NXDOMAIN is frequently the result of a query-side mistake rather than any server-side misconfiguration. A missing letter, transposed characters, a double-dot, or querying the wrong subdomain all produce a valid NXDOMAIN from the server's perspective — because the name being queried genuinely does not exist. This is common in application config files, scripts, Ansible variables, Dockerfile ENV blocks, and manual

dig

invocations. A related problem is search-domain expansion in

/etc/resolv.conf

causing an unintended suffix to be appended to short names.

How to Identify It

Enable BIND query logging on sw-infrarunbook-01 and capture the exact name hitting the nameserver:

# Enable query logging temporarily
$ sudo rndc querylog on

$ tail -f /var/log/named/query.log
05-Apr-2026 14:22:01.003 queries: info: client @0x7f1c 10.10.2.15#41823 (amil.solvethenetwork.com): query: amil.solvethenetwork.com IN A +E(0)K (10.10.0.53)

The query log reveals the application is querying

amil.solvethenetwork.com

instead of

mail.solvethenetwork.com

— a transposition of the first two characters. Alternatively, use tcpdump on the DNS port to observe queries in real time:

$ sudo tcpdump -i eth0 -n port 53 -l | grep solvethenetwork
14:22:01.003210 IP 10.10.2.15.41823 > 10.10.0.53.53: 12345+ A? amil.solvethenetwork.com. (42)
14:22:01.004891 IP 10.10.0.53.53 > 10.10.2.15.41823: 12345 NXDomain 0/1/0 (101)

A search-domain doubling problem in

/etc/resolv.conf

is another common typo-class issue:

$ cat /etc/resolv.conf
nameserver 10.10.0.53
search solvethenetwork.com solvethenetwork.com   # duplicated search domain

# Result: short name "mail" expands to mail.solvethenetwork.com.solvethenetwork.com
$ dig mail @10.10.0.53 +search
;; status: NXDOMAIN   # mail.solvethenetwork.com.solvethenetwork.com does not exist

How to Fix It

Correct the typo at its source — the application config, script variable, or resolv.conf. Always use fully qualified domain names (FQDN) with a trailing dot in configuration files to prevent search-domain expansion entirely:

# Before — subject to search domain expansion
smtp_host = mail.solvethenetwork.com

# After — trailing dot suppresses expansion
smtp_host = mail.solvethenetwork.com.

# Fix /etc/resolv.conf — remove duplicate
nameserver 10.10.0.53
search solvethenetwork.com

---

Root Cause 4: Negative Caching TTL (NCACHE)

Why It Happens

When a caching resolver receives an NXDOMAIN response, it stores that negative answer for a duration defined by the SOA record's minimum TTL field — referred to as the negative caching TTL or NCACHE TTL, as standardized in RFC 2308. The consequence is that even after you correctly fix the underlying DNS issue (adding a missing record, correcting a delegation), client resolvers continue returning NXDOMAIN until the cached negative answer expires. This catches many administrators off guard: the authoritative server returns the correct answer immediately, but downstream resolvers still serve stale NXDOMAIN for minutes or hours.

How to Identify It

Examine the AUTHORITY section of an NXDOMAIN response — the last field of the SOA record is the negative cache TTL. Compare queries to the authoritative server versus the caching resolver:

# Query authoritative directly — returns correct answer
$ dig mail.solvethenetwork.com @10.10.0.53 +short
10.10.1.25

# Query caching resolver — still returning NXDOMAIN with decreasing TTL
$ dig mail.solvethenetwork.com @10.10.0.1 +noall +authority
solvethenetwork.com.    2847    IN  SOA  ns1.solvethenetwork.com. infrarunbook-admin.solvethenetwork.com. 2024040502 3600 900 604800 300

# 10 minutes later — TTL has decreased, confirming stale cached NXDOMAIN
$ dig mail.solvethenetwork.com @10.10.0.1 +noall +authority
solvethenetwork.com.    2241    IN  SOA  ns1.solvethenetwork.com. infrarunbook-admin.solvethenetwork.com. 2024040502 3600 900 604800 300

The decreasing SOA TTL (2847 → 2241) confirms the NXDOMAIN is cached and not freshly queried from the authoritative server. The NCACHE TTL in this example is the last SOA field:

300

seconds — but the resolver cached the TTL from the SOA record itself (3600), so it will serve the NXDOMAIN for up to 3600 seconds after the negative was first cached.

How to Fix It

Flush the cached NXDOMAIN on the caching resolver to force an immediate re-query of the authoritative server:

# BIND 9 — flush a specific name from cache
$ sudo rndc flushname mail.solvethenetwork.com

# BIND 9 — flush entire cache for a specific view (if using views)
$ sudo rndc flush internal

# Unbound — flush a specific name
$ sudo unbound-control flush mail.solvethenetwork.com
ok

# Verify the flush worked — should now return the correct answer
$ dig mail.solvethenetwork.com @10.10.0.1 +short
10.10.1.25

Reduce future blast radius by keeping the SOA negative cache TTL (the last field) low — 300 seconds is a widely recommended default:

$TTL 86400
@   IN  SOA ns1.solvethenetwork.com. infrarunbook-admin.solvethenetwork.com. (
        2024040503 ; serial
        3600       ; refresh
        900        ; retry
        604800     ; expire
        300 )      ; negative cache TTL — keep at 300s or lower

---

Root Cause 5: Zone Not Delegated Properly

Why It Happens

DNS delegation is the chain of trust mechanism by which a parent zone instructs resolvers which nameservers are authoritative for a child zone. If the delegation is broken — missing NS records at the parent, NS records pointing to incorrect hostnames, or missing glue records for in-bailiwick nameservers — resolvers cannot locate the authoritative server and either receive NXDOMAIN from the parent zone itself or fail to complete the resolution chain. Delegation problems most often arise after a nameserver migration where NS records at the registrar were not updated, or after configuring a new subdomain without adding NS records to the parent zone file.

How to Identify It

Trace the full delegation chain from the root using

dig +trace

to pinpoint exactly where the chain breaks:

$ dig mail.solvethenetwork.com +trace +nodnssec

; <<>> DiG 9.18.24 <<>> mail.solvethenetwork.com +trace +nodnssec
.                        518400  IN  NS  a.root-servers.net.
...
com.                     172800  IN  NS  a.gtld-servers.net.
...
solvethenetwork.com.     172800  IN  NS  ns1.solvethenetwork.com.
solvethenetwork.com.     172800  IN  NS  ns2.solvethenetwork.com.
;; Received 97 bytes from 192.5.6.30#53(a.gtld-servers.net) in 12 ms

mail.solvethenetwork.com.  NXDOMAIN
;; Received 101 bytes from 10.10.0.53#53(ns1.solvethenetwork.com) in 2 ms

For subdomain delegation issues, check for NS records in the parent zone file and matching glue records:

# Checking delegation for dev.solvethenetwork.com
$ dig NS dev.solvethenetwork.com @10.10.0.53 +noall +answer
(no output — NS records missing from parent zone)

# What SHOULD exist in the parent zone file:
# dev                 IN  NS  ns1.dev.solvethenetwork.com.
# ns1.dev             IN  A   10.10.5.53    ; glue record

# Verify NS records at the registrar match the actual authoritative servers
$ dig NS solvethenetwork.com @a.gtld-servers.net +short
ns1.solvethenetwork.com.
ns2.solvethenetwork.com.

# Confirm those hostnames resolve (glue records present)
$ dig A ns1.solvethenetwork.com @a.gtld-servers.net +short
10.10.0.53

If the registrar-side NS records point to old or incorrect nameserver hostnames, resolvers follow the stale delegation and get NXDOMAIN or SERVFAIL from the wrong server.

How to Fix It

For TLD-level delegation, update NS records at the domain registrar to match the actual authoritative nameservers and wait for the registrar's TTL to expire. For internal subdomain delegation, add NS and glue records to the parent zone:

# Parent zone: /etc/bind/zones/solvethenetwork.com.zone
# Add delegation for dev.solvethenetwork.com subdomain
dev                 IN  NS  ns1.dev.solvethenetwork.com.
dev                 IN  NS  ns2.dev.solvethenetwork.com.
ns1.dev             IN  A   10.10.5.53
ns2.dev             IN  A   10.10.5.54

$ sudo named-checkzone solvethenetwork.com /etc/bind/zones/solvethenetwork.com.zone
zone solvethenetwork.com/IN: loaded serial 2024040504
OK

$ sudo rndc reload solvethenetwork.com

# Verify delegation is now functional
$ dig NS dev.solvethenetwork.com @10.10.0.53 +short
ns1.dev.solvethenetwork.com.
ns2.dev.solvethenetwork.com.

$ dig mail.dev.solvethenetwork.com +trace | tail -5
mail.dev.solvethenetwork.com.  3600  IN  A  10.10.5.25
;; Received 56 bytes from 10.10.5.53#53(ns1.dev.solvethenetwork.com) in 1 ms

---

Root Cause 6: DNSSEC Validation Failure

Why It Happens

DNSSEC-validating resolvers use cryptographic signatures to verify the authenticity of DNS responses. When the DNSSEC chain of trust is broken — mismatched DS records at the parent zone, expired RRSIG records, or a key rollover performed incorrectly — a validating resolver rejects the response as bogus. Depending on resolver configuration this surfaces as SERVFAIL, but some configurations return NXDOMAIN. Additionally, DNSSEC uses NSEC and NSEC3 records to provide authenticated denial of existence — if these records are malformed or a zone is incompletely signed, legitimate names can be incorrectly denied.

How to Identify It

# Query with DNSSEC validation shows SERVFAIL
$ dig mail.solvethenetwork.com @10.10.0.53 +dnssec +noall +comments
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44123
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

# Disable validation — if this returns an answer, DNSSEC is the culprit
$ dig mail.solvethenetwork.com @10.10.0.53 +cd +short
10.10.1.25

# Check RRSIG expiry — look for dates in the past
$ dig solvethenetwork.com RRSIG @10.10.0.53 +short
A 8 2 86400 20240101000000 20231201000000 12345 solvethenetwork.com. ...
#                          ^^^^^^^^^^^^^^^^ expiry — if past today, signatures are stale

How to Fix It

Re-sign the zone and ensure DS records at the parent match the active KSK:

$ sudo rndc sign solvethenetwork.com
$ sudo rndc loadkeys solvethenetwork.com

# Verify fresh RRSIG records are present
$ dig solvethenetwork.com RRSIG @10.10.0.53 | grep 'expir\|RRSIG'

# Confirm DS at parent matches local DNSKEY
$ dig solvethenetwork.com DNSKEY @10.10.0.53 +short
257 3 8 AwEAAb...
$ dig solvethenetwork.com DS @a.gtld-servers.net +short
12345 8 2 AB12EF...

Enable

auto-dnssec maintain;

and

inline-signing yes;

in BIND to automate key rollovers and eliminate manual signature expiry as a failure mode.

---

Root Cause 7: Split-Horizon View Misconfiguration

Why It Happens

BIND's

view

directive serves different responses based on the source IP of the query — commonly used to return RFC 1918 addresses to internal clients and public IPs to external clients. If a record is added to the wrong view's zone file, or if ACL matching places a client in an unintended view, the client receives NXDOMAIN because the record does not exist in the zone file being served to their source IP.

How to Identify It

$ grep -A20 'view' /etc/bind/named.conf.local
view "internal" {
    match-clients { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };
    zone "solvethenetwork.com" {
        type primary;
        file "/etc/bind/zones/solvethenetwork.com.internal.zone";
    };
};
view "external" {
    match-clients { any; };
    zone "solvethenetwork.com" {
        type primary;
        file "/etc/bind/zones/solvethenetwork.com.external.zone";
    };
};

# Record exists in internal zone but was accidentally omitted from external
$ grep 'mail' /etc/bind/zones/solvethenetwork.com.internal.zone
mail    IN  A   10.10.1.25

$ grep 'mail' /etc/bind/zones/solvethenetwork.com.external.zone
(no output)

How to Fix It

Add the record to the appropriate view's zone file. If the record should be reachable from both views, add it to both with the appropriate IP per view:

# Add to external zone with publicly routable IP
echo 'mail    IN  A   203.0.113.25' | sudo tee -a /etc/bind/zones/solvethenetwork.com.external.zone

# Increment serial in that zone file, then reload
$ sudo rndc reload solvethenetwork.com

# Confirm an external client now resolves correctly
$ dig mail.solvethenetwork.com @10.10.0.53 +short
203.0.113.25

---

Root Cause 8: Response Policy Zone (RPZ) Blocking

Why It Happens

RPZ (Response Policy Zones) allow DNS servers to override query responses based on policy — used for blocking malware domains, enforcing acceptable use policies, or implementing parental controls. An overly broad RPZ rule or a wildcard entry that inadvertently matches a legitimate hostname will cause that name to return NXDOMAIN (or a walled-garden redirect) even though the underlying DNS record is perfectly valid. This is particularly tricky to diagnose because the record exists and the authoritative server answers correctly — the RPZ layer intercepts the response at the resolver.

How to Identify It

# RPZ-intercepted responses include EDE (Extended DNS Error) code 15 = Blocked
$ dig mail.solvethenetwork.com @10.10.0.53 +noall +comments
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55123
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 15 (Blocked)

# RPZ events are logged separately
$ tail -f /var/log/named/rpz.log
05-Apr-2026 15:33:01.442 rpz: info: client 10.10.2.15#51230: rpz QNAME Local-Data rewrite mail.solvethenetwork.com/A/IN via solvethenetwork.com.rpz: NXDOMAIN

# Enumerate the RPZ zone to find the matching rule
$ dig axfr solvethenetwork.com.rpz @10.10.0.53
mail.solvethenetwork.com.rpz.  300  IN  CNAME  .    ; CNAME to . means NXDOMAIN policy

How to Fix It

Remove or refine the RPZ rule that is incorrectly matching the legitimate hostname, then increment the RPZ zone serial and reload:

$ sudo vi /etc/bind/zones/solvethenetwork.com.rpz
# Delete or comment out:
# mail.solvethenetwork.com.rpz.  300  IN  CNAME  .

# Increment RPZ zone serial
$ sudo rndc reload solvethenetwork.com.rpz

# Flush the cached RPZ-blocked response
$ sudo rndc flushname mail.solvethenetwork.com

# Confirm resolution is restored
$ dig mail.solvethenetwork.com @10.10.0.53 +short
10.10.1.25

---

Prevention

Most NXDOMAIN incidents are preventable through disciplined zone management, low negative TTLs, and continuous monitoring:

• Always validate before reloading. Run

  named-checkzone

  and

  named-checkconf

  before every zone change. Automate these checks as a CI gate in your DNS deployment pipeline.
• Version-control all zone files. Store zone files in Git and require peer review for all changes. Diffs catch typos and wrong-file edits before they hit production.
• Set low negative cache TTLs. Keep the SOA minimum TTL at 300 seconds so NXDOMAIN caching does not extend the impact window of a misconfiguration.
• Use FQDN with trailing dots in all configs. Trailing dots prevent search-domain expansion and eliminate an entire class of query typo.
• Monitor DNS health continuously. Run synthetic checks against all critical records from multiple vantage points using tools like Nagios

  check_dns

  , Prometheus

  dns_sd

  exporter, or Blackbox Exporter.
• Test delegation after every nameserver change. Use

  dig +trace

  and validate the full delegation chain before and after cutover. Treat delegation verification as a required step in your change management checklist.
• Document and review RPZ rules. Maintain a changelog for all RPZ and split-horizon view changes. Require peer approval before merging policy updates to avoid unintended blocks.
• Automate DNSSEC maintenance. Use BIND's

  auto-dnssec maintain;

  and

  inline-signing yes;

  directives and set up alerting for RRSIG expiry at least 14 days in advance.
• Enforce consistent resolver configuration. Manage

  /etc/resolv.conf

  via Ansible or systemd-resolved configuration to prevent search-domain drift across hosts.

---

Frequently Asked Questions

Q: What does NXDOMAIN mean exactly?

A: NXDOMAIN stands for Non-Existent Domain and is DNS response code 3. It is a definitive answer from an authoritative nameserver asserting that the queried name does not exist anywhere in the zone. It is not an error in the traditional sense — it is a valid, authoritative negative response.

Q: How is NXDOMAIN different from SERVFAIL?

A: NXDOMAIN means the name definitively does not exist; SERVFAIL (response code 2) means the server encountered an error while trying to resolve the name — the name may or may not exist but the server could not determine the answer. Common SERVFAIL causes include DNSSEC validation failures, broken delegation, and resolver timeouts reaching the authoritative server.

Q: How long does negative caching last?

A: It depends on the SOA record. The negative cache TTL is the minimum of the SOA record's own TTL and the last field (minimum TTL) of the SOA RDATA. RFC 2308 caps the negative caching TTL at 10800 seconds (3 hours). Best practice is to set the SOA minimum TTL to 300 seconds to limit the impact of errors.

Q: How do I immediately flush a cached NXDOMAIN in BIND 9?

A: Use

sudo rndc flushname mail.solvethenetwork.com

to flush a specific name, or

sudo rndc flush

to flush the entire cache. For Unbound, use

sudo unbound-control flush mail.solvethenetwork.com

. After flushing, the next query will go directly to the authoritative server.

Q: Why does querying the authoritative server return the correct answer, but the caching resolver still returns NXDOMAIN?

A: The caching resolver has a stale negative answer stored from before you fixed the record. The cached NXDOMAIN will persist until the negative cache TTL expires. Flush the resolver's cache (see above) to resolve this immediately without waiting for TTL expiry.

Q: How do I check if a zone delegation is correctly configured end-to-end?

A: Use

dig mail.solvethenetwork.com +trace

to walk the full delegation chain from root to authoritative and identify where the chain breaks. Also use

named-checkzone

to validate the zone file locally and check that NS records and glue records in the parent zone are consistent with the actual authoritative server addresses.

Q: Can DNSSEC cause NXDOMAIN responses for records that actually exist?

A: Yes. DNSSEC uses NSEC and NSEC3 records to provide authenticated proof that a name does not exist. If these records are misconfigured, malformed, or the zone is only partially signed, a validating resolver may incorrectly deny a legitimate name. Additionally, RRSIG expiry can cause validating resolvers to return SERVFAIL, which some applications interpret similarly to NXDOMAIN.

Q: How do I find out which BIND view a client query is hitting?

A: Enable query logging with

sudo rndc querylog on

and inspect

/var/log/named/query.log

. BIND includes the matched view name in the log line when views are configured:

client 10.10.2.15#41823 (mail.solvethenetwork.com): view internal: query ...

. You can also use

dig

from different source IPs to test which view responds from each network segment.

Q: What is the difference between NXDOMAIN and NODATA?

A: NXDOMAIN means the queried name does not exist at all. NODATA (sometimes called NOERROR/NODATA) means the name exists but has no records of the queried type — for example, querying for an AAAA record on a hostname that only has an A record. NODATA returns response code NOERROR with an empty ANSWER section, while NXDOMAIN returns response code 3. Both include the SOA in the AUTHORITY section but for different reasons.

Q: How do I enable RPZ logging in BIND to detect policy-driven NXDOMAIN responses?

A: Add an RPZ-specific logging channel to your

named.conf

:

category rpz { rpz_log; };

with a corresponding file channel. BIND will then log every RPZ rewrite with the client IP, queried name, and which RPZ rule triggered the override, making it straightforward to identify false positives in your policy zones.

Q: Should I use FQDN with trailing dots in application configuration files?

A: Yes, always. A hostname without a trailing dot (e.g.,

mail.solvethenetwork.com

) is subject to search-domain expansion defined in

/etc/resolv.conf

. On a host with

search solvethenetwork.com

configured, the short name

mail

will correctly expand, but on a host without that search domain, resolution may fail. Using the FQDN

mail.solvethenetwork.com.

(trailing dot) bypasses search-domain expansion universally and eliminates this ambiguity.

Q: How do I prevent NXDOMAIN from impacting applications during a planned DNS change?

A: Lower the TTL of the affected record 24–48 hours before the change so caches drain quickly. Also lower the SOA negative cache TTL before making the change. After the change, verify with

dig @10.10.0.53

directly against the authoritative server before announcing the record is live. If using a caching resolver internally, flush the relevant name from the cache immediately after the change using

rndc flushname

.