What is DNS?
The Domain Name System (DNS) is the distributed, hierarchical naming infrastructure that underpins virtually every networked application on the internet and private intranets alike. At its core, DNS translates human-readable hostnames — such as mail.solvethenetwork.com — into machine-readable IP addresses like 192.168.10.25. Without DNS, operators and users would need to maintain and memorize numeric addresses for every service, making scalable networking practically impossible.
DNS was formally defined in RFC 1034 and RFC 1035 in 1987 by Paul Mockapetris. The system was designed as a replacement for the flat HOSTS.TXT file that ARPANET nodes exchanged. As the network grew, that centralized model collapsed under its own weight — DNS solved the scaling problem by distributing authority across a global hierarchy of name servers, where each delegation boundary hands off responsibility to a more specific set of servers.
DNS is not simply a lookup table. It is a globally replicated, loosely consistent, fault-tolerant database that supports multiple record types, zone delegation, caching at multiple layers, security extensions (DNSSEC), dynamic updates (RFC 2136), and response policy enforcement (RPZ). Understanding how it operates at every layer is essential for any infrastructure engineer responsible for network reliability, mail delivery, TLS certificate automation, or service discovery.
The DNS Hierarchy
DNS is organized as an inverted tree. At the top sits the root zone, represented by a single dot (.). Beneath the root are the top-level domains (TLDs) such as
.com,
.net,
.org, and country-code TLDs like
.ukand
.de. Below TLDs are second-level domains (e.g.,
solvethenetwork.com), and below those are subdomains and individual host records.
Each node in this tree is called a label. A fully qualified domain name (FQDN) is the complete path from a leaf node to the root, written right-to-left with dots as separators. The trailing dot in
mail.solvethenetwork.com.represents the root and is technically required by the protocol but is usually omitted in everyday usage because resolvers append it implicitly.
The hierarchy is divided into zones. A zone is a contiguous, delegated portion of the DNS namespace administered by a specific set of authoritative name servers. Zone data is stored in zone files and served by those authoritative servers. When an organization registers
solvethenetwork.com, the .com TLD registry delegates authority for that zone to the name servers specified by the registrant — recording those NS records and their associated glue A records in the TLD zone itself.
How DNS Resolution Works
DNS resolution is a multi-step process involving several distinct actors. Understanding each role precisely is critical for troubleshooting resolution failures and designing reliable, performant DNS infrastructure.
The Key Components
- Stub Resolver: A lightweight client library embedded in the operating system. It sends DNS queries to the configured recursive resolver and returns answers to calling applications. On Linux systems, the stub resolver reads
/etc/resolv.conf
to determine which recursive resolver addresses to use. It performs no iterative resolution itself. - Recursive Resolver (Recursor): The workhorse of DNS. It accepts queries from stub resolvers and performs the full iterative resolution walk on their behalf, caching responses to reduce latency and authoritative server load. Examples include BIND in recursive mode, Unbound, PowerDNS Recursor, and cloud-managed resolvers.
- Root Name Servers: Thirteen logical root server clusters (labeled A through M, e.g.,
a.root-servers.net
throughm.root-servers.net
). They do not hold zone data for registered domains but hold the NS records for every TLD. They are anycast-distributed across hundreds of physical locations globally, providing resilience against DDoS and network partitioning. - TLD Name Servers: Operated by registries. They hold NS delegation records pointing to the authoritative name servers for each registered domain in that TLD, along with glue A records for in-zone name servers.
- Authoritative Name Server: The definitive source of truth for a zone. It returns actual resource records (A, AAAA, MX, TXT, CNAME, etc.) for names within its zone. It does not perform recursion on behalf of clients — it only answers for zones it is configured to serve.
The Full Resolution Walk-Through
Consider a query for
mail.solvethenetwork.comfrom a workstation at 192.168.10.50 configured to use a local recursive resolver at 192.168.1.1. Assume all caches are cold.
Step 1: Local stub resolver checks OS cache and /etc/hosts
No match found.
Step 2: Stub resolver sends UDP query to 192.168.1.1:53
Query: mail.solvethenetwork.com IN A ? (RD=1)
Step 3: Recursive resolver (192.168.1.1) checks its local cache
Cache MISS — no cached entry for this name or its parent zones.
Step 4: Recursive resolver queries a root server (e.g., 198.41.0.4)
Query: mail.solvethenetwork.com IN A ?
Root response (referral, AA=0):
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
[+ additional glue A records for .com TLD servers]
Step 5: Recursive resolver queries a .com TLD server (e.g., 192.5.6.30)
Query: mail.solvethenetwork.com IN A ?
TLD response (referral, AA=0):
solvethenetwork.com. 172800 IN NS ns1.solvethenetwork.com.
solvethenetwork.com. 172800 IN NS ns2.solvethenetwork.com.
[+ glue: ns1.solvethenetwork.com. A 192.168.10.10]
Step 6: Recursive resolver queries ns1.solvethenetwork.com (192.168.10.10)
Query: mail.solvethenetwork.com IN A ?
Authoritative response (AA=1):
mail.solvethenetwork.com. 300 IN A 192.168.10.25
Step 7: Recursive resolver caches:
mail.solvethenetwork.com. A 192.168.10.25 (TTL=300s)
Returns answer to stub resolver at 192.168.10.50.
Step 8: Application on 192.168.10.50 connects to 192.168.10.25.The recursive resolver performs iterative queries — it follows referrals hop by hop from root to TLD to authoritative. The stub resolver, by contrast, sends a single recursive query and waits for a final answer. This distinction is encoded in the DNS message flags: the stub sets the RD (Recursion Desired) bit; the recursive resolver sets the RA (Recursion Available) bit in its response to indicate it supports recursion for clients.
DNS Message Format
Every DNS message — query or response — uses the same binary wire format defined in RFC 1035. It consists of five sections:
- Header: 12 bytes. Contains the transaction ID (used to match responses to queries), flags (QR, Opcode, AA, TC, RD, RA, Z, AD, CD, RCODE), and counts for each subsequent section.
- Question: The queried name (QNAME), query type (QTYPE, e.g., A, MX, TXT), and query class (QCLASS, almost always IN for Internet).
- Answer: Resource records (RRs) that directly answer the query.
- Authority: NS records pointing to authoritative servers, returned in referral responses when the queried server does not hold the answer.
- Additional: Supplemental RRs such as glue A records for name servers listed in the Authority section, or OPT records for EDNS0.
DNS uses UDP on port 53 for the vast majority of queries due to low per-packet overhead. If a response exceeds the negotiated EDNS0 payload size (classically 512 bytes, now typically 1232–4096 bytes), or for zone transfers and certain DNSSEC responses, the resolver retries over TCP on port 53. DNS over TLS (DoT, port 853) and DNS over HTTPS (DoH, port 443) are increasingly deployed for privacy and integrity in untrusted network environments.
Caching and TTL
Every resource record carries a TTL (Time To Live) value in seconds. Recursive resolvers cache records and serve cached copies until the TTL expires, at which point a fresh query to the authoritative server is required. TTL is the primary operational lever for balancing DNS change agility against resolver query load:
- Low TTL (60–300s): DNS changes visible to most resolvers within minutes, but higher ongoing query load on authoritative servers.
- High TTL (3600–86400s): Reduced authoritative server load and improved resolver performance, but slow cutover during IP migrations or failover events.
A proven practice before any planned IP migration for
solvethenetwork.comrecords is to pre-emptively lower the TTL of affected records to 60–300 seconds at least one full existing-TTL period before the change window opens. This flushes stale cached copies from resolvers before you need them to pick up the new address.
DNS Record Types
The DNS protocol defines dozens of resource record types. The following are the most operationally significant:
- A: Maps a hostname to an IPv4 address. The most queried record type.
- AAAA: Maps a hostname to an IPv6 address.
- CNAME: Canonical Name — an alias that points to another hostname. The resolver follows the CNAME chain until it resolves to an A or AAAA record. CNAMEs cannot coexist with other record types at the same name.
- MX: Mail Exchanger — identifies the mail servers for a domain, each with a priority value. Lower priority values are preferred.
- NS: Name Server — delegates a zone or subdomain to a set of authoritative servers.
- SOA: Start of Authority — contains zone metadata: primary NS hostname, administrative contact email (encoded as a dotted name), serial number, refresh interval, retry interval, expire interval, and negative cache TTL.
- PTR: Pointer — reverse DNS; maps an IP address back to a hostname. Stored in
in-addr.arpa
(IPv4) andip6.arpa
(IPv6) zones. - TXT: Free-form text records. Used for SPF email authentication, DKIM public keys, DMARC policies, domain ownership verification tokens, and more.
- SRV: Service locator. Defines the hostname, port, priority, and weight for a specific service protocol. Used by SIP, XMPP, and service discovery systems.
- CAA: Certification Authority Authorization. Restricts which certificate authorities may issue TLS certificates for the domain. Checked by CAs before issuance.
Zone File Structure on sw-infrarunbook-01
Below is a representative BIND zone file for
solvethenetwork.comas configured on the authoritative server sw-infrarunbook-01:
; Zone file for solvethenetwork.com
; Managed by: infrarunbook-admin
; Server: sw-infrarunbook-01
$ORIGIN solvethenetwork.com.
$TTL 3600
@ IN SOA ns1.solvethenetwork.com. infrarunbook-admin.solvethenetwork.com. (
2026040401 ; Serial (YYYYMMDDnn)
3600 ; Refresh — how often secondary checks for updates
900 ; Retry — if refresh fails, retry after this interval
604800 ; Expire — secondary stops answering if no contact
300 ; Negative cache TTL (NXDOMAIN / NODATA)
)
; Name servers (these must also appear as NS records at parent)
@ IN NS ns1.solvethenetwork.com.
@ IN NS ns2.solvethenetwork.com.
; Glue records for in-zone authoritative name servers
ns1 IN A 192.168.10.10
ns2 IN A 192.168.10.11
; Host records
@ IN A 192.168.10.1
www IN A 192.168.10.1
mail IN A 192.168.10.25
vpn IN A 192.168.10.50
sw-infrarunbook-01 IN A 192.168.10.10
; Mail exchanger (priority 10 — lower is preferred)
@ IN MX 10 mail.solvethenetwork.com.
; SPF record — authorize only 192.168.10.0/24, hard-fail all others
@ IN TXT "v=spf1 ip4:192.168.10.0/24 -all"
; DMARC policy
_dmarc IN TXT "v=DMARC1; p=reject; rua=mailto:infrarunbook-admin@solvethenetwork.com"
; SRV record for SIP over TCP
_sip._tcp IN SRV 10 20 5060 sip.solvethenetwork.com.
; CAA — only allow Let's Encrypt to issue certificates
@ IN CAA 0 issue "letsencrypt.org"
; Subdomain delegation for dev.solvethenetwork.com
dev IN NS ns1.dev.solvethenetwork.com.
dev IN NS ns2.dev.solvethenetwork.com.
; Glue for delegated subdomain NS (if in-zone)
ns1.dev IN A 192.168.20.10
ns2.dev IN A 192.168.20.11Reverse DNS Zone (PTR Records)
Reverse DNS maps IP addresses back to hostnames using PTR records in the
in-addr.arpazone. For the IP
192.168.10.25, the PTR record lives at
25.10.168.192.in-addr.arpa.. Reverse DNS is critical for mail server reputation scoring, SSH login audit logging, and network security monitoring tools that resolve IPs to hostnames in real time.
; Reverse zone for 192.168.10.0/24
; File: db.192.168.10
; Managed by: infrarunbook-admin on sw-infrarunbook-01
$ORIGIN 10.168.192.in-addr.arpa.
$TTL 3600
@ IN SOA ns1.solvethenetwork.com. infrarunbook-admin.solvethenetwork.com. (
2026040401
3600
900
604800
300
)
@ IN NS ns1.solvethenetwork.com.
@ IN NS ns2.solvethenetwork.com.
1 IN PTR solvethenetwork.com.
10 IN PTR ns1.solvethenetwork.com.
11 IN PTR ns2.solvethenetwork.com.
25 IN PTR mail.solvethenetwork.com.
50 IN PTR vpn.solvethenetwork.com.Why DNS Matters
DNS is the first dependency for almost every networked service. A misconfigured or unreachable recursive resolver can make an entire datacenter appear offline even when every application server is healthy and fully reachable. DNS failures are consistently one of the top causes of widespread internet service outages — and they are frequently misdiagnosed because the symptom (service unreachable) looks identical to a network or application failure.
Beyond basic hostname resolution, DNS carries critical operational data across the infrastructure stack:
- Mail routing via MX records — a missing or misconfigured MX causes inbound mail delivery failures across the entire domain, often with delayed bounce notifications.
- Email authentication via SPF, DKIM, and DMARC TXT records — without correctly published DNS records, outbound mail from solvethenetwork.com will be rejected or silently quarantined by recipient mail servers.
- TLS certificate issuance — ACME challenge protocols (Let's Encrypt, ZeroSSL) validate domain ownership via DNS TXT records for DNS-01 challenges. Misconfigured zones cause certificate renewal failures that surface days later when the expired certificate triggers browser warnings.
- Service discovery — Kubernetes CoreDNS, Consul DNS, and similar platforms expose internal service endpoints via DNS. DNS availability is a hard dependency for all inter-service communication in these environments.
- Security controls — DNSSEC prevents cache poisoning; DNS RPZ (Response Policy Zones) enables DNS-layer threat blocking; CAA records restrict unauthorized certificate issuance.
Real-World Examples
Full Resolution Trace with dig
The
digutility with the
+traceflag forces a full iterative walk from the root, bypassing the local resolver cache and showing every referral hop. This is the most valuable single diagnostic for resolution problems:
infrarunbook-admin@sw-infrarunbook-01:~$ dig +trace mail.solvethenetwork.com A
; <<>> DiG 9.18.20 <<>> +trace mail.solvethenetwork.com A
;; global options: +cmd
. 518400 IN NS a.root-servers.net.
. 518400 IN NS b.root-servers.net.
[... 11 additional root NS records ...]
;; Received 811 bytes from 192.168.1.1#53(192.168.1.1) in 2 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
[... additional .com TLD NS records ...]
;; Received 1170 bytes from 198.41.0.4#53(a.root-servers.net) in 24 ms
solvethenetwork.com. 172800 IN NS ns1.solvethenetwork.com.
solvethenetwork.com. 172800 IN NS ns2.solvethenetwork.com.
;; Received 284 bytes from 192.5.6.30#53(a.gtld-servers.net) in 15 ms
mail.solvethenetwork.com. 300 IN A 192.168.10.25
solvethenetwork.com. 3600 IN NS ns1.solvethenetwork.com.
solvethenetwork.com. 3600 IN NS ns2.solvethenetwork.com.
;; Received 112 bytes from 192.168.10.10#53(ns1.solvethenetwork.com) in 1 msQuerying SOA, NS, and Reverse DNS
infrarunbook-admin@sw-infrarunbook-01:~$ dig solvethenetwork.com SOA +short
ns1.solvethenetwork.com. infrarunbook-admin.solvethenetwork.com. 2026040401 3600 900 604800 300
infrarunbook-admin@sw-infrarunbook-01:~$ dig solvethenetwork.com NS +short
ns1.solvethenetwork.com.
ns2.solvethenetwork.com.
infrarunbook-admin@sw-infrarunbook-01:~$ dig -x 192.168.10.25 +short
mail.solvethenetwork.com.
infrarunbook-admin@sw-infrarunbook-01:~$ dig solvethenetwork.com MX +short
10 mail.solvethenetwork.com.Validating DNSSEC
When DNSSEC is deployed, the recursive resolver cryptographically validates signatures from the zone all the way up to the root trust anchor. The AD (Authenticated Data) flag in the response confirms successful validation:
infrarunbook-admin@sw-infrarunbook-01:~$ dig solvethenetwork.com DNSKEY +dnssec +short
257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0dxW4... ; KSK (Key Signing Key)
256 3 13 oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRipwnt... ; ZSK (Zone Signing Key)
infrarunbook-admin@sw-infrarunbook-01:~$ dig mail.solvethenetwork.com A +dnssec
;; flags: qr rd ra ad ; <-- AD flag = Authenticated Data (DNSSEC chain valid)
;; ANSWER SECTION:
mail.solvethenetwork.com. 300 IN A 192.168.10.25
mail.solvethenetwork.com. 300 IN RRSIG A 13 3 300 20260501000000 ...If the AD flag is absent when DNSSEC is expected, either the resolver does not validate DNSSEC, the zone's signatures have expired, or the DS record in the parent zone does not match the zone's DNSKEY. Each scenario requires a different fix.
Common Misconceptions
Misconception 1: DNS changes propagate instantly or within minutes
DNS changes do not push out to the internet — they expire from caches on their own schedule. When you update a record on ns1.solvethenetwork.com, resolvers that cached the old record continue serving it until their TTL countdown reaches zero. A record with a 24-hour TTL may still resolve to the old IP for up to 24 hours after you make the change. The term "propagation" is technically a misnomer; the correct mental model is TTL expiry and cache refresh.
Misconception 2: Root servers handle most DNS queries
Root servers only field queries for which no cached TLD referral exists. Because .com TLD NS records carry TTLs of 48 hours or more, recursive resolvers rarely need to contact root servers for common TLDs. Root servers handle a tiny fraction of global DNS traffic. Recursive resolvers are responsible for the vast majority of query volume.
Misconception 3: CNAME records can be placed at the zone apex
RFC 1034 explicitly prohibits CNAME records at the zone apex (the
@record for
solvethenetwork.com.) because the apex must simultaneously carry SOA and NS records, and a CNAME cannot coexist with any other record type at the same owner name. Some DNS providers implement proprietary CNAME flattening (marketed as ALIAS or ANAME records) that resolves the CNAME target and returns its A records, but this is non-standard behavior implemented at the provider layer.
Misconception 4: DNS only uses UDP
UDP port 53 handles most query traffic, but TCP port 53 is mandatory for responses that exceed the negotiated payload size, for all zone transfers (AXFR/IXFR), and is increasingly standard for DNSSEC responses carrying large RRSIG, DNSKEY, and NSEC records. Firewalls that block TCP/53 silently break DNSSEC validation and zone transfers.
Misconception 5: Flushing your local DNS cache resolves stale record issues
Your local OS cache is only one of several independent caching layers. Your stub resolver, the enterprise recursive resolver at 192.168.1.1, ISP resolvers, and CDN edge nodes all cache records independently. Flushing your machine's cache causes it to re-query the upstream recursive resolver — which may immediately return the same stale record it has cached. To verify you are seeing the authoritative answer, query the authoritative server directly with
dig @192.168.10.10 mail.solvethenetwork.com A.
Frequently Asked Questions
Q: What is the difference between an authoritative DNS server and a recursive resolver?
A: An authoritative DNS server holds the zone data for one or more domains and returns definitive answers for names within those zones. It does not query other servers on a client's behalf. A recursive resolver accepts queries from stub resolvers and performs the full iterative walk — root, TLD, authoritative — returning a final answer. Most enterprise environments run both: authoritative servers for their own zones and recursive resolvers for outbound client lookups.
Q: What happens when a DNS TTL expires while a user is actively connected to a service?
A: TTL expiry affects the resolver's cache, not active TCP or application sessions. An established connection between 192.168.10.50 and 192.168.10.25 persists entirely independently of DNS. TTL expiry only matters when a new DNS query is initiated — for a new connection or when an application explicitly re-resolves the hostname. Long-lived connections are therefore unaffected by DNS record updates until the application reconnects.
Q: Why do some DNS lookups return multiple A records for the same hostname?
A: Multiple A records implement DNS round-robin load distribution. The authoritative server returns all configured A records, and most recursive resolvers rotate the order in successive responses. Clients typically connect to the first address returned. This provides basic traffic distribution at zero infrastructure cost, but it has no health checking — a failed server's IP continues to be returned even when it is unreachable. Use it only for stateless, health-monitored services or in combination with a higher-level load balancing layer.
Q: What is a negative cache and why does it matter?
A: When a DNS query returns NXDOMAIN (name does not exist) or NODATA (name exists but carries no records of the requested type), recursive resolvers cache this negative result to prevent hammering authoritative servers with repeated queries for known-nonexistent names. The duration of negative caching is controlled by the minimum TTL field in the zone SOA record. If you create a new hostname that previously returned NXDOMAIN, resolvers that cached that NXDOMAIN will continue returning it until their negative cache entry expires — set your SOA minimum TTL accordingly before adding new records.
Q: What is EDNS0 and why is it required in modern DNS?
A: EDNS0 (Extension Mechanisms for DNS, RFC 6891) extends the original DNS protocol by adding an OPT pseudo-resource record to DNS messages. It allows clients and servers to advertise a larger UDP payload size — up to 4096 bytes or more — enabling larger DNS responses that carry DNSSEC signatures, large TXT records, or many A records. EDNS0 also supports DNS cookies (RFC 7873) for lightweight query authentication and carries the DO (DNSSEC OK) flag that tells authoritative servers to include RRSIG signatures in responses. Without EDNS0, DNSSEC is effectively non-functional.
Q: What is a DNS zone transfer and how should it be secured?
A: A zone transfer replicates zone data from a primary authoritative server to one or more secondary servers. A full transfer is AXFR; incremental transfers (only records changed since a given serial number) are IXFR. An unsecured AXFR allows anyone to download a complete inventory of every hostname and IP in your zone — a significant reconnaissance aid. Zone transfers must be restricted using BIND's
allow-transferACL to known secondary server IPs, and authenticated with TSIG (Transaction SIGnatures) using a shared HMAC secret to prevent spoofed transfers.
Q: How does split-horizon DNS work and when should it be used?
A: Split-horizon (or split-brain) DNS returns different answers to the same query depending on the query source. Internal clients in 192.168.10.0/24 querying
vpn.solvethenetwork.comreceive the private RFC 1918 address 192.168.10.50, while external clients receive a public address or are redirected elsewhere. In BIND, this is implemented with views — named ACL-matched query contexts each serving a different zone file. Use split-horizon wherever internal services have both private and public-facing addresses and you want internal clients to avoid hairpinning through a firewall NAT.
Q: What is DNS cache poisoning and how does DNSSEC prevent it?
A: Cache poisoning is an attack in which a malicious actor races a legitimate DNS response, injecting forged records into a recursive resolver's cache to redirect users to attacker-controlled addresses. The Kaminsky attack (2008) demonstrated that with predictable transaction IDs and source ports, poisoning was practical at scale. Modern mitigations include randomized source ports (RFC 5452), 0x20 query bit randomization, and most decisively DNSSEC: because each record set is cryptographically signed by the zone's private key, a forged or modified record will fail signature validation at the resolver and be discarded regardless of how it arrived.
Q: What are glue records and when are they required?
A: Glue records are A or AAAA records for authoritative name servers that are included in the parent zone's delegation when the name server hostname falls within the zone being delegated. Without glue, resolving ns1.solvethenetwork.com requires querying solvethenetwork.com — but querying solvethenetwork.com requires knowing ns1.solvethenetwork.com's IP, creating a circular dependency. The .com TLD registry breaks this circularity by including glue A records (e.g., ns1.solvethenetwork.com A 192.168.10.10) directly in the delegating TLD zone. Glue is only strictly required when the NS hostname is within the delegated zone itself.
Q: How do recursive resolvers handle SERVFAIL responses?
A: SERVFAIL (RCODE 2) means the resolver was unable to complete the query — typically due to all authoritative servers being unreachable, a DNSSEC validation failure, or a broken zone configuration. Most resolvers briefly cache SERVFAIL (RFC 2308 recommends up to 5 minutes) to prevent retry storms. From a troubleshooting perspective, SERVFAIL is the most common symptom of broken DNSSEC (expired signatures, mismatched DS records) or authoritative server outages. Always check whether SERVFAIL is accompanied by the
ADflag being absent on a DNSSEC-signed zone.
Q: What is the minimum number of authoritative name servers required and why?
A: RFC 1034 requires a minimum of two authoritative name servers for any publicly delegated zone. This provides basic redundancy — if one server is unreachable, the second continues serving the zone. In practice, production zones should use at least two geographically separated servers (or anycast-distributed infrastructure) to survive datacenter failures and regional network partitions. Both servers must be listed in the parent TLD's delegation and must serve identical zone content, kept in sync via zone transfers (AXFR/IXFR) authenticated with TSIG.
Q: What does the AA (Authoritative Answer) flag mean and how is it useful for troubleshooting?
A: The AA flag in the DNS response header indicates that the responding server is authoritative for the queried zone — the answer came directly from the zone's source of truth, not from a resolver cache. When you query a recursive resolver and see AA=0, the resolver served a cached copy. To verify you are looking at the actual zone data, query the authoritative server directly:
dig @192.168.10.10 mail.solvethenetwork.com A. If the response sets AA=1, you are reading the authoritative record. If you query the authoritative server and get AA=0, something is wrong with the zone configuration on that server.