The answer is certainly operating system-specific in the sense that nothing is preventing a certain operating system from behaving differently. There is nothing necessary about DNS client querying of multiple servers that would prevent an operating system implementation from treating DNS queries differently than I'm describing here.
That said, the example of how Linux looks up DNS names should be representative of how most operating systems in common use today do it.
Here is a good post describing the behavior in detail, as well as a way to set up something like what you've asked for.
The general idea is that, by default, secondary/tertiary DNS servers are only used in sequence if the primary DNS server times out or points to a non-routable IP address. Even if the primary DNS server says "that domain does not resolve", it will not move on to ask the next nameserver. It treats any valid response to the query as a reason not to move to the next DNS server in the list.
One possible sane way of setting it up so that local addresses will resolve first, but still use Google DNS or OpenDNS instead of your ISP's DNS server, is to configure your router or LAN box (whichever box is the Internet gateway) to use 8.8.8.8 as its primary nameserver. Of course, the gateway box should itself be running a nameserver, and should be configured to answer DNS queries for local hostnames on the private subnet -- but if it fails to resolve against the local subnet, it should immediately punt to Google DNS. This is kind of the best of both worlds.
Another way to do it is to set up different nameservers for different network interfaces. Windows lets you do that by default; the article in the link above describes a way to do it by configuring the BIND9 DNS server implementation using the forward and forwarders directives.
Your computer has a list of DNS servers that it can query for further information. On a unix or linux system, this is stored in /etc/resolv.conf. In Windows, it's configurable in your network settings. Often, your DNS server will be supplied by your DHCP server, possibly along with other settings like default domain, proxy servers, etc.
The location of the DNS server you use doesn't matter much. As long as your computer has an IP address and a working default route (i.e. you can ping the DNS server), you should be able to make DNS queries.
DNS servers don't have to know "all" domains. They only need to know who is "authoritative", which it learns from a set of "root" servers. Each DNS server has a list of "root" servers, and this list changes infrequently. On one of my DNS servers, there are 18 root servers configured, and this configuration came when I installed the DNS server two years ago, and if the list of root servers has changed since then, enough of them are accessible that I haven't noticed it.
My DNS server, when asked to resolve a domain it doesn't know, makes a query to a root server to find out what other DNS server is authoritative for the domain. The response it gets may contain additional "NS" records and be marked non-authoritative, in which case my DNS server knows that it has to "follow the chain" and make a new query to a new server. Eventually, it finds a DNS server that provides authoritative information, and queries can be made that are not just NS records. A (address) and MX (mail exchange) are of course the two most common.
Each TLD (top-level domain) like COM, NET, ORG, CA, UK, etc maintains its own registry of subdomains. (A "subdomain" is any domain within another domain, so "example.com" is a subdomain within "com", and "com" is even a subdomain within ".", the "root".) The rules for each registry apply only to the TLD it administers -- that is, there's a completely different set of criteria for each country-code TLD, and the "generic" TLDs are administered by different organizations with different policies. But they all maintain DNS servers for their TLD, which, from a command line, you can see using basic DNS query tools:
[ghoti@pc ~]$ host -t ns ca.
ca name server c.ca-servers.ca.
ca name server e.ca-servers.ca.
ca name server z.ca-servers.ca.
ca name server a.ca-servers.ca.
ca name server f.ca-servers.ca.
ca name server sns-pb.isc.org.
ca name server j.ca-servers.ca.
ca name server k.ca-servers.ca.
ca name server tld.isc-sns.net.
ca name server l.ca-servers.ca.
[ghoti@pc ~]$ host -t ns info
info name server c0.info.afilias-nst.info.
info name server d0.info.afilias-nst.org.
info name server b2.info.afilias-nst.org.
info name server b0.info.afilias-nst.org.
info name server a2.info.afilias-nst.info.
info name server a0.info.afilias-nst.info.
[ghoti@pc ~]$
When you buy a domain from a registrar (of which there are many), that registrar submits information about the domain to the registry (of which there is just one per TLD). It is the responsibility of each registry to maintain the list of registered domains within their TLD, and maintain the DNS servers that provide this info to other servers.
Best Answer
Your situation is not unusual the slightest bit; every time a full-featured recursive resolver is started – such as BIND9 or Unbound, even the copy I've running on my laptop – it starts with just a list of root zone 'hints', and descends from there all by itself.
(You said "Imagine a world where Google Public DNS doesn't exist". Ever wonder how Google Public DNS itself resolves all domain names?)
But replies to DNS queries can have more than just a straight answer. Specifically, if a domain's authoritative name servers are in the same domain, then a copy of their addresses – aka, glue records – will be held by the parent domain as well.
So when you query the
com.name servers forwww.google.com, they don't just say that it's hosted byns1.google.com, but also give you the IP addresses ofns1.google.comin the same reply message!In fact, you should have already hit this earlier, with the
com.top-level domain. When you query the root name servers – they will tell you that all ofcom.is hosted bym.gtld-servers.net.and they will give you its IP address. You can see for yourself that the root zone file holds this information.For example:
Continuing with one of the
com.name servers:Continuing with one of the
google.com.name servers:We finally received an authoritative answer (
aa) for the same name we asked for.