Conceptually as a user there is not much difference between the topmost TLD, a domain within the TLD, and a "subdomain" (really, a "host") within a domain. Nor any other level under it.
The DNS root is .
Under the DNS root are the TLDs; com, net, org, and a bazillion other.
Then under those are domains. More or less. Some countries use for example co.tld instead of tld, and some use both.
Anyways, aside from things like glue records etc that the domain and tld owners have to concern themselves with, my claim is that for a user it is more or less the same.
If I tell you that my website is http://www.example.com/ then in theory you could do the following to resolve it:
- You don't know the IP of www.example.com so you have to find the Name Server for it.
- You don't know the NS of example.com so you decide that you should query the NS of com for it.
- You don't know the NS of com so you decide that you should query the DNS root . for it
https://en.wikipedia.org/wiki/DNS_root_zone
https://root-servers.org/
So let's query a root server
dig @198.41.0.4 com. NS
Command output with response and some tool specific stuff:
; > DiG 9.10.6 > @198.41.0.4 com. NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER
Ok, and from that we can query one of the NS of com for example.com
dig @192.12.94.30 example.com NS
Output:
; > DiG 9.10.6 > @192.12.94.30 example.com NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER
And we can query the NS for example.com to find out the IP address of www.example.com
dig @a.iana-servers.net. www.example.com A
(You can see I skipped a couple of steps in the interest of brevity here, as I am suddenly querying an NS by its DNS name a.iana-servers.net. directly instead of via an IP address. But if you like you could imagine that we take the same steps to resolve a.iana-servers.net. from the DNS root up.)
And we get the following output:
; > DiG 9.10.6 > @a.iana-servers.net. www.example.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER
In reality most client devices will not resolve it from the root up. Instead, they will be told about local resolvers when they aquire DHCP lease on their local network, and they will ask those resolvers on the local network to resolve the domain, and they might do it either directly from cached values, or at least skipping a few steps because they already know which NS are in charge of which TLDs.
But what I am getting to is this:
We can ask the root servers for the NS for the TLD.
dig @198.41.0.4 ai. NS
which gives us
; > DiG 9.10.6 > @198.41.0.4 ai. NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER
And we can ask one of those for an IP address for the ai tld itself.
dig @204.61.216.123 ai. A
And in the case of the ai tld, the NS for the tld do indeed return an A record for the bare tld
; > DiG 9.10.6 > @204.61.216.123 ai. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER
And there you have it. That's how it works.