Comprehensive understanding of the Domain Name System and the end to end name resolution process. Candidates should be able to explain the full query flow from a client stub resolver to a recursive resolver and onward to root name servers, top level domain name servers, and authoritative name servers, and to distinguish recursive and iterative queries and the roles of stub, recursive, and authoritative resolvers. Expected knowledge includes common resource record types and their purposes such as A and AAAA address records, CNAME alias records, MX mail exchange records, NS delegation records, SOA start of authority records and zone serials, TXT arbitrary text and verification records, PTR reverse mapping records, and SRV service records. Candidates should understand caching behavior, the role of time to live values and negative caching, how propagation delays occur, and how time to live choices affect rollouts and rollbacks. The topic covers operational impacts and common failures including misdelegation and missing glue records, stale caches and slow resolution, DNS cache poisoning and denial of service amplification, and mitigations such as domain name system security extensions, rate limiting, and validating authoritative responses. Candidates should be able to perform diagnostics using tools and commands such as dig, nslookup, host, tcpdump, and traceroute, and to run checks like querying authoritative servers, performing a trace of the resolution path, inspecting SOA serial numbers, and testing from multiple resolvers. Practical troubleshooting steps and best practices are expected, including zone verification, checking delegation chains, understanding resolver configuration and forwarders, and planning DNS changes to minimize user impact.
MediumTechnical
25 practiced
Define SLOs and an alerting strategy for a public authoritative DNS service. Recommend concrete targets (for example 99.99% resolution success, 95th percentile latency <100ms), describe synthetic probes to validate user experience, and explain how to implement error budgets and burn-rate alerts to avoid alert fatigue.
Sample Answer
SLOs (Service Level Objectives) specify measurable reliability targets for user-visible behavior; for an authoritative public DNS service they should focus on resolution success, latency, and consistency (no stale data).Recommended SLOs (global targets):- Resolution success: 99.99% per rolling 30d (<=4.3 min downtime/month)- Latency: 95th percentile < 100 ms for UDP queries, 99th < 250 ms- TTL/consistency: 99.999% of responses match authoritative data (no incorrect responses)- Zone-update propagation: 99% of updates visible within X minutes (define X per SLA)Synthetic probes to validate UX:- Globally-distributed active probing from multiple DCs/regions (real-user regions + cloud vantage points).- Query types: A/AAAA, CNAME, NS, SOA, and long/short TTLs; over UDP and TCP, with EDNS(0) and DNSSEC validation.- Frequency: per-region probes every 10–30s for latency, every 5m for full validation.- Compare responses to a canonical authoritative store; record success, response code, RDATA correctness, and response size.- Simulate client retries and resolver caching by varying source IPs and query names.Error budget & burn-rate alerts to avoid alert fatigue:- Compute error budget = (1 - SLO) * window (e.g., minutes in 30d). Track consumption from synthetic and real-user (RUM/Resolver logs) errors.- Multi-tiered burn-rate alerts: - Informational: burn rate >1x for 1h — ticket to investigate, no paging. - Actionable: burn rate >4x sustained for 30m — on-call notification. - Critical: burn rate >8x sustained for 15m — page SRE.- Use adaptive suppression: correlate alerts by region/anycast location and silence lower-priority alerts when a higher-level paging is active.- Tie policy to runbook: when error budget spend crosses thresholds, enact mitigation (rate-limit nonessential changes, roll back deploys, shift traffic).- Measure and tune: keep <1 noisy alert per week per on-call by iterating probe thresholds, using deduplication, grouping, and dynamic sampling.Why this works:- Synthetic probes approximate real-user experience from many vantage points; concrete SLOs give objective targets; burn-rate tiers prioritize impact and prevent paging for transient noise while enabling rapid response to sustained degradation.
HardTechnical
23 practiced
Design an idempotent Terraform-based approach to manage DNS records across multiple providers (for example Route 53 and Cloud DNS) ensuring safe updates, drift detection, provider-agnostic aliases, and rollback strategies. Provide a short HCL pseudo-code snippet and describe how you would handle provider-specific features like alias records or DNSSEC.
Sample Answer
Approach: model DNS as idempotent Terraform resources with a provider-agnostic abstraction layer (module) that maps logical records to provider-specific implementations. Use import/state locking, plan-based gating, automated drift detection (terraform plan vs state), and staged canary updates with DNS TTL management and automatic rollback via stored snapshots.HCL pseudo-code:
Module design (concepts):- Input: logical record (name,type,ttl,targets,alias,dnssec,providers)- For each provider, module contains provider-specific sub-resources: - aws: aws_route53_record (uses alias block when alias.enabled) - gcp: google_dns_record_set (translate alias to CNAME or synthesised A records; Google Cloud DNS supports ALIAS via synthetic records in Cloud DNS managed zones—use provider-specific flags)- Use lifecycle { create_before_destroy = true, prevent_destroy = false } and record-level ignore_changes for ephemeral fields (e.g., last_modified).- Manage TTL reduction before change: lower TTL, wait TTL window, apply change, then restore TTL.Drift detection & CI:- CI job runs terraform init + plan against each provider account; if plan != empty, fail build and create an alert/ticket.- Periodic drift scanner (scheduled job) runs terraform plan; if unexpected diffs, open incident and optionally run automated remediation after human approval.Safe updates & rollback:- Staged rollout: apply to a subset of zones/providers (canary) via targeted workspaces or tfvars; validate monitor metrics (DNS resolution, latency, errors).- Maintain remote state snapshots (versioned backend like S3/GCS with object versioning). Before risky change, create a state snapshot and save plan JSON.- Rollback flow: restore state snapshot and run terraform apply with saved plan or reapply previous config. Use automation to re-point records to previous IPs and increase TTLs.- Use provider locks (DynamoDB/GCS) to avoid concurrent applies.Handling provider-specific features:- Alias records: expose alias on module input; implement as provider-specific constructs: aws_route53_record alias block, Cloud DNS uses CNAME or Cloud DNS synthetic records; if unsupported, synthesize equivalent A records via resolving target and populating addresses with automation.- DNSSEC: store keys in secure secrets manager; module conditionally creates DNSSEC resources per provider (google_dns_managed_zone.dnssec_config, aws route53 DNSSEC is hosted zone signing and key signing resources). Abstract config so callers pass intent, not implementation.- Edge cases: handle propagation delays by decreasing TTL first; respect provider limits (rate limits, record size) and implement retries with exponential backoff for API errors.Key practices:- Keep records declarative and single source of truth in TF modules.- Use automated plan gating, monitoring, and human approvals for high-risk changes.- Test in staging zones and automate rollback using versioned state and saved plans.
MediumTechnical
25 practiced
Explain DNS amplification and reflection attacks. Describe how attackers use UDP, open resolvers, and large responses to amplify traffic, which record types historically amplify more (e.g., ANY), why EDNS increases amplification risk, and an operational mitigation plan for authoritative and recursive servers.
Sample Answer
DNS amplification/reflection is a DDoS technique where an attacker sends DNS queries with a spoofed source IP (the victim) to UDP-based DNS servers (reflectors). Because UDP is connectionless and small queries can trigger much larger responses, the attacker “amplifies” traffic: many bytes returned to the victim for each byte sent by the attacker.How it works (mechanics):- UDP allows spoofed source addresses so the responder sends replies to the victim.- Open resolvers or misconfigured authoritative servers will answer queries from anyone, providing reflectors.- Attackers choose queries that elicit very large responses (amplification factor = response size / request size). Historically ANY queries yielded big responses; others that amplify include TXT, MX, and DNSSEC-related records (RRSIG, DNSKEY) which are large.- EDNS(0) increases risk because it advertises larger UDP buffer sizes (so servers send larger UDP responses rather than truncating and forcing TCP), raising amplification potential.Operational mitigation plan (authoritative + recursive):1. Prevent spoofing network-wide - Enforce BCP 38/ RFC 2827 ingress filtering at border routers to block spoofed source IPs.2. Harden DNS servers - Disable or rate-limit ANY responses (return minimal data or NXDOMAIN/NOTIMPL). - Implement Response Rate Limiting (RRL) for authoritative servers and recursive resolvers to throttle identical responses to the same target IP. - Limit EDNS advertised size (cap UDP response size) and honor TC->require TCP only when necessary; prefer TCP for large responses. - Disable recursion on authoritative servers; restrict recursive resolvers to trusted clients via ACLs.3. Reduce open resolver surface - Audit for open resolvers and close or restrict them; configure recursion-only on deliberate resolvers with IP allowlists.4. Network & infra protections - Use upstream scrubbing/anycast DDoS mitigation services and load‑balanced, globally dispersed authoritative infrastructure. - Apply flow/ACL rate-limits at edge routers to drop or challenge high-volume UDP flows.5. Monitoring & incident runbook - Monitor DNS query rates, sudden spikes in ANY/TXT/DNSSEC queries, and unusual response volumes. - Maintain an incident playbook: enable RRL, throttle offending prefixes, engage scrubbing provider, and contact ISPs for upstream filtering.6. Testing & compliance - Regularly scan your own authoritative and recursive fleets for being open, test RRL and EDNS behavior, and review DNSSEC key size policies to avoid unnecessary large records.Trade-offs and notes:- RRL can slightly affect legitimate clients behind NATs (tune thresholds).- For heavy DNSSEC use, consider RFC-compliant packet-size tuning and encourage TCP fallback while balancing performance.- Combining network-level anti-spoofing, server-level RRL/ACLs, and external scrubbing provides layered protection.
HardTechnical
25 practiced
Your DNS logs show frequent unauthorized AXFR attempts from multiple IPs. How would you investigate whether data was exfiltrated, what immediate containment steps would you take, and what long-term policy, access control, and monitoring changes would you implement to prevent recurrence?
Sample Answer
Situation: My DNS logs show repeated unauthorized AXFR (zone transfer) attempts from multiple external IPs. I need to determine if any zone data left our network, stop ongoing transfers, and harden DNS to prevent recurrence.Investigation (forensics-focused):- Triage logs: gather DNS server logs (named/bind, PowerDNS, NSD), firewall logs, and SIEM records for timestamps/IPs. Search for successful AXFR responses (200/transfer completion) and large TCP connections on port 53. Filter by zone, source IP, and time window.- Capture/collect evidence: take immutable snapshots of DNS server logs, /etc/bind (or config), TSIG keys, and current zone files; export pcap of relevant traffic (tcpdump 'tcp port 53 and host X') and preserve checksums and timestamps for chain-of-custody.- Confirm exfiltration: look for completed AXFR exchanges (log entries showing X bytes sent), abnormal outbound bandwidth spikes, or external hosts completing full zone serials. Correlate with secondary/ slave servers—did any unauthorized host appear as a NOTIFY/AXFR client? Check transfer sizes vs expected zone sizes.- Check compromise indicators: review auth logs, ssh/console, cron, configuration changes, and access to TSIG keys or deploy keys. Scan authoritative servers for suspicious processes, new accounts, or lateral movement.- Query external reconnaissance: reverse-DNS and threat intel on source IPs, see if they belong to botnets, ISPs, or known scanners.Immediate containment:- Block offending IPs at perimeter firewall and WAF, and apply immediate iptables/ACL deny on authoritative servers. If many IPs, block by ASN or geofence if appropriate.- Temporarily disable zone transfers globally or for affected zones (set allow-transfer none).- If needed for internal clients, enable zone-transfer only to known slave IPs and disable AXFR over TCP from untrusted networks.- Rotate TSIG keys and revoke any keys that might be compromised; reload nameserver configs.- If authoritative server may be compromised, isolate it (network segment) and fail over to a clean standby; promote unaffected secondary(s) if using multi-primary design.- Preserve evidence and notify security/CSIRT, management, and legal if exfiltration is suspected.Long-term prevention (policy, access control, monitoring):- Access controls: - Enforce allow-transfer ACLs by explicit IP lists and restrict to specific slave servers. - Require TSIG with strong keys for zone transfers; store keys in an HSM or secrets manager with strict rotation policies. - Use DNS views to separate internal-only zones from public zones; ensure internal zones never served to public interfaces. - Implement principle of least privilege for admin access to DNS configs (RBAC, MFA, audited API tokens).- Policy and process: - Formalize change control for DNS and scheduled TSIG key rotation (e.g., 90-day rotation) and incident playbooks for DNS data loss. - Inventory all zones and authoritative servers; ensure documented owner/contact info and runbooks.- Monitoring and detection: - Create SIEM alerts for: AXFR attempts, large TCP/53 response sizes, high volume NOTIFYs, changes in zone serial number without authorized change, and any AXFR from non-whitelisted IPs. - Instrument flow/NetFlow and DNS query logging; baseline normal transfer patterns and alert on anomalies or outbound spikes. - Deploy eBPF/tcpdump-based detection for large DNS TCP responses and automate suspicious pcap capture. - Use IDS/IPS signatures for AXFR abuse; integrate threat intel to auto-block malicious ASNs. - Implement rate-limiting for DNS responses and consider TCP connection limits per IP to slow scanners.- Hardening & resilience: - Sign zones with DNSSEC to prevent tampering (note: DNSSEC doesn’t prevent AXFR but improves integrity). - Move internal sensitive records to split-horizon or private zones accessible only via internal resolvers. - Regularly audit DNS servers, run vulnerability scans, and rehearse incident response with tabletop exercises.- Verification: - After remediation, validate no unauthorized copies exist (ask ISPs/hosts identified if they received data); perform a post-incident audit and a blameless postmortem, tracking action items.Why this approach: immediate log/pcap evidence collection preserves proof; blocking and disabling transfers remove the active exfil path; rotating keys and tightening ACLs eliminate credential-based transfers; monitoring and alerting detect future abuse early; process and inventory reduce human/configuration error—together these steps restore safety and improve resilience.
EasyTechnical
26 practiced
Explain the end-to-end DNS name resolution flow from a client stub resolver to a recursive resolver and onward to the root name servers, TLD servers, and authoritative nameservers. Describe what is returned at each step (referral vs authoritative answer), the difference between recursive and iterative queries, where caching occurs, and two common failure points in the chain.
Sample Answer
Situation: A client wants to resolve example.com. The client stub resolver (typically in OS or browser) asks its configured recursive resolver (e.g., ISP or 8.8.8.8) to resolve the name.Flow:1. Stub → Recursive (recursive query): The stub asks the recursive resolver to fully resolve the name. The recursive resolver will do the work and return either the final answer or an error.2. Recursive → Root (iterative/querying root): If not cached, the recursive sends an iterative query to a root server. The root returns a referral: a list of TLD name servers for “.com” (not the final answer).3. Recursive → TLD servers (iterative): The recursive queries a TLD server; the TLD replies with a referral to the authoritative nameserver for example.com (often including glue records if needed).4. Recursive → Authoritative nameserver (iterative): The recursive queries the authoritative server, which returns an authoritative answer containing the requested A/AAAA record (or NXDOMAIN if the name doesn’t exist).5. Recursive → Stub: The recursive returns the authoritative answer to the stub and may mark TTLs for caching.Key distinctions:- Recursive query: client requests the resolver do all lookups and return final answer.- Iterative query: server returns best-known referral and expects the requester (here the recursive) to continue querying.Caching:- Occurs at recursive resolver and often at OS/browser stub; records cached with TTL from authoritative answers; root/TLD referrals can also be cached.Two common failure points:- Recursive resolver outage or misconfiguration (no resolver reachable, DNS misconfigs, firewall blocked UDP/53).- Authoritative nameserver failure or misconfigured NS records (authoritative server down, missing glue, wrong delegation causing NXDOMAIN or SERVFAIL).
Unlock Full Question Bank
Get access to hundreds of Domain Name System and Name Resolution interview questions and detailed answers.
