DNS, DHCP, and Name Resolution Questions

Definition and purpose:

• MX (Mail Exchange) records: specify which mail servers accept email for a domain. Each MX has a priority (lower = higher preference) and must point to a hostname that resolves to A/AAAA records. Email delivery agents then look up that A/AAAA.
• SRV (Service) records: designed for generic service discovery. An SRV record includes priority, weight, port, and target host. Clients use SRV to find not only the host but also the port to connect to for a given service/protocol.

Key DNS constraints:

• MX targets must resolve to A or AAAA records; you cannot set an MX record directly to an IP.
• A CNAME record creates an alias for a name and by DNS rules cannot coexist with any other record type at the same label (no other records like A, MX, SRV, TXT allowed at that exact name).
• SRV records can coexist with other records at different labels but follow normal label rules.

When to use SRV vs CNAME:

• Use SRV for true service discovery when you need: port information, load distribution via weight, and failover via priority (e.g., SIP, XMPP, LDAP, custom services). SRV lets clients pick host+port and consider weight/priority.
• Use CNAME when you simply want one DNS name to alias another name for simplification (e.g., www -> app.example.com) and you don’t need port metadata. Don’t use CNAME where other record types must exist at the same name (e.g., apex/zone root) because CNAME forbids coexisting records.
• Don’t use MX or SRV pointing to a CNAME target: best practice is targets should resolve to A/AAAA directly to avoid extra indirection and potential compatibility issues.

SRE implications:

• For service discovery in production, prefer SRV when clients support it; otherwise use a combination of A/AAAA + external service registry (Consul, DNS SRV via ingress) or use CNAMEs carefully for HTTP where port is standard. Ensure monitoring and client libraries handle SRV semantics (weight/priority) and validate DNS TTLs and failover behavior.

Incident goal: stop amplification, restore authoritative server availability, and prevent recurrence while preserving legitimate DNS traffic.

Immediate containment (first 0–30 minutes)

• Activate incident bridge, notify on-call, upstream ISPs, and DNS registrars.
• Apply coarse network-level filters at edge and upstream: null-route obvious attacker source subnets (with ISP help), rate-limit UDP/53 flows, and drop packets with forged source IPs if possible.
• Redirect traffic through scrubbing provider or DDoS mitigation service (BGP announce prepends to failover AS if pre-configured).
• Raise logging/pcap sampling for a subset of traffic; avoid full capture to prevent overload.

DNS-specific short-term mitigations (30 min–3 hours)

• Enable Response Rate Limiting (RRL) on authoritative servers and authoritative front-ends; tune thresholds to protect low-volume clients.
• Temporarily disable recursion and hide any recursion-capable services; ensure authoritative-only mode.
• Drop or NXDOMAIN/REFUSE for expensive query types and records commonly abused (ANY queries, large TXT, DNSSEC/TYPE255), returning minimal responses.
• Lower EDNS buffer sizes and disable EDNS0 DNSSEC validation on respond servers to reduce amplification factor.
• Serve minimal TTL and cached negative responses where safe.

Mid-term remediation (3 hours–72 hours)

• Keep scrubbing or upstream filtering until attack subsides; continuously tune RRL and filtering based on analytics.
• Rotate authoritative server IPs if spoofed responses cause cache poisoning risk; coordinate with registrars for glue changes.
• Run postmortem to identify gaps (telemetry, BCP38 compliance of peers).

Long-term architecture & prevention

• Deploy Anycast for authoritative DNS across multiple PoPs to absorb and distribute volumetric load; combine with local RRL and local rate limits.
• Contract with multiple scrubbing/DDoS providers and pre-configure BGP failover playbooks.
• Implement egress/ingress source validation (BCP38) advocacy with ISPs and require for colocation providers; monitor upstream compliance.
• Harden DNS stack: authoritative-only appliances, response signing separation, and minimum amplification configurations (disable ANY/large TXT, configure DNSSEC carefully).
• Improve monitoring: per-source, per-subnet metrics, RRL hit rates, query-type heatmaps, automated alarms.
• Run tabletop drills, update runbooks with thresholds, contacts, and automated scripts for failover and RRL tuning.

Trade-offs and considerations

• Aggressive filtering/RRL may break legitimate low-volume resolvers—use graduated thresholds and whitelist known resolvers.
• Anycast + scrubbing increases operational complexity but enormously improves resilience to amplification attacks.

Success metrics

• Restore <1% normal query latency, reduce dropped/failed responses to acceptable SLOs, and eliminate amplification factor seen on egress. Post-incident: zero repeat of same vector within 6 months.

Situation: Encrypted DNS (DoH/DoT) shifts DNS from plaintext to TLS/HTTPS, which improves user privacy but reduces traditional enterprise visibility and inline controls.

Impact on enterprise visibility, policy enforcement, monitoring:

• Loss of passive DNS logs: security tools and SIEMs that rely on network DNS telemetry (pcap/NIDS, DNS sinks) see fewer or no queries.
• Policy bypass: users/apps using external DoH endpoints can evade DNS-based content filtering, malware blocking, and internal split-horizon resolution.
• Monitoring gaps: service discovery, synthetic checks, and health dashboards that depend on corporate DNS telemetry may miss client-side failures.
• Operational risk: harder to correlate incidents (DNS errors vs. network vs. app).

Deployment options and trade-offs:

1. Block third-party DoH/DoT at network edge (port filtering, SNI/ALPN inspection, firewall rules)

• Pros: preserves existing DNS stack and controls with minimal changes.
• Cons: arms race with clients; TLS 1.3/ESNI complicates detection; false positives; user privacy reduced.
• Perf: low overhead on infra; minimal latency change.

2. Enterprise DoH proxy (transparent proxy that intercepts and decrypts DoH to apply policy)

• Pros: preserves user privacy over wire while restoring visibility and enforcement by funneling through corporate proxy; integrates with SIEM and content filters.
• Cons: requires TLS interception or client cooperation, certificate management, potential legal/privacy implications; increased latency and single-point-of-failure risk; scaling/HA needs careful SRE design.
• Perf: adds TLS termination and parsing overhead; plan autoscaling and caching.

3. Managed enterprise DoH endpoint (provide internal DoH/DoT resolver and enforce via network/DHCP/Group Policy)

• Pros: native support for modern protocols without TLS interception; simplest privacy-respecting enterprise control; easier telemetry collection at resolver.
• Cons: requires client configuration or device management; third-party apps may ignore system resolver; must secure and scale resolver clusters.
• Perf: comparable to traditional DNS if optimized (UDP fallback not available for DoH), benefit from caching and local authoritative hints.

SRE considerations:

• Ensure high availability and geo-distribution of resolvers/proxies, autoscaling, rate-limiting, and caching tiers.
• Instrument end-to-end DNS metrics (latency, error rate, cache hit ratio) and emit logs to SIEM with privacy-aware retention.
• Provide clear privacy policy and least-privilege telemetry to satisfy legal/employee trust.
• Plan for rollout: detect DoH clients, pilot managed DoH, measure latency and failure modes, and automate fallback/rollback.

Recommendation: Prefer managed enterprise DoH endpoint combined with blocking unknown external DoH and robust telemetry; use proxies only when unavoidable, and treat TLS interception as last resort with strict governance and scaling plans.

Approach: show practical commands and brief explanations for dig, nslookup, and host to (1) query a specific authoritative server, (2) trace resolution path, and (3) request without recursion. Then compare tools and explain when to use packet capture.

Query a specific authoritative server (example: ask ns1.example-axfr.net at 198.51.100.10 for example.com A record)

# dig
dig @198.51.100.10 example.com A

# nslookup (interactive or one-liner)
nslookup -query=A example.com 198.51.100.10

# host
host example.com 198.51.100.10

Trace the resolution path (show iterative delegation from root -> TLD -> authoritative)

# dig +trace shows iterative walk using system root hints
dig +trace example.com

# host has -t option but not a built-in trace; use dig for trace. nslookup doesn't implement full trace.

Disable recursion (ask an authoritative server to respond as non-recursive)

# dig with +norecurse (or +norec)
dig @198.51.100.10 example.com A +norec

# nslookup: set norecurse in interactive mode
nslookup
> server 198.51.100.10
> set norecurse
> example.com

# host doesn't expose recursion flag; use dig or tcpdump to inspect flags

Notes on flags/answers:

• Look for "ra" (recursion available) in dig’s flags, and check the RCODE and answer vs. authority sections.
• For axfr/zone-transfer testing: dig @server example.com AXFR

Tool differences and when to use each:

• dig: preferred for SREs — powerful, scriptable, displays sections, supports +trace, +norec, and detailed flags.
• nslookup: older, interactive-friendly; fine for quick checks but deprecated in some platforms.
• host: simple, human-friendly mappings; good for quick lookups but less feature-rich for debugging.
• Use packet capture (tcpdump/wireshark) when:
  • You need to see raw DNS wire traffic (flags, EDNS, truncation, TCP fallback, DoT/DoH negotiation).
  • Diagnosing retransmits, malformed packets, fragmentation, or server not receiving queries.
    Example tcpdump capture for UDP DNS on port 53 to/from that server:

sudo tcpdump -i any host 198.51.100.10 and port 53 -w dns.pcap

Summary: Use dig for deep debugging and scripts, nslookup/host for quick checks, and tcpdump/wireshark when you must inspect packet-level behavior or confirm on-the-wire flags and transport issues.

A — Address record

• Purpose: Maps a hostname to an IPv4 address.
• Pitfall: Stale IPs after autoscaling or failover cause outages; TTL too long delays propagation.
• Example: myapp.example.com → 93.184.216.34 for a public web service front-end.

AAAA — IPv6 address record

• Purpose: Maps a hostname to an IPv6 address.
• Pitfall: Clients or networks without IPv6 can fail; dual-stack misconfiguration leads to asymmetric routing.
• Example: ipv6.example.com → 2001:0db8::1 to announce IPv6-enabled service.

CNAME — Canonical name (alias)

• Purpose: Alias one name to another (must point to a hostname).
• Pitfall: Cannot coexist with other records (e.g., cannot have CNAME and MX at same name); adds lookup latency.
• Example: www.example.com CNAME to myapp.example.com for CDN or multi-host routing.

MX — Mail exchange

• Purpose: Specifies mail servers for a domain and priority.
• Pitfall: Wrong priority or missing backup MX causes mail loss; using CNAME targets is invalid.
• Example: example.com MX 10 mail1.example.com for inbound email.

NS — Name server

• Purpose: Delegates a zone to authoritative name servers.
• Pitfall: Inconsistent NS records between parent and child or glue records missing cause resolution failures.
• Example: Delegating sub.example.com to ns1.subnet.example.net.

SOA — Start of Authority

• Purpose: Zone metadata (primary NS, admin, serial, TTLs, refresh/retry/expire).
• Pitfall: Incorrect serial semantics breaks zone propagation; aggressive TTLs cause cache issues.
• Example: Zone SOA updated when pushing DNS changes; bump serial for zone transfer.

TXT — Text record

• Purpose: Arbitrary text (SPF, DKIM, verification, config).
• Pitfall: Long TXT entries can exceed UDP limits; improper SPF syntax breaks email delivery.
• Example: example.com TXT "v=spf1 include:_spf.example.net -all" for email validation.

PTR — Pointer (reverse DNS)

• Purpose: Maps IP to hostname for reverse DNS lookups.
• Pitfall: ISPs control PTRs for assigned IPs; mismatch between PTR and forward A causes mail rejection.
• Example: 34.216.184.93.in-addr.arpa PTR mail.example.com for SMTP HELO validation.

SRV — Service locator

• Purpose: Maps a service to hostname/port with priority/weight (used by SIP, LDAP, Kubernetes service discovery).
• Pitfall: Many clients ignore SRV; DNS TTL and load-balancing semantics differ from HTTP LB.
• Example: _sip._tcp.example.com SRV 10 60 5060 sip1.example.com to discover SIP servers.

Use: as an SRE, pick the right RR for intent, keep TTLs appropriate for operational flexibility, validate via forward/reverse consistency, and automate DNS changes and checks in CI/CD to avoid human error.