This is where you finish
In this chapter you work through 8 case-based questions, and afterwards you can see a unified view of how you did on all 42 questions in the course. Any question you have not yet answered correctly shows up with a link, so you can jump back to its chapter for one quick round of review.
Target for passing:
If you get at least 6 of the 8 case questions right and at least 34 out of 42 overall, you are in good shape for the first-pass triage you will do in real operations.
If you get at least 6 of the 8 case questions right and at least 34 out of 42 overall, you are in good shape for the first-pass triage you will do in real operations.
Check your understanding
0 / 8 correct. Correctness is stored only in this browser's localStorage.
Comprehensive review 7-1 — Think across delegation, TTL, and MX
These questions do not sit inside a single chapter — they ask you to combine several.
Chapter 7 / Practice 1
Q35. shop.example.com has been delegated to a separate zone. When you query the parent's authoritative server for api.shop.example.com A, what is the most likely way it responds?
Show hint
Past the delegation point, the parent is no longer responsible.
Data under the delegated child zone is not inside the parent's authority, so the parent typically returns a referral pointing to the child zone's NS records.
Chapter 7 / Practice 2
Q36. At 09:55 a resolver fetched the old A record with TTL 600 seconds, and on the authoritative side it was switched to the new A at 10:00. Starting from 10:00, what is the maximum number of minutes the resolver may still serve the old value?
minutes
Show hint
Expiry is at 10:05.
09:55 + 600 seconds = 10:05 is the expiry time, so seen from 10:00 the old value may remain for at most 5 minutes.
Chapter 7 / Practice 3
Q37. After obtaining example.com MX 10 mail.example.net, what should you look up next in order to learn the delivery target's IP?
Show hint
The value of an MX is a hostname.
MX returns the delivery-target hostname, so the next step is to query the A / AAAA of mail.example.net to obtain its IP.
Chapter 7 / Practice 4
Q38. dig www.example.com A returned status: NOERROR, no ANSWER, and an SOA in AUTHORITY. In addition, www.example.com only has an AAAA record. Which interpretation is closest?
Show hint
Pay attention to the fact that it is NOERROR.
When the name itself exists and only data of a different type is present, the typical response is NOERROR with no ANSWER of the requested type — a NODATA-like reply.
Comprehensive review 7-2 — Wrap up cache, DNSSEC, and troubleshooting
The final stretch also covers "where to start investigating."
Chapter 7 / Practice 5
Q39. 50 identical queries share a single resolver, and all of them happen within a single TTL window. The cache starts empty. How many queries reach the authoritative server for this RRset?
queries
Show hint
Within the same resolver, the first result can be reused for the rest.
Once the same resolver has retrieved the RRset on the first query, the remainder become cache hits while the TTL is still valid. Only 1 query reaches the authoritative server.
Chapter 7 / Practice 6
Q40. When thinking about the DNSSEC validation chain, select all of the elements that are directly involved.
Show hint
The signature itself, the validation key, and the parent-to-child link that ties them together.
DS is the parent-to-child link, DNSKEY is the public key, and RRSIG is the signature. MX is the mail delivery target and is not an element of the validation chain itself.
Chapter 7 / Practice 7
Q41. Which is closest to the reason it is hard to put a plain CNAME at a zone apex?
Show hint
Recall which records are required as the starting point of a zone.
A zone apex requires that zone's SOA and NS. The basic rule is that a CNAME cannot coexist with other data on the same owner name, which is why a plain CNAME collides with the apex.
Chapter 7 / Practice 8
Q42. When "I thought I changed the record, but the old IP is still showing up," what is the best first step for triage?
Show hint
Do not look at the UI — observe "who is actually returning what right now."
The fastest path is to first observe the actual DNS responses and separate out which authoritative server is in charge, whether a TTL has not yet expired, and whether the delegation chain takes a wrong turn somewhere. Note: smashing the browser refresh button is useless because, until the cached RRset on the recursive resolver or the OS expires, every HTTP request will keep getting the same cached DNS response. Repeated refreshes do not shorten the DNS-layer TTL, so the "old IP keeps showing up" situation does not resolve on its own.
Things that help the material stick
- Run
dig NS,dig SOA, anddig +traceagainst your own managed domain, and watch the delegation path with your own eyes. - Create a test record whose TTL you can change, and practice the "lower the TTL before the change, restore it after" routine.
- If you have a mail domain, trace MX → A / AAAA of the delivery host on paper step by step.