Zones

Zone vs. Domain

  • A domain is a logical division of the DNS namespace (e.g., example.com).
  • A zone is a physical/administrative division that contains the actual DNS data for that domain or part of it.
  • One domain can be split into multiple zones (e.g., example.com and dev.example.com as separate zones).
  • Or multiple domains can be in one zone if they’re managed together (less common).

Resolution

  • Top-down delegation

    • Root servers . → tell you the TLD servers (e.g., .com)

    • TLD servers (.com) → tell you the authoritative name servers for example.com

    • Authoritative name servers for example.com → give you the actual record (e.g., A record for example.com)

    • Delegation is implemented by NS records in the zone file, e.g.:

      blog.example.com. 3600 IN NS ns1.example.com.
blog.example.com. 3600 IN NS ns2.example.com.

    • Parent zone could handle example.com, while child zone handles blog.example.com.

  • DNS resolvers (like those from Google 8.8.8.8, Cloudflare 1.1.1.1, or your ISP) cache query results aggressively and interact with root servers and TLD servers on your behalf.

DNS Record Types

SOA

DNS - Specification

DNS - Performance

rDNS

  • Reverse DNS lookups query DNS servers for a PTR (pointer) record; if the server does not have a PTR record, it cannot resolve a reverse lookup. PTR records store IP addresses with their segments reversed, and they append ".in-addr.arpa." to that. For example if a domain has an IP address of 192.0.2.1, the PTR record will store the domain's information under 1.2.0.192.in-addr.arpa.

  • In IPv6, PTR records are stored within the ".ip6.arpa" domain instead of ".in-addr.arpa.".

  • Resource

Multicast DNS / mDNS

DNSSEC

DNS - Software

systemd-resolved

Dnsmasq

BIND

Unbound

NGINX

Google Admin Toolbox - Dig

Dynamic DNS

Troubleshooting

Common DNS issues that affect load balancers (causes and quick fixes)

1. TTL-related stickiness and slow failover

  • Cause: High DNS TTLs cause clients to keep using an IP returned earlier (including an unhealthy backend or old LB target).
  • Fix: Lower TTLs before planned changes; use health-aware DNS (GSLB) or shorter TTLs for failover-critical records.

2. CNAME/A record mismatch for managed LBs

  • Cause: Cloud load balancers often expose a DNS name (ALB/ELB/GLB). Pointing an A record to the LB DNS (instead of CNAME/ALIAS/ANAME) or using the wrong record type breaks resolution or routing.
  • Fix: Use the provider-recommended record type (CNAME/ALIAS/ANAME) or use an IP-based fronting service if static IPs are required.

3. DNS caching masking backend health changes

  • Cause: Recursive resolvers cache old responses; after an LB health change, clients still get cached answers.
  • Fix: Reduce TTLs, use a DNS provider with cache-control features, or implement connection-level health checks and global traffic steering (not-only-DNS).

4. Inconsistent resolver behavior (split-brain / split-horizon)

  • Cause: Internal and external resolvers receive different records or views, leading clients to hit wrong LB/backend.
  • Fix: Align zone data across views, ensure correct delegation and view ACLs, test from both networks.

5. DNS-based load balancing not load-aware

  • Cause: Round-robin or multi-A responses don’t consider server load or connection state; overloaded backends still receive traffic.
  • Fix: Use an application-aware load balancer (L4/L7) or DNS solutions with health/weighting and frequent health probes.

6. Glue/NS delegation issues for LB hostnames

  • Cause: Using in-zone nameservers for LB endpoints without proper glue causes unresolved delegation.
  • Fix: Add correct glue records at the registrar for any nameserver subdomains; verify delegation with dig +trace.

7. DNSSEC and validation failures

  • Cause: Mis‑signed zones or broken DNSSEC chain cause SERVFAIL at resolvers, preventing LB hostname resolution.
  • Fix: Validate signatures (dnssec-tools / named-checkzone), fix keys/signatures or temporarily disable DNSSEC while correcting.

8. PTR/reverse DNS mismatch for services behind LB

  • Cause: Reverse DNS doesn't match forward names expected by downstream services (mail, API whitelists), causing rejections.
  • Fix: Ensure PTRs map to LB or backend FQDN as required; coordinate with IP owner (cloud/ISP) for PTR changes.

9. Mixed IPv4/IPv6 (A/AAAA) inconsistencies

  • Cause: AAAA exists but backend/LB doesn’t properly support IPv6, so IPv6-capable clients fail while IPv4 succeed.
  • Fix: Ensure LB and backends support both protocols or remove the AAAA record until IPv6 is ready.

10. Health-check DNS resolution failure inside LB

  • Cause: Load balancer’s health checks target hostnames that the LB itself cannot resolve (wrong resolver settings, firewall).
  • Fix: Configure health checks to use IPs or ensure LB has access to correct DNS servers and that firewall allows DNS traffic.

11. Multiple delegation or zone overlap (split delegation)

  • Cause: Partial delegation or duplicate records across providers cause inconsistent answers; some clients hit old LB targets.
  • Fix: Consolidate records to a single authoritative zone, update NS records at the registrar, and remove stale records.

12. Wildcard records and unintended matches

  • Cause: Wildcard DNS entries match LB-related subdomains unintentionally, routing traffic incorrectly.
  • Fix: Replace wildcard with explicit records for LB subdomains or add explicit higher-priority records.

Diagnostic checklist (quick tests)

  • dig +trace example.com
  • dig @8.8.8.8 your-lb.example.com A/AAAA/CNAME +short
  • curl --resolve host:80:IP http://host/ (test specific resolved IP)
  • Test from multiple resolvers/locations (public DNS, internal DNS)
  • Verify TTLs and recent changes in registrar/hosted zone
  • Check DNSSEC status: dig +dnssec example.com
  • Confirm LB health-check logs and that LB can resolve DNS
Quantum Computing