Question bank — DNS — recursive vs iterative query, hierarchy, record types (A, AAAA, CNAME, MX, NS)

True in principle but they play different roles: the recursive resolver chases referrals for clients, the authoritative server stores a zone's records. Mixing them is discouraged because a recursive-open authoritative server can be abused for cache-poisoning and amplification attacks.

False. There are 13 root server identities (letters a–m, limited by old UDP packet-size constraints), but each is replicated to hundreds of physical instances worldwide via anycast — see Anycast Routing. So there are far more than 13 boxes.

False. The TLD server only knows the NS records — which authoritative server handles example.com. The actual A record lives on that authoritative server, not the TLD.

False. Per RFC (the DNS/email rulebooks), if no MX record exists a sender falls back to the domain's A/AAAA record (the "implicit MX"). Delivery is still attempted to the host itself — see SMTP and Email Delivery.

True and common. A supplies the IPv4 address, AAAA supplies the IPv6 address (see IP Addressing — IPv4 vs IPv6); a dual-stack host publishes both and the client picks by its own connectivity.

False. A CNAME points to another name (a canonical hostname), never to an IP. The resolver must then look up that name to eventually reach an A/AAAA record.

False — it makes changes propagate faster but resolution slower on average, because caches expire sooner so more queries miss and must walk the hierarchy again. TTL trades freshness against cache efficiency (see Caching and TTL).

False in the networking sense. A recursive query means the asked server accepts full responsibility for producing the final answer, doing whatever legwork is needed — it's about who owns the work, not about code recursion.

Error: the laptop's stub resolver sends one recursive query to its configured resolver and waits. The iterative walk across root→TLD→authoritative is done by the recursive resolver, not your laptop.

Error: a CNAME must point to a name, not an IP. This should be ftp.example.com. IN CNAME www.example.com. (which then resolves to the A record), or an A record directly if you want an IP.

Error: a CNAME cannot sit at the zone apex because it may not coexist with other records, and the apex already carries mandatory SOA and NS records. Use A/AAAA (or a provider's ALIAS/ANAME) instead.

Error: lower number = higher preference (tried first). Here the 5 backup record would be tried before the 50 primary record, which is the opposite of the intent. Swap the numbers.

Error: root servers only know TLD delegations. Registering example.com updates the .com TLD's zone, not the root — the root already knows where .com lives and never changes for a new site.

Partly wrong: TTL 0 means resolvers should not cache, but the change is only "instant" for resolvers that honour it — and it hammers your authoritative server with every query. Many resolvers also enforce a minimum TTL, so "everywhere instant" is not guaranteed.

Error: CNAME chains are legal (each hop points to another name until an A/AAAA is reached). They are discouraged for performance (extra lookups) but not forbidden — resolvers follow the chain.

If root servers answered recursively they would do the full lookup on behalf of every client on Earth and instantly melt. Iterative keeps them cheap: they only ever hand back a referral to the right TLD.

A single HOSTS.TXT couldn't be updated, downloaded, or owned fast enough for billions of hosts. Splitting the namespace into a delegated tree means no single machine knows everything — each level only knows the next, spreading load and authority.

Popular answers are stored near clients for their TTL, so most queries are served instantly without walking the hierarchy. A high cache-hit fraction turns a multi-hop lookup into near-zero work for the common case (see Caching and TTL).

It gives one canonical host that many aliases point to. Change the canonical host's IP once and every alias follows automatically — no need to edit each alias's A record.

The number is a preference rank / "distance", not an importance score. Senders try the most-preferred (lowest) first and only fall to higher numbers if it's unreachable, giving a deterministic failover order.

Because delegation flows from the most significant part (root) downward: root delegates to TLD, TLD to the domain's authoritative server. Right-to-left mirrors the actual resolution path down the tree.

Because it is the source of truth — it stores the zone's records rather than caching them. Its answers are marked "authoritative" and are trusted without needing a further lookup.

Because RFC 2181 (the DNS clarification standard) forbids it: mail and delegation logic must resolve the target directly to an address in one step, and a CNAME would introduce an extra indirection that many servers reject or mishandle.

The authoritative server returns an NXDOMAIN (non-existent domain) response. This negative answer is itself cacheable — the SOA record's timer sets how long — so repeated bad lookups don't keep hitting the authoritative server.

It treats the entry as absent and re-resolves from the hierarchy, then caches the fresh result. The old value is discarded — TTL is exactly the promise "trust me only this long."

They shouldn't — secondaries pull from the primary via zone transfers. If they diverge (misconfiguration or a failed transfer), a client may get inconsistent answers depending on which server it happened to ask; whichever replies is treated as authoritative.

It denotes the root — the name is a Fully Qualified Domain Name, absolute rather than relative. Without the dot, resolvers may append a search domain (e.g. turn www into www.mycorp.local).

DNS still returns the AAAA record — DNS doesn't know your connectivity. The client's connection logic (often Happy Eyeballs) tries IPv6, fails or times out, and falls back to the A record's IPv4. DNS did its job; reachability is a separate layer.

It's invalid per RFC 2181 — MX (and NS) targets must be real hostnames with A/AAAA records, not a CNAME. Many mail servers will reject or mishandle it, so always point MX at a name that resolves directly to an address.

You get a NODATA response: the name exists but that specific record type does not. It is distinct from NXDOMAIN (name doesn't exist at all) and is likewise cacheable as a negative answer.

Circular dependency: if example.com's NS is ns1.example.com, you can't find ns1.example.com's address without already knowing where example.com is served. Glue records are the ns1.example.com A record stored at the parent (.com) TLD alongside the NS delegation, breaking the loop so the resolver can actually reach the authoritative server.

When a zone's NS names live in a different zone (e.g. example.com delegated to ns1.provider.net). Then ns1.provider.net is resolved independently through .net, no circular dependency exists, and the parent supplies only the NS record — no glue.

It answers for any name that has no more specific record — e.g. foo.example.com and bar.example.com both resolve via the wildcard. But an explicitly defined name (like www.example.com) takes precedence, and the wildcard does not cover deeper labels like a.b.example.com unless they too fall through with no closer match.

Yes for the type it covers: because a matching name now "exists" via the wildcard, queries return data instead of NXDOMAIN. But a query for a type the wildcard doesn't provide (e.g. AAAA when only a wildcard A exists) yields NODATA, not the wildcard's A — wildcards match on name-fallthrough, not across record types.

Technically allowed and used for CDNs (see CDN and Load Balancing), but the usual CNAME rules still bite: the wildcard only matches names with no more-specific records, and it can't help at the apex or coexist with other data at the exact same wildcard name.