NS records chicken and egg: NS in the domain it's serving

I've dealt with BIND for years and this has always kind of bugged me.

$ dig google.com ns

;; QUESTION SECTION:
;google.com.            IN  NS

;; ANSWER SECTION:
google.com.     87046   IN  NS  ns3.google.com.
etc...

;; ADDITIONAL SECTION:

ns1.google.com.     87274   IN  A   216.239.32.10
etc.

I get that, at least notionally, the root servers handle ., and hand off .com., .gov., whatever to the right servers (though in practice this is all cached several levels down), but at some point, somebody has to know to ask the server at 216.239.32.10 for the A record of whatever.google.com. But how did resolvers figure that out in the first place, since you need to know the A of the NS to do that? (And for that matter, since we know it's an Internet NS and not, say, Chaos or something, why do you have to use a name rather than an address for the NS record?)

My nameservers have always had names that could be found by somebody upstream (eg, I hosted DNS for bar.com on foo.com, and my upstream handled foo.com), but I have never quite grasped how people like Google get over the chicken and egg problem of hosting the DNS for google.com under the name google.com.

Answer

I think the concept you're struggling with is glue records.

---

From that linked article above:

For example, if the authoritative name server for example.org is ns1.example.org, a computer trying to resolve www.example.org first resolves ns1.example.org. Since ns1 is contained in example.org, this requires resolving example.org first, which presents a circular dependency. To break the dependency, the name server for the top level domain org includes glue along with the delegation for example.org. The glue records are address records that provide IP addresses for ns1.example.org. The resolver uses one or more of these IP addresses to query one of the domain's authoritative servers, which allows it to complete the DNS query.