For something so pervasive, DNS is just too hard at times. Even the author, who is clearly in the 99th percentile plus for DNS knowledge, slips up on the depth.
There's two small nits, besides the modern browser caching/pre-fetching, that are worth clearing up;
1. When receiving a delegation response, the NS records won't be in the answer section - they'll be in the authority section. NS records are never in the answer section unless the query was an NS query, or an ANY query. But neither query plays any role in ordinary DNS resolution. Resolvers always ask the same question when recursing - so if you're trying to resolve www.example.com, then with a cold cache a resolver will at some point make a query that is the equivalent of "dig www.example.com @h.gtld-servers.net" . There you'll see the NS records in the authority section, and the glue in the additional section.
2. There's one exception to the "NS queries don't form a part of regular DNS" which is root zone priming. When a resolver first starts it will try to find the current "live" root zone contents by querying each root server in the hints file (which might be out of date), with an NS query, until one responds. E.g. "dig NS . @a.root-servers.net" . That response is what forms the authoritative root zone in the cache, not the hints file. The hints file is just for one-time bootstrap. At least that's the intent.
Comments
For something so pervasive, DNS is just too hard at times. Even the author, who is clearly in the 99th percentile plus for DNS knowledge, slips up on the depth.
There's two small nits, besides the modern browser caching/pre-fetching, that are worth clearing up;
1. When receiving a delegation response, the NS records won't be in the answer section - they'll be in the authority section. NS records are never in the answer section unless the query was an NS query, or an ANY query. But neither query plays any role in ordinary DNS resolution. Resolvers always ask the same question when recursing - so if you're trying to resolve www.example.com, then with a cold cache a resolver will at some point make a query that is the equivalent of "dig www.example.com @h.gtld-servers.net" . There you'll see the NS records in the authority section, and the glue in the additional section.
2. There's one exception to the "NS queries don't form a part of regular DNS" which is root zone priming. When a resolver first starts it will try to find the current "live" root zone contents by querying each root server in the hints file (which might be out of date), with an NS query, until one responds. E.g. "dig NS . @a.root-servers.net" . That response is what forms the authoritative root zone in the cache, not the hints file. The hints file is just for one-time bootstrap. At least that's the intent.