Cache and bailiwick — What can you trust
Separate referral, glue, and bailiwick, and sort out what is safe to put in the cache.
Recap of the previous chapter: In Chapter 1, we confirmed the picture that a forged RRset in the cache of a shared recursive resolver causes the same bad answer to be served to every user. In this chapter, we organize referral / glue / bailiwick as the criteria for "what a resolver should be allowed to put in its cache."
A delegation returns "where to go next," not the "final answer"
A recursive resolver does not receive the final answer directly. The parent zone returns a referral pointing at the child zone's NS records, and the resolver uses that signpost to step to the next authoritative server.
| Section | Typical contents | How to think about it |
|---|---|---|
| ANSWER | Final RRset | Is this really the answer for the name and type you wanted? |
| AUTHORITY | NS / SOA | Is this a referral or a negative response? |
| ADDITIONAL | glue / auxiliary addresses | Is it a stepping stone for the next hop, or unrelated additional data? |
Practice 2-1 — Glue is a bridging stepping stone
When the Additional section has A / AAAA for an in-bailiwick NS name, the resolver can reach the child zone more easily.
Q1. The parent zone example.com delegates shop.example.com to ns1.shop.example.com, and the referral's Additional section includes ns1.shop.example.com A 192.0.2.53. Which description of this additional data is closest?
Think about whether it is a "stepping stone" for reaching the child zone.
This is in-bailiwick glue used as a stepping stone to the child zone. It helps to follow the delegation, but it should not be treated with the same strength as a general final answer.
Q2. In dig output, where do the NS records of a delegation mainly appear?
A referral shows "where to go next," not "the final answer."
Delegation NS records mainly appear in the AUTHORITY section of dig output. ANSWER holds the final RRset; ADDITIONAL holds glue or auxiliary addresses; QUESTION holds the queried name, type, and class. (dig output is structured as the five sections HEADER / QUESTION / ANSWER / AUTHORITY / ADDITIONAL.)
Three bailiwick scenarios
How to treat a record in the Additional section depends on whether that record falls inside (in-bailiwick) or outside (out-of-bailiwick) the delegation range of the referral.
The decisions here are for conceptual learning. Implementations differ in the fine print, but the viewpoint of keeping "a stepping stone for the delegation" and "unrelated additional data" separate is what matters.
Handle out-of-bailiwick additional data with care
If unrelated data can be slipped into the Additional section of a referral, that is dangerous. Resolver implementations therefore treat glue strictly — who to trust, and how far. The word that keeps coming up in this context is bailiwick.
Origin of "bailiwick": Originally a legal term in medieval English law meaning "the jurisdiction of a bailiff," with the connotation of "the range for which a particular party is responsible." Borrowed into DNS, it now refers to the idea of "whether a name lies inside the namespace that the delegating zone is responsible for." A record that appears in a referral's Additional section is called in-bailiwick if it sits inside that delegation range, and out-of-bailiwick if it sits outside.
Practice 2-2 — Handle out-of-bailiwick additional data with care
If unrelated data can be slipped into a referral's Additional section, that is dangerous. Bailiwick is the idea that limits which glue you trust, and how far.
Q3. A referral from example.com to ns.partner.net arrived with ns.partner.net A 198.51.100.10 in Additional. What is the most conservative way to handle it?
Check whether that additional A falls under example.com's authority.
Treating out-of-bailiwick additional data as unconditionally authoritative is unsafe. If needed, separately resolve the name itself — that is the safer side. The idea of bailiwick exists precisely to keep unrelated additional data from sneaking in.
Q4. What is the main purpose of the idea of bailiwick?
Think about "for which range of introductions do you tighten the acceptance rule?"
Bailiwick is the idea of suppressing acceptance of unrelated additional data that piggybacks on a referral. Using it, a resolver can put tight limits on how it treats glue.
Q5. Which statement about glue in Additional is correct?
Glue is convenient, but its role is "bridging."
Glue is auxiliary information for following a delegation. To "keep its handling limited" specifically means: (1) use only in-bailiwick glue as a stepping stone for the delegation, (2) do not trust out-of-bailiwick Additional data as authoritative — resolve it separately if needed, and (3) do not treat a record in Additional as the final answer for the name the user actually queried.
Key takeaways from this chapter
- Delegation NS records mainly appear in AUTHORITY, and stepping-stone glue appears in ADDITIONAL
- Do not trust in-bailiwick glue and out-of-bailiwick additional data with the same strength
- Bailiwick is the viewpoint that suppresses the mixing in of unrelated additional data