Computing desk
< September 10	<< Aug \| September \| Oct >>	September 12 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

September 11

Did I understood correctly how world wide web interactions generally happen?

I understand that any World Wide Web interaction happens generally this way:

Stage 1: Client (human or software) ⟶ User agent ⟶ HTTP/S web-server request (with an unresolved domain)
Stage 2: ISP-initiated Routing software ⟶ DNS server (one, or two or more until resolve) ⟶ DNS resolve
Stage 3: A web Server which is part of a server environment of a computer system with the "resolved" IP address processes the server request
Stage 4: HTTP/S web Server response (with a resolved domain) ⟶ Server-initiated routing software ⟶ Client (human or software)

Regarding stage 2, I understand that some ISP routing software will try to lookup/resolve/translate a given domain with a given IP address "somewhere in the internet" and because that IP address can be associated with one or more DNS servers, the routing software would have to go through generally all DNS servers in the world until it reaches one which successfully lookedup/resolved/translated the domain to an IP address and then the rest of the process will continue.

Did I understood correctly how world wide web interactions generally happen? 49.230.223.177 (talk) 11:26, 11 September 2020 (UTC)[reply]

It is not necessary to query every single DNS server in the world. Rather, if necessary you query a Root name server to work out the authoritative name servers for the top level domain of interest, say .nz. Then if necessary, you query a authoritative name server for the top level domain, say .nz, to find out the authoritative name servers for the second level domain, say co.nz. This process can be repeated until you find the authoritative name servers for the subdomain of interest. You can then do whatever query you need one of these name servers to find out the A or AAAA records or whatever is of interest. Caching of course means it's often "not necessary" especially for something like querying the root name servers. See [1] and [2] for further explanation. Nil Einne (talk) 15:44, 11 September 2020 (UTC)[reply]

You probably also want to read Domain Name System#Address resolution mechanism. Note that my answer was mostly intended to deal with how you can resolve the domain name rather than how it happens in practice. As that article suggests, I believe for normal home user client set-ups, the norm will be to first check your local cache for that specific domain, and then if that is a miss, to ask the router's DNS server, if that's has no cache for that specific domain (or if the user has overriden the DNS to bypass their router), to ask the ISP's or public recursive resolver which will most likely then take the necessary steps to resolve the specific domain. There is a slight chance the ISP's name servers will pass the query on to some other name server, but I don't think it goes very far even if it does and it's definitely not even close to checking every name server in the world. Nil Einne (talk) 16:06, 11 September 2020 (UTC)[reply]

One final comment, my first answer leaves an obvious question namely how do you know what IP to use when you're querying a root name server if starting afresh? I believe the answer is generally you start off with a hardcoded list of such servers, hope that one of these works and you then have authoritative root name servers. [3] Nil Einne (talk) 16:21, 11 September 2020 (UTC)[reply]

Yes, the chicken-and-egg problem means that if you're doing a "black start" of a DNS resolver, you need the IP address for at least one DNS root nameserver. DNS nameserver software usually includes a copy of the root zone file in the package. DNS clients just need the address of a DNS resolver to query; this is most typically provided to the operating system via DHCP as part of setting up a network connection. --47.146.63.87 (talk) 20:36, 11 September 2020 (UTC)[reply]

The DNS request doesn't have to be ISP-initiated. You can force your computer to use a specific DNS server irrelevant of your ISP. This is for example necessary for DoH/DoT. And of course the whole stage 2 is skipped if the domain is in your computer's DNS cache (here's one point where TTL matters, tho it's made irrelevant if the DNS server you or the ISP is using decides to set its own TTLs). 93.136.17.85 (talk) 17:46, 11 September 2020 (UTC)[reply]

Two distinct points:

You need to clarify in your mind the distinction between the WWW and the internet. The latter handles all of this, the former is just application software built on the internet.
It may be desirable to run your own DNS on a network, and only hand things over to the router if they are not local. This helps with routers that time out and forget addresses and which cannot easily be programmed.

Martin of Sheffield (talk) 18:27, 11 September 2020 (UTC)[reply]

Martin of Sheffield I did make the distinction. 49.230.223.177 (talk) 14:06, 12 September 2020 (UTC)[reply]

You kind of omitted a step between 2 and 3. Your client software—for instance, a Web browser—gets the DNS query result. Then that client software connects to whatever IP address it got from the query result. Then of course the server (presumably) accepts the connection and sends back to your client whatever the client requested. Another detail: Internet Protocol "routing software" is usually found on dedicated network routers rather than end-point servers. These use the Border Gateway Protocol to figure out how to route IP datagrams between different networks. On a local link segment, routing is done at the link layer, most often Ethernet. --47.146.63.87 (talk) 20:36, 11 September 2020 (UTC)[reply]

Hello; I think there is a mistake in your first sentence here - I don't think I omitted that part; if you still think I omitted that part, please try to rephrase the meaning; Nicely. 49.230.223.177 (talk) 21:00, 12 September 2020 (UTC)[reply]

First the Web browser makes a DNS query for example.com. Once that query is completed, then the browser opens an HTTP connection to example.com. I wasn't sure if you understood they're two independent things so I just wanted to point that out. --47.146.63.87 (talk) 07:27, 14 September 2020 (UTC)[reply]

Now your intention is clear to me; I didn't think about it this way; thank you. 49.230.219.227 (talk) 11:30, 14 September 2020 (UTC)[reply]

Although you said "generally" and I guess this is sort of implied by above comments by others, it's worth remembering in case there is some confusion, that a domain is not actually a required to run a website. Through it's not something many will do for various reasons, it is possible for some websites to be accessed simply by the IP, in which case there is no need for DNS. Note that because of the way most hosting works, along with CDNs etc, most website's can't actually be acccessed simply from the IP (the server will have no idea what site you're trying to access). Still since I have fibre with 500 mbit upload if I want to share large files with family I normally just run a simple webserver. While I do have a domain set-up, since my IPv4 IP is extremely sticky simply using that also works. Likewise when I want to access my router, I normally just use the IP. Nil Einne (talk) 14:13, 17 September 2020 (UTC)[reply]

For convenience a lot of people who do this use dynamic DNS. This gives you a domain name, and if you run a client somewhere on your LAN it can update the DNS entry when your IP address changes. Some ISPs even provide this to customers, either by default or by request. --47.146.63.87 (talk) 20:22, 18 September 2020 (UTC)[reply]

Oh also, for those not familiar with the concept, "CDN" refers to content delivery networks. To elaborate on what Nil Einne said, a single host with a single IP address can host tons of different websites with different domain names via virtual hosting. example.com and example.net can both resolve to the same IP address. You connect to that address on port 80 (the standard HTTP port), and send one of example.com or example.net in the Host header of your HTTP request. This lets the host know what site to give you. --47.146.63.87 (talk) 20:29, 18 September 2020 (UTC)[reply]