DNS & DHCP Interview Questions & Answers

DNS (Domain Name System) is the internet's distributed directory that translates human-friendly names like example.com into the machine IP addresses (for example an IPv4 like 93.184.215.14 or an IPv6 address) that computers actually use to connect.

Think of it like the contacts app on your phone: you remember "Mom", not her 10-digit number. DNS does the same for the web, so you type a name instead of memorizing IPs that can also change behind the scenes.

The core problem it solves is human memorability vs. machine routing — names are easy for people, numbers are needed by the network — while also adding a layer of flexibility (you can move a site to a new IP and just update DNS).

👉 Interview tip: Say "name-to-IP resolution" in your first sentence — interviewers want that exact phrase.

DNS uses port 53 on both transports. By default it runs over UDP because most queries and replies are small and fit in a single packet — UDP is fast and connectionless, with no handshake overhead.

DNS switches to TCP (also port 53) when the response is too large to fit reliably in one UDP datagram. Classic triggers:

• Zone transfers (AXFR/IXFR) between primary and secondary servers — always TCP.
• Large responses, e.g. many records, DNSSEC signatures, or when a server sets the TC (truncated) flag, telling the resolver to retry over TCP.

Modern EDNS0 lets resolvers advertise a larger UDP payload (commonly 1232 bytes today, after fragmentation concerns trimmed the older 4096 default), but TCP fallback is still the safety net. Note that encrypted DNS uses different ports — 853 for DoT and DoQ, 443 for DoH.

👉 Interview tip: Remember the rule: UDP for queries, TCP for zone transfers and truncated/large responses.

An FQDN (Fully Qualified Domain Name) is the complete, unambiguous name of a host — it specifies the exact position in the DNS tree, leaving nothing to guess. Reading www.example.com. right to left:

• . (trailing dot) — the root zone, the silent top of the hierarchy. Its presence is what makes a name "fully qualified."
• com — the TLD (Top-Level Domain).
• example — the SLD (Second-Level Domain), the registered name.
• www — a subdomain / hostname label within example.com.

Like a postal address read bottom-up: country to state to city to street. The trailing dot is the "country" — usually hidden, but always there.

👉 Interview tip: Stress that the trailing dot = root, and that DNS resolves right-to-left.

The core record types every engineer should know:

• A — maps a name to an IPv4 address (e.g. example.com to 93.184.215.14).
• AAAA — maps a name to an IPv6 address.
• CNAME — an alias pointing one name to another canonical name (e.g. www to example.com).
• MX — names the mail server for a domain, with a priority value (lower = preferred).
• NS — delegates a zone to its authoritative name servers.
• PTR — reverse DNS: maps an IP back to a name (used in mail anti-spam checks).
• TXT — arbitrary text; used for SPF, DKIM, DMARC and domain verification.
• SOA — Start of Authority: zone metadata (primary server, serial, timers).

👉 Interview tip: Group them: address (A/AAAA), aliasing (CNAME), mail (MX), delegation (NS/SOA), reverse (PTR), policy (TXT).

An A record maps a name directly to an IPv4 address — it's the final answer. A CNAME is an alias: it says "this name is really another name; go resolve that instead," forcing a second lookup.

You cannot put a CNAME at the zone apex (the bare example.com) because of RFC 1034's rule: a CNAME cannot coexist with any other record of the same name. The apex must hold mandatory records like SOA and NS. A CNAME there would collide with them, so it's forbidden.

It's like a mail-forwarding label that says "redirect everything" — but the apex address must also keep its official registration paperwork (SOA/NS) on file, so you can't slap a blanket forward on it.

👉 Interview tip: Mention ALIAS / ANAME / CNAME-flattening records (Cloudflare, Route 53) as the modern workaround for apex aliasing.

DNS is an inverted tree, resolved top-down during a recursive lookup:

• Root (.) — the apex. Served by 13 named root-server identities (A–M), operated by 12 organizations and backed by well over a thousand anycast instances worldwide. They don't know your IP; they point to the right TLD servers.
• TLD — .com, .org, .in, etc. Run by registries (e.g. Verisign for .com). Their authoritative servers point you to the domain's name servers.
• SLD (Second-Level Domain) — the registered name, e.g. example in example.com. Its authoritative name servers (set via NS records) hold the real records.
• Subdomain — e.g. www or mail; usually served by the same authoritative servers, or delegated further.

Like an address drilling down: country to state to city to house.

👉 Interview tip: Note that each tier only knows the next tier down — that delegation is what makes DNS scale.

The SOA (Start of Authority) record defines the zone's authority and replication behavior. Its fields:

• MNAME — the primary authoritative name server.
• RNAME — the admin email (with the @ written as a dot).
• Serial — version number; secondaries pull updates when it increases.
• Refresh / Retry / Expire — timers for secondary servers to sync with the primary.
• Minimum — a TTL value (originally the zone's default record TTL).

Per RFC 2308, the Minimum field now governs negative caching: when a name doesn't exist (an NXDOMAIN) or has no record of the requested type (NODATA), resolvers cache that negative answer for the lesser of the SOA minimum and the SOA record's own TTL. This stops repeated lookups for typo'd or missing names from hammering the authoritative servers.

👉 Interview tip: Say "SOA minimum = how long a negative answer (NXDOMAIN/NODATA) is cached" — that crisp link impresses interviewers.

All three are published as TXT records in DNS and work together to prove an email genuinely comes from your domain — stopping spoofing.

• SPF (Sender Policy Framework) — a TXT record listing which mail servers/IPs are allowed to send for your domain. The receiver checks the message's envelope sender (Return-Path) against that list.
• DKIM (DomainKeys Identified Mail) — the sender cryptographically signs each message; the receiver fetches your public key from a DKIM TXT record (at selector._domainkey.example.com) to verify the signature wasn't tampered with.
• DMARC — a TXT record (_dmarc.example.com) that ties SPF and DKIM together with alignment and tells receivers what to do on failure (p=none, quarantine, or reject), plus where to send reports.

SPF = guest list, DKIM = tamper-proof seal, DMARC = the policy and audit log.

👉 Interview tip: Stress that DMARC's job is alignment — SPF or DKIM must pass and match the visible From domain.

These are specialized records that extend DNS beyond simple name-to-IP:

• SRV (Service) — advertises which host and port a named service runs on, plus priority/weight. Scenario: a SIP or XMPP client queries _sip._tcp.example.com to auto-discover the server and port — no hardcoding.
• CAA (Certification Authority Authorization) — declares which CAs may issue TLS certificates for your domain. Scenario: you set 0 issue "letsencrypt.org" so that only Let's Encrypt can issue, and any other CA must refuse the request at issuance — a real defense against mis-issued or fraudulently obtained certificates.
• NAPTR (Naming Authority Pointer) — uses regex/rules to rewrite a name into another URI/service, often chained with SRV. Scenario: ENUM telephony maps a phone number to a SIP URI for VoIP routing.

👉 Interview tip: Pair them: SRV = service discovery, CAA = cert governance, NAPTR = rule-based rewriting (VoIP/ENUM).

Five players cooperate to turn a name into an IP. Think of it like asking a librarian to find a book from a vague description.

• Stub resolver — the tiny client built into your OS/browser. It just asks one question and waits for the final answer.
• Recursive resolver — your ISP's server or a public one like 8.8.8.8 / 1.1.1.1. This is the librarian who does the legwork on your behalf.
• Root server — points the resolver toward the right TLD servers. There are 13 named root identities (a.root-servers.net through m.root-servers.net), but each is actually hundreds of anycast instances worldwide, not 13 physical boxes.
• TLD server — handles the suffix like .com or .in and points to the domain's authoritative server.
• Authoritative server — holds the real records for that exact domain and gives the final answer.

Interview tip: Stress that the stub asks once; the recursive resolver does all the chasing. Correct the common myth that there are only 13 root servers — there are 13 named identities, but 1,900+ anycast instances.

TTL (Time To Live) is a number of seconds attached to every DNS record that says, in effect, "you may reuse this answer for this long before asking again." A record with TTL 3600 can be cached for one hour. It is like an expiry date stamped on milk — once it passes, you fetch fresh.

The same answer gets cached at several layers, each checked in order before a query is sent upstream:

1. Browser cache — Chrome/Firefox keep their own short-lived DNS cache (in Chrome, inspect it at chrome://net-internals/#dns).
2. OS / stub resolver cache — the Windows DNS Client service, or systemd-resolved on most modern Linux distros.
3. Recursive resolver cache — your ISP or public resolver, which caches the answer on behalf of many users.

Any layer holding a non-expired copy answers instantly, so the full root-to-authoritative chain only runs when every copy has expired.

Interview tip: Lower TTL means faster propagation of changes but more queries and load.

The difference is who does the chasing.

• Recursive query — the client demands a final answer: "Give me the IP, do not send me anywhere else." The receiver must either return the full answer or an error. This is what your stub resolver sends to the recursive resolver.
• Iterative query — the receiver replies "I do not know, but ask this server next" (a referral). The asker then queries the next server itself.

The recursive resolver is the component that actually performs the recursion: it accepts your one recursive request, then fires iterative queries to a root server, then a TLD server, then the authoritative server, following each referral until it has the answer, and hands the final result back to you.

Analogy: you tell one assistant "just get me the answer" (recursive); that assistant hops desk to desk asking "who knows next?" (iterative).

Interview tip: Root and TLD servers only answer iteratively — they never recurse on your behalf.

Assume nothing is cached anywhere and we want www.example.com:

1. The stub resolver sends one recursive query to the configured recursive resolver.
2. The resolver, finding nothing cached, asks a root server: "where is .com?" The root replies with a referral to the .com TLD servers.
3. The resolver asks a .com TLD server: "where is example.com?" The TLD replies with a referral (NS records) to example.com's authoritative nameservers.
4. The resolver asks the authoritative server for www.example.com. It returns the final A/AAAA record with a TTL.
5. The resolver caches that answer for the TTL and returns it to the stub resolver, which hands the IP to the browser.

Steps 2 to 4 are iterative referrals; only step 1 is recursive. Next time, the cache short-circuits this whole walk.

Interview tip: Name the record types — NS at each referral, A/AAAA at the end.

Negative caching means a resolver remembers a failure, not just a success. When a lookup returns NXDOMAIN ("this name does not exist") or an empty answer for a record type (NODATA), the resolver caches that negative result so it does not re-ask upstream for every repeat query.

The lifetime is not the record's TTL (there is no record). Instead, per RFC 2308, it is the smaller of the SOA record's TTL and the MINIMUM field inside that SOA, both returned in the AUTHORITY section. So if a typo'd or deleted name is queried a thousand times a second, the resolver answers "does not exist" from memory instead of hammering the root, TLD, and authoritative servers each time.

Analogy: a librarian who, once told a book is not in the catalogue, writes it on a sticky note so she does not re-search every time someone asks.

Interview tip: Mention RFC 2308 and that the negative TTL comes from the SOA (the lesser of the SOA's own TTL and its MINIMUM field), not from any missing record — that detail impresses.

TTL trades agility against load and resilience.

• Low TTL (e.g. 60s): changes propagate fast and failover is quick, but resolvers re-query constantly — more DNS traffic, slightly slower average page loads, and heavier dependence on your nameservers being reachable.
• High TTL (e.g. 86400s): fewer queries, faster cache hits, and better survivability if your DNS provider has a blip — but a change can take a full day to reach everyone.

The standard move before a planned migration: lower the TTL well in advance. If a record sits at TTL 86400, drop it to 300 at least one full old-TTL window (a day, here) before the cutover. Once the old high TTL has fully expired everywhere, the short TTL is what is cached, so when you flip the IP almost everyone picks it up within minutes. Raise the TTL back afterward.

Interview tip: The catch — you must lower the TTL one full old-TTL period before the change, or the short TTL will not have taken effect yet.

Classic DNS over UDP capped a response at 512 bytes (RFC 1035). If an answer was bigger, the server set the TC (truncated) bit, and the client had to retry over TCP to get the full reply.

EDNS0 (RFC 6891) lets the client advertise a larger UDP buffer via an OPT pseudo-record, so big responses — DNSSEC signatures, many A records, large TXT — can fit in UDP without truncation.

The hazard is the middle ground: if a UDP datagram exceeds the path MTU (commonly ~1500 bytes), it gets IP-fragmented, and fragments are frequently dropped by firewalls and NAT, causing silent timeouts. That is why the modern consensus from DNS Flag Day 2020 standardized on advertising a 1232-byte EDNS buffer — small enough to stay under typical MTUs and avoid fragmentation, with truncation plus TCP fallback as the safety net for anything larger.

Interview tip: The failure mode is dropped fragments; the fix is a 1232-byte buffer plus TCP fallback.

Goal: internal users get internal answers, the public gets external answers, and resolution survives a site failure.

• Anycast resolvers — advertise the same resolver IP (e.g. 10.0.0.53) from multiple data centres via BGP. Clients always reach the nearest healthy node; if one site dies and withdraws the route, traffic silently re-routes to another. No client reconfiguration needed.
• Split-horizon (split-brain) DNS — the authoritative servers serve two views of the same zone. Internal clients querying app.corp.com get the private RFC 1918 IP; external clients get the public/edge IP. The server selects the view by source IP.
• Conditional forwarders — on the enterprise resolver, forward specific zones to specific upstreams: e.g. corp.local to the AD/internal DNS, partner.com to a partner's resolver over a tunnel, everything else to recursion or a public resolver.

Layer in redundant resolver pairs per region, health-checked anycast route withdrawal, and DNSSEC validation. The result is location-aware, failure-tolerant, view-correct resolution.

Interview tip: Split-horizon decides what answer; anycast decides which node answers.

TTL 3600 only bounds well-behaved caches. Walk the chain and check each layer:

• Authoritative server — confirm the change actually published. If you run secondaries, did the zone transfer complete? Check that the SOA serial incremented and the secondaries synced. A stale master is the real culprit surprisingly often.
• Recursive resolver — it may have cached the old record just before your change and is still inside its 3600s window, or it is mishandling the TTL. Verify with dig @resolver name and read the countdown TTL.
• Forwarders / corporate caching layers — a chain of forwarders each re-caches, so the effective lifetime can stack beyond 3600s.
• OS stub cache — flush with ipconfig /flushdns (Windows) or resolvectl flush-caches (Linux with systemd-resolved).
• Browser cache — in Chrome, clear it at chrome://net-internals/#dns.
• Hardcoded data — a stale hosts file entry, or a pinned CDN/HTTP keep-alive connection, bypasses DNS entirely.

Interview tip: Always verify the authoritative answer first with dig +trace — fix the source before chasing caches.

DHCP (Dynamic Host Configuration Protocol) automatically hands out IP configuration to devices when they join a network, so nobody has to type settings by hand. Beyond the IP address, it also delivers the subnet mask, default gateway, DNS servers, and lease time.

Think of it like a hotel front desk: you walk in (connect), the desk assigns you a room number (IP) for the length of your stay (lease), and tells you where the lift and exit are (gateway/DNS).

DHCP runs over UDP. The server listens on port 67 and the client uses port 68. A handy way to remember: 67 = serve(r), 68 = the client next door.

Interview tip: Always say UDP (not TCP) and name both ports — 67 server, 68 client. If asked why fixed ports on both ends: the client has no IP yet, so the reply has to come back to a well-known port (68) rather than an ephemeral one.

The four-step handshake is called DORA:

1. D — Discover: The client broadcasts a DHCPDISCOVER looking for any DHCP server ("Is anyone out there who can give me an address?").
2. O — Offer: A server replies with a DHCPOFFER proposing an available IP and config.
3. R — Request: The client broadcasts a DHCPREQUEST formally accepting that offered address. The broadcast also tells any other servers that offered "I'm taking this one, not yours" so they can withdraw their offers.
4. A — Acknowledge: The chosen server confirms with a DHCPACK, locking in the lease.

Like ordering food: you ask what's available (Discover), the waiter offers a dish (Offer), you confirm your order (Request), and the kitchen confirms it's being made (Ack).

Interview tip: Memorise the acronym DORA — it's the single most-asked DHCP question. Bonus point: if the server can't honour the request, it replies with a DHCPNAK instead and the client restarts at Discover.

A DHCP lease is a time-limited "rental" of an IP address. The server doesn't give the address away forever — it loans it for a set lease duration (e.g. 8 hours, 1 day). Before the lease expires, the client tries to renew so it can keep the same address; if it goes away and never renews, the address eventually returns to the pool for someone else.

A scope (also called a pool) defines everything for one subnet: the range of IP addresses the server can give out, plus options like the subnet mask, default gateway, DNS servers, and lease time. One scope usually maps to one subnet or VLAN.

Like a library: each book (IP) is checked out for a due date (lease), and the catalogue section (scope) defines which books are available to lend.

Interview tip: Lease = rental with a clock; scope = the address range plus options for one subnet.

It starts with a broadcast because the client has no IP address yet and doesn't know where any DHCP server is. With no source address and no server location, the only way to reach "anyone who can help" is to shout to everyone on the local segment — destination 255.255.255.255, source 0.0.0.0.

What happens after that depends on the broadcast (B) flag the client sets in the Discover:

• Discover — always broadcast (the client knows nothing yet).
• Offer and Ack — usually unicast. Per RFC 2131, if the client leaves the broadcast flag clear (the common default), the server sends the Offer and Ack as L3 unicast to the offered IP, addressing the frame to the client's known MAC. Only if the client's IP stack can't receive a unicast before it's configured does it set the broadcast flag, forcing those replies to be broadcast.
• Request — broadcast in the initial DORA, so all servers that made an offer hear which one the client chose and the non-selected servers release their offers.

Later, when the client renews an existing lease, it already has an IP and knows its server, so the renewal Request and its Ack are unicast.

Interview tip: The headline is "no IP yet = must broadcast for Discover." If pushed on Offer/Ack, the precise answer is "it depends on the broadcast flag — unicast by default, broadcast if the client sets the flag."

A DHCP client doesn't wait for the lease to fully expire — it tries to renew early using two timers.

• T1 (Renewal) — fires at 50% of the lease. The client sends a unicast DHCPREQUEST directly to its original server asking to extend the lease. A DHCPACK resets the clock and the client keeps the same IP.
• T2 (Rebind) — fires at 87.5% (7/8) of the lease. This only happens if T1 renewal failed (original server is down or unreachable). The client now broadcasts a DHCPREQUEST to any server that can extend the lease.

If even rebind fails by 100%, the lease expires, the client drops the IP, and starts DORA over from Discover.

Like a magazine subscription: at the halfway point you quietly renew with your provider (T1); if they don't answer, near the end you ask any provider to keep you covered (T2).

Interview tip: Remember the exact numbers — T1 = 50%, T2 = 87.5% — and that T1 is unicast to the original server while T2 is broadcast to any server.

All three control how addresses inside a scope are used:

• Dynamic pool: the normal range of addresses DHCP freely hands out, first-come-first-served. Use it for ordinary clients — laptops, phones, desktops — that don't care which address they get.
• Reservation: a specific IP permanently tied to a device's MAC address (or DHCP client identifier), so that device always gets the same IP through DHCP. Use it for printers, servers, APs, or cameras that need a stable address but that you still want managed centrally — better than hand-configuring static IPs on each device.
• Exclusion: a range inside the scope that the DHCP server is told to never give out. Use it to protect IPs that are statically assigned outside DHCP (e.g. the gateway, switches, firewalls) so DHCP can't hand out a duplicate.

Like a parking lot: most spots are open parking (pool), a few are "Reserved — Mr. Sharma" (reservation), and some are coned off so nobody parks there (exclusion).

Interview tip: Reservation = always-same IP via MAC, still served by DHCP; exclusion = an address DHCP never hands out at all.

DHCP carries extra settings as numbered options alongside the IP address:

• Option 3 — Router / Default Gateway: the gateway the client uses to reach other networks.
• Option 6 — DNS Servers: the DNS resolver(s) for name lookups.
• Option 15 — Domain Name: the DNS suffix (e.g. corp.local) appended to unqualified hostnames.
• Option 51 — Lease Time: how long the lease is valid (drives the T1/T2 timers).
• Option 66 — TFTP Server Name: where to fetch the boot file from (a server name or IP).
• Option 67 — Bootfile Name: the exact boot file to download.

PXE boot (network boot, no local OS) depends on 66/67 because a diskless or freshly-imaged machine has nothing local to boot from — it needs DHCP to tell it which server (66) and which file (67) to download its boot image from. Without them, PXE has no target. (In larger PXE setups options 66/67 are sometimes replaced by options 60/43 or DHCP Proxy/IP Helper to a dedicated PXE/WDS server, but 66/67 is the classic answer.)

Interview tip: Map them fast — 3 = gateway, 6 = DNS, 15 = domain, 51 = lease, 66/67 = PXE boot server + file.

Broadcasts don't cross routers, so a client on one subnet normally can't reach a central DHCP server on another. The fix is a DHCP relay agent (Cisco configures this with ip helper-address) — usually on the router or SVI for that subnet.

When the relay hears a DHCPDISCOVER broadcast, it converts it to a unicast and forwards it to the configured DHCP server's IP. Crucially, it stamps the GIADDR (Gateway IP Address) field with its own interface IP on the client's subnet. The server uses GIADDR for two things: to pick which scope to lease from (the scope whose subnet matches GIADDR), and to know where to send the reply — back to the relay, which then delivers it to the client.

Option 82 (DHCP Relay Agent Information) adds finer detail the relay inserts — such as the exact switch port / circuit ID the client connected on (Circuit ID) and which relay device it came through (Remote ID) — enabling per-port policy, tighter assignment, and abuse tracking.

Like posting a letter abroad: your local post office (relay) repackages it, addresses it to the right sorting centre (server), and stamps the return address (GIADDR) so the reply finds its way home.

Interview tip: The one-liner they want is "ip helper-address relays the broadcast as unicast, and GIADDR tells the server which scope to use and where to reply."

You never want a single DHCP server — if it dies, no one gets addresses. Common redundancy designs:

• Split-scope (80/20): two servers cover the same subnet; one owns roughly 80% of the range, the other ~20%, so either can keep leasing if its partner fails. Simple, but the two servers don't share lease state.
• DHCP Failover with shared state: two servers share one scope and synchronise lease information so they don't hand out the same address twice. Modes are load-balance (both active, splitting the load) or hot-standby (one active, the other takes over on failure). Microsoft Windows Server DHCP implements this natively.
• On Linux, the modern choice is ISC Kea with its High-Availability hook (load-balancing or hot-standby pairs). Note the legacy ISC DHCP Server (dhcpd) reached end-of-life and is no longer maintained, so new builds should use Kea rather than the old failover-pair config.

Always pair the design with redundant relay (helper) addresses pointing at both servers.

DDNS (Dynamic DNS) closes the loop: when DHCP assigns an IP, it (or the client) automatically registers or updates the DNS records — the A record (name to IP) and the PTR record (IP to name, reverse lookup). So a laptop that just got a fresh DHCP address becomes resolvable by hostname without anyone editing DNS by hand.

Interview tip: Name a concrete model (split-scope 80/20, or failover in load-balance mode) and mention DDNS updating both the A and PTR records.

ARP (Address Resolution Protocol) answers one question: "I have the IP address — now what is the MAC address?" It maps a Layer-3 IPv4 address to a Layer-2 MAC address so a frame can actually be delivered on the local link.

Think of it like knowing someone's name (IP) but needing their seat number in the room (MAC) to hand them a note. Hosts and switches deliver frames by MAC, not by IP — so before any host can send a packet over Ethernet or Wi-Fi, it must resolve the destination's MAC.

The sender broadcasts: Who has 192.168.1.1? Tell 192.168.1.5. The owner replies with its MAC, and the result is stored in the ARP cache to avoid asking again.

One nuance: ARP is its own protocol that rides directly inside an Ethernet frame (EtherType 0x0806) — it is not carried inside an IP packet.

Interview tip: Always say "IPv4 (L3) to MAC (L2)" — and note that IPv6 has no ARP; it uses NDP instead.

The ARP request is a broadcast. The sender doesn't know who owns the target IP, so it shouts to everyone on the segment using destination MAC ff:ff:ff:ff:ff:ff. Every host in the broadcast domain receives and inspects it.

The ARP reply is unicast. Only the host that actually owns the requested IP answers, sending the reply directly back to the requester's MAC (which it learned from the request). Everyone else silently discards the request.

It's like calling out "Whose phone is ringing?" to a whole room (broadcast), and only the owner walking over to answer you privately (unicast).

A useful side effect: because the request already carries the sender's IP and MAC, other listening hosts can learn the sender's mapping for free, even though they don't reply.

Interview tip: Remember the asymmetry — "request = broadcast, reply = unicast." It's a one-liner candidates often miss.

The ARP cache is a short-lived table mapping recently-resolved IPs to MACs (view it with arp -a or, on Linux, ip neigh). It saves the host from broadcasting a fresh request for every single packet — entries typically expire after a few minutes so stale mappings get refreshed.

ARP works only within one broadcast domain because it relies on Layer-2 broadcasts, and routers do not forward broadcasts between subnets. An ARP request physically cannot reach a host on another network — it dies at the router boundary.

So to reach a remote host you don't ARP for the remote IP at all; you ARP for your default gateway's MAC and hand the frame to the router, which repeats the process on the next hop.

Analogy: shouting across one room works, but it won't carry to a different building — there you hand your letter to the front desk (gateway) instead.

Interview tip: "Routers don't forward broadcasts" is the core reason ARP is link-local.

A Gratuitous ARP (GARP) is an ARP message a host sends about its own IP without anyone asking — typically a broadcast where the sender IP and the target IP are the same. Nobody is expected to reply; the goal is to announce or verify.

Three classic uses:

• Duplicate IP detection: on boot, a host GARPs for its own IP — if someone replies, there's an address conflict.
• Cache update / takeover: after a NIC swap or a failover (for example, an HA pair or VRRP virtual IP moving to a new device), the GARP tells everyone "this IP now lives at my MAC," so traffic redirects almost instantly.
• Switch MAC-table priming: it refreshes switch forwarding tables so frames hit the right port without waiting for the old entry to age out.

Analogy: announcing "I've moved to this new desk" so mail reroutes immediately, instead of waiting for people to ask.

Interview tip: Tie GARP to HA failover — that's the use interviewers love. Also note attackers abuse GARP for ARP spoofing, since hosts trust an unsolicited reply.

Proxy ARP is when a router answers an ARP request on behalf of a host that lives on a different subnet, supplying its own MAC. The asking host then sends frames to the router, which forwards them onward — even though the host wrongly believes the destination is on its own segment.

It was designed for hosts with broken or missing subnet masks (or no default gateway) that ARP for remote IPs as if they were local. The router "covers" for the missing routing logic.

Why it's usually undesirable today:

• It hides real topology — hosts can't tell local from remote, which complicates troubleshooting.
• It bloats ARP caches — many remote IPs all map to the router's one MAC.
• It is a security risk — it normalizes one device answering for others, blurring the line with ARP spoofing.
• Modern hosts have correct masks and gateways, so it is simply unnecessary.

It does still appear in a few legitimate niches — for example, some VPN and wireless designs use it to bridge clients into a subnet — but as a general LAN setting it's left disabled.

Interview tip: Frame it as a legacy crutch — "a correct subnet mask plus a default gateway makes Proxy ARP obsolete."

The host first compares the destination IP against its own subnet mask. Since an internet server is on a different network, the host knows it must use its default gateway. So ARP resolves the gateway's MAC, not the server's — the remote server's MAC is irrelevant and unreachable via ARP.

The sequence:

1. DNS resolves the server's name to an IP (this lookup itself may first require ARPing the gateway, since the DNS server is usually off-subnet too).
2. The host sees the server IP is off-subnet, so it picks the default gateway.
3. If the gateway's MAC isn't cached, the host ARPs: Who has 192.168.1.1? (the gateway).
4. The frame goes out with destination MAC = gateway, but destination IP = the server.

At each hop the L2 MAC is rewritten to the next router, while the L3 source and destination IPs stay the same end-to-end. Analogy: the IP is the final mailing address; the MAC is just "hand it to the next post office."

Interview tip: Nail the split — "the MAC changes every hop, the IP stays constant."

All three resolve addresses, but in different directions and contexts:

• RARP (Reverse ARP): a host knows its own MAC but needs an IP — "this is my MAC, what's my IP?" Used by diskless workstations at boot. It was crude (it returned only an IP, worked in a single broadcast domain, and needed a RARP server with a manual MAC-to-IP table). It was replaced by BOOTP, then DHCP, which also hand out gateway, DNS, subnet mask, and more.
• Inverse ARP (InARP): used in NBMA WAN technologies such as Frame Relay and ATM. There you already know the local Layer-2 circuit identifier (the DLCI in Frame Relay, or the VPI/VCI in ATM) but need the remote IP reachable over it — the reverse of normal ARP. It auto-built the IP-to-circuit map across PVCs so admins didn't map each one by hand.
• Modern alternatives: DHCP for host IP assignment; for IPv6, NDP replaces ARP entirely; and Frame Relay and ATM themselves are legacy, displaced by MPLS, Ethernet, and IP-based WANs, so InARP is rarely seen outside old gear or exam questions.

Interview tip: One-liner — "RARP gave way to DHCP for host IPs; InARP was a Frame Relay / ATM thing; ARP becomes NDP in IPv6."

IPv6 drops ARP entirely. NDP (Neighbor Discovery Protocol) does the same jobs using ICMPv6 messages, and instead of broadcasts it uses efficient multicast (solicited-node multicast addresses), so only the relevant host is interrupted rather than the whole segment.

The four key messages and their IPv4 analogues:

• NS (Neighbor Solicitation): "What's the MAC for this IPv6 address?" — the equivalent of the ARP request.
• NA (Neighbor Advertisement): the reply carrying the link-layer address — the ARP reply (an unsolicited NA behaves like a Gratuitous ARP).
• RS (Router Solicitation): a host asking "are there any routers?" to speed up gateway discovery.
• RA (Router Advertisement): routers announcing themselves, the on-link prefixes, and config flags — roughly default-gateway plus subnet discovery, with no direct IPv4 equivalent.

DAD (Duplicate Address Detection): before using an address, a host sends an NS for that very address; any NA in response means it's already taken. This is the IPv6 counterpart of Gratuitous ARP duplicate detection.

Interview tip: Memorize "NS = request, NA = reply, RS/RA = router discovery, DAD = duplicate check — all over ICMPv6 multicast."

Both give a host an IPv6 address, but they differ in who is in control:

• SLAAC (Stateless Address Autoconfiguration): the host builds its own address from the prefix in the Router Advertisement plus a self-generated interface ID (either EUI-64 from the MAC, or a privacy-random value, which is now the default on most OSes). No server tracks who has what — it's stateless, zero-config, and scales effortlessly. DNS is still pushed statelessly via the RDNSS/DNSSL options in the RA (standardized in RFC 8106 and supported by modern Windows, macOS, Linux, iOS, and Android), so SLAAC no longer needs DHCPv6 just for DNS.
• Stateful DHCPv6: a server hands out and tracks each address, much like IPv4 DHCP. Choose it when you need auditing, fixed/reserved assignments, or centralized control (enterprise, compliance, IPAM). The RA's M-flag (managed) tells hosts to use DHCPv6.

Rule of thumb: SLAAC for simple, large, or home networks; stateful DHCPv6 where you must know exactly which device holds which address. The two can also be combined (SLAAC for the address, stateless DHCPv6 only for extra options).

DAD guards both: before activating any address, the host sends a Neighbor Solicitation for it; if a Neighbor Advertisement comes back, the address is already in use and won't be assigned.

Interview tip: "SLAAC = stateless / self-config; DHCPv6 = stateful / tracked; DAD always runs first."

DNS cache poisoning (spoofing) is an attack where a malicious actor tricks a resolver into caching a forged DNS answer. The resolver then hands that fake record to every user, silently redirecting them — e.g. typing your real bank's name but landing on the attacker's clone to steal credentials.

Classically (the Kaminsky attack) the attacker floods the resolver with spoofed replies, racing the real one, guessing the query's 16-bit transaction ID before the legitimate answer arrives.

Like someone slipping a wrong address into the post office's directory — every letter now goes to the wrong house.

The standard mitigations: source-port and transaction-ID randomization (makes guessing impractical), and for real cryptographic protection, DNSSEC, which signs records so forged answers fail validation. Encrypted transports (DoH/DoT) also help by hiding and integrity-protecting the query in transit.

👉 Interview tip: Name-drop the Kaminsky attack and say DNSSEC is the only cryptographic fix.

ARP (Address Resolution Protocol) maps IPv4 addresses to MAC addresses on a local network. The catch: ARP is stateless and unauthenticated — a host blindly trusts any ARP reply it receives, even one it never asked for (a gratuitous reply).

In ARP spoofing (poisoning), an attacker on the same LAN sends forged ARP replies, e.g. "the gateway's IP belongs to my MAC." Victims update their ARP cache and start sending the attacker traffic meant for the router.

This primarily enables a Man-in-the-Middle (MitM) attack: the attacker silently relays traffic while sniffing credentials, hijacking sessions, or tampering with data. It can also be used for denial of service (blackholing traffic).

It's like a stranger telling the whole office "I'm the new mailroom" — and everyone hands their mail to them.

👉 Interview tip: Mention Dynamic ARP Inspection (DAI) as the switch-level defense. (Note: IPv6 uses NDP instead of ARP, with its own spoofing defenses like RA Guard.)

Two related LAN attacks abuse DHCP's open trust model:

• DHCP starvation — the attacker floods the real DHCP server with thousands of DISCOVER requests using spoofed MACs, exhausting the IP pool so legitimate clients can't get an address (a DoS).
• Rogue DHCP server — the attacker stands up their own DHCP server handing out a malicious default gateway/DNS, becoming a Man-in-the-Middle for victims who lease from it.

DHCP snooping defends by classifying switch ports: only trusted ports (toward the legit DHCP server/uplink) may send DHCP server messages such as OFFER and ACK; on untrusted ports (client ports) those server messages are dropped — killing rogue servers. It also builds a binding table (MAC, IP, port, VLAN, lease) and rate-limits DHCP, blunting starvation.

👉 Interview tip: The binding table is the keystone — DAI and IP Source Guard both rely on it.

These three switch features form a layered Layer-2 defense, all anchored on the DHCP snooping binding table (the trusted record of MAC, IP, port, VLAN, and lease built from observed legitimate DHCP leases):

• DHCP Snooping — stops rogue DHCP servers and starvation; crucially, it builds the binding table that the other two consume.
• Dynamic ARP Inspection (DAI) — intercepts ARP packets on untrusted ports and drops any whose IP-to-MAC pairing doesn't match the binding table, stopping ARP spoofing / MitM.
• IP Source Guard (IPSG) — filters traffic per port, allowing only source IP (or IP+MAC) values present in the binding table, stopping IP/MAC spoofing.

Snooping is the foundation; DAI guards ARP, IPSG guards the data plane — both are blind without the table. (For statically addressed hosts, you add manual ARP ACLs / static IPSG bindings since they never DHCP.)

👉 Interview tip: Lead with "DHCP snooping is the foundation; DAI and IPSG are useless without its binding table."

DNSSEC adds cryptographic signatures to DNS so resolvers can verify a record's authenticity and integrity — defeating cache poisoning and spoofing. It does NOT provide confidentiality: DNSSEC data still travels in plaintext (that's the job of DoH/DoT/DoQ).

The key records:

• RRSIG — the digital signature over a record set (RRset).
• DNSKEY — the zone's public keys used to verify RRSIGs.
• DS (Delegation Signer) — a hash of the child's key, published in the parent zone.

The chain of trust runs from the root down: each parent's DS vouches for the child's DNSKEY, all the way up to a trusted root key (the trust anchor).

The KSK/ZSK split: the Key Signing Key signs only the DNSKEY set (it's the key referenced by the parent's DS, rarely rotated); the Zone Signing Key signs the actual records (rotated often). This lets you re-key zone data without re-engaging the parent. (Modern signers can also use a combined single-key CSK setup.)

👉 Interview tip: "DNSSEC = integrity/authenticity, not privacy."

All three encrypt DNS in transit for confidentiality and tamper-resistance, differing in transport:

• DoT (DNS over TLS) — DNS inside TLS on a dedicated TCP port 853. Easy for networks to identify and manage (or block).
• DoH (DNS over HTTPS) — DNS inside HTTPS on port 443, blending in with normal web traffic so it's hard to single out or block. Default in many browsers.
• DoQ (DNS over QUIC, RFC 9250) — DNS over QUIC (UDP-based, also port 853), giving TLS-grade encryption with lower latency and no head-of-line blocking. It also underpins DNS-over-HTTP/3.

DNSSEC and encrypted DNS are complementary because they solve different problems: DNSSEC = authenticity/integrity (is this the real answer, signed end-to-end by the zone owner?), while DoH/DoT/DoQ = confidentiality (can an eavesdropper read or modify it on the wire?). DNSSEC validates the data regardless of transport; encrypted transports only protect the client-to-resolver hop. One proves the data; the other hides it.

👉 Interview tip: "DNSSEC signs, encrypted DNS hides — use both."

The challenge: DoH on port 443 hides DNS inside normal HTTPS, so traditional port-53 monitoring and DNS-based filtering go blind — endpoints can bypass corporate resolvers entirely.

Enterprise strategies:

• Run your own DoH/DoT resolver and force clients to use it via policy/MDM, so you keep visibility while still encrypting.
• Disable browser/OS "auto-upgrade" DoH — Firefox honors a canary domain (use-application-dns.net) and enterprise policies; Chrome/Windows respect managed policies (GPO/MDM).
• Block external DoH endpoints at the firewall (known DoH IP/domain/SNI lists) so clients fall back to the trusted resolver.
• Move enforcement to the endpoint agent (EDR/SASE), which sees queries pre-encryption.

The trade-off is privacy vs. control: encryption protects users from ISP/on-path snooping, but enterprises need centralized resolution for malware/C2 blocking and compliance.

👉 Interview tip: Mention the Firefox canary domain and SASE/EDR enforcement — that signals real-world depth.

DNS tunneling abuses DNS as a covert channel. Because DNS is almost always allowed outbound (even on locked-down networks), attackers encode data inside DNS queries and responses. Stolen data is base32/hex-encoded into subdomain labels (data-chunk.evil.com) sent to an attacker-controlled authoritative server; commands come back in TXT/CNAME/NULL answers — giving both exfiltration and C2.

SOC detection signals:

• High-entropy / random-looking subdomains — encoded data looks like gibberish, unlike real hostnames.
• Abnormal record-type mix — unusually high TXT / NULL volume to one domain.
• Long / oversized queries and unusually long FQDN labels.
• High query frequency / volume to a single rarely-seen domain, and large total bytes.

It's like smuggling a letter one syllable at a time through innocent-looking phone calls.

👉 Interview tip: Name tools like iodine / dnscat2 and cite "entropy + volume to a single domain" as the top detection combo.

DNS amplification is a reflection DDoS that exploits two facts: DNS runs over spoofable UDP, and a tiny query can trigger a much larger response.

The attacker sends small queries to open recursive resolvers (or misconfigured authoritative servers) with the source IP spoofed to the victim's address (often using ANY queries or large DNSSEC-signed zones). Each server dutifully sends a large reply to the victim. With amplification factors that can reach 50x and beyond, a modest botnet drowns the target in traffic.

It's effective because of reflection (hides the attacker, uses innocent servers) and amplification (small input, massive output).

Resolver-side mitigations:

• Don't run open resolvers — restrict recursion to known clients.
• Response Rate Limiting (RRL) — cap identical replies per source.
• BCP 38 / source-address ingress filtering at networks to block spoofed source IPs (the root cause of reflection).
• Disable or minimize ANY responses; deploy anycast to absorb load.

👉 Interview tip: Say "close open resolvers + RRL + BCP 38" as the trio.

If the IP pings fine but the name does not, the network path and the server are healthy — the problem is name resolution (DNS). The packets can travel; the phone book is broken.

What to check, fastest first:

• Can you resolve at all? Run nslookup servername or dig servername. If it returns no IP or an error, DNS is the issue.
• Is a DNS server configured and reachable? Check ipconfig /all (Windows) or resolvectl status (Linux) for the assigned resolver, then ping that resolver's IP.
• Right record / right resolver? The name may be missing from DNS, or the client may be pointed at a resolver that does not know internal names.
• hosts file — a wrong or missing entry can override DNS.

Interview tip: State the conclusion crisply — "IP works, name fails = DNS" — then prove it with nslookup.

A 169.254.x.x address is an APIPA (Automatic Private IP Addressing) / link-local address. The machine assigns it to itself when it is set to use DHCP but got no reply from any DHCP server. It is the device saying "nobody gave me an address, so I picked one myself."

The practical meaning: DHCP failed. With a 169.254 address the host can only talk to other link-local hosts on the same segment — no gateway, no internet, and usually no working DNS.

Common root causes:

• DHCP server down, out of leases, or its scope is exhausted.
• Broken physical or Wi-Fi link, or a bad switch port — the DHCP DISCOVER never leaves the host.
• Missing DHCP relay (ip helper-address) when the client is on a different subnet from the server.
• VLAN mismatch or a blocked/misconfigured port.

Interview tip: First action — ipconfig /renew; if it still self-assigns, the DHCP path is the problem, not the client.

On Windows, open an elevated Command Prompt (Run as administrator) and use these:

Flush the DNS cache (clears stale name-to-IP entries held by the DNS Client service):

• ipconfig /flushdns — clears the cache.
• ipconfig /displaydns — shows what is currently cached (handy to confirm).

Renew the DHCP lease (release the current address and request a fresh one):

• ipconfig /release — drops the current lease.
• ipconfig /renew — requests a new lease from the DHCP server.

A common combined cleanup is ipconfig /release, then ipconfig /renew, then ipconfig /flushdns.

For reference, the Linux equivalents on systemd-resolved distros are resolvectl flush-caches for DNS, and dhclient -r then dhclient (or nmcli con down/up under NetworkManager) for the lease.

Interview tip: Mention these need an elevated prompt — a common gotcha.

dig splits a response into three record sections:

• ANSWER — the records that directly answer your question (e.g. the A record for the name you asked). This is the payload you usually care about.
• AUTHORITY — the authoritative nameservers (NS records) for the zone, telling you who is authoritative. On a referral or an NXDOMAIN this section also carries the SOA.
• ADDITIONAL — helper records, often the A/AAAA glue for the nameservers listed in AUTHORITY, plus the EDNS OPT pseudo-record (advertised buffer size).

The flags in the ;; flags: line:

• aa = Authoritative Answer — the response came from a server authoritative for that zone, not from a cache.
• ra = Recursion Available — the responding server is willing to recurse for you.

So if you query a recursive resolver you typically see ra set and aa unset; query the authoritative server directly and you see aa set.

Interview tip: No aa flag means the answer came from cache, not the authoritative source.

Intermittent drops on two hosts that share an IP is a classic address conflict — two devices answering ARP for one IP, so the switch keeps flapping which MAC owns it.

Confirm the duplicate:

• Watch for the OS conflict event (Windows logs an "address conflict"; the gateway's ARP table shows the IP bouncing between two MACs).
• Run arping -D 192.168.1.50 (duplicate-address detection), or ping the IP and then read the ARP table — you will see the MAC alternating.

Trace it:

• Note both MAC addresses; the OUI prefix often identifies the vendor (though MAC randomization can mask this on modern clients).
• Find each MAC on the switch with show mac address-table to locate the physical port, then walk to the device.
• Decide the cause: if one device has a static IP inside the DHCP scope, it is a static collision — exclude that IP from the scope or re-IP the device. If a device got a lease from an unexpected server, hunt the rogue DHCP server (capture the DHCP OFFER and check its source, or enable DHCP snooping).

Interview tip: The ARP table flapping between two MACs is your smoking gun.

The pattern — slow first hit, fast repeats, then slow again later — is the signature of a cache miss followed by cache hits, expiring on the TTL.

What is happening: on the first request the resolver has no cached record, so it walks root to TLD to authoritative (tens to hundreds of milliseconds). It caches the answer, so subsequent hits resolve instantly. When the TTL expires, the next request is a cache miss again — slow — and the cycle repeats. A very low TTL makes this happen often.

How to prove it:

• Run dig name twice in quick succession — note the Query time drops sharply on the second call and the TTL counts down between calls.
• Isolate DNS time with dig +stats versus the rest of the connection; if DNS dominates the first-hit delay, it is DNS, not the server.
• Check the record's TTL — if it lines up with the slow-fast period, that is confirmation.
• Rule out the server: a warm vs cold application cache, or TLS session resumption, can mimic this, so isolate DNS time specifically.

Interview tip: The countdown TTL in dig between two queries is the cleanest proof.

Inconsistent resolution for the same internal name means clients are taking different resolution paths. Isolate top-down:

• Stub resolver / client config — compare ipconfig /all or resolvectl status on a working vs a broken host. Different assigned DNS servers, a stale hosts entry, or a different DNS suffix search-list is the most common split. Also check whether some clients use encrypted DNS (DoH/DoT) that bypasses the internal resolver entirely.
• Recursive resolver — query each resolver directly: dig @resolverA name vs dig @resolverB name. If one returns the record and the other does not, the resolvers are not equivalent.
• Conditional forwarders — the failing resolver may lack the conditional forwarder for the internal zone (so it attempts public recursion and gets NXDOMAIN), while the working one forwards correctly to the internal authoritative server.
• Split-horizon views — check whether clients land in different views by source IP/VLAN; a host in the "external" view will not see the internal record. Verify the view's match criteria.

Interview tip: Always test dig @each-resolver directly — it instantly localizes which resolver is wrong.

End-to-end for https://www.example.com:

1. DNS resolution — the browser checks its cache, then the OS stub resolver. On a miss, the recursive resolver walks root to TLD to authoritative and returns the A/AAAA record, cached per its TTL.
2. Routing decision — the OS compares the destination IP against its routing table. It is not on the local subnet, so the packet must go to the default gateway.
3. ARP for the gateway — to build the Ethernet frame, the host needs the gateway's MAC. It checks its ARP cache; on a miss it broadcasts an ARP request ("who has 192.168.1.1?"). The gateway replies with its MAC, which gets cached.
4. First packet out — the host frames a TCP SYN to the server IP on port 443, with the destination MAC = the gateway's (the layer-2 next hop) but the destination IP = the server (the layer-3 end-to-end target). It hits the wire.
5. Beyond — the TCP handshake, then the TLS handshake (SNI carries the hostname), then the HTTPS request; the response renders.

Key insight: DNS gives the destination IP; ARP gives the next-hop MAC — different layers, both needed before the first byte leaves.

Interview tip: Stress that on that first frame the destination IP is the server but the destination MAC is the gateway.

Two modern defaults are the culprits. MAC randomization (per-SSID or rotating private MACs on iOS, Android, and Windows) means a device shows a new MAC, so your DHCP reservations keyed on MAC stop matching — the device gets a random pool address instead of its reserved one. Encrypted DNS (DoH/DoT, on by default in modern browsers and OSes) sends queries to a public resolver such as Cloudflare or Google, bypassing your internal resolver, so internal names return NXDOMAIN.

Diagnose: compare a device's expected reservation MAC against its current MAC in the switch and DHCP logs; capture traffic to confirm DNS leaving on port 443 (DoH) or 853 (DoT) to public resolvers instead of the internal one.

Remediate fleet-wide:

• Push MDM or Group Policy to set the Wi-Fi adapter to use a fixed (non-private) MAC on corporate SSIDs, or move reservations to identity-based binding (802.1X or DHCP client-identifier) instead of MAC.
• Disable or redirect encrypted DNS via policy (browser enterprise policy, Windows NRPT). For Firefox specifically, publish the canary domain use-application-dns.net returning NXDOMAIN so it auto-disables DoH; otherwise force clients to the internal resolver and block outbound DoH/DoT at the firewall.
• Use DHCP option 81 / dynamic DNS together with conditional forwarders so internal names resolve regardless of which device requested them.

Interview tip: Naming the Firefox canary domain and 802.1X identity-based reservations signals senior-level depth.