What Actually Happens When You Type a Website Address?
Hemel Private Tuition | Computing Beyond the Syllabus
Type a website address and press Enter. A moment later, there it is. Now try this question. If you already knew the website's IP address, could you type that instead and expect the same page?
Sometimes you can reach a server that way. Getting the same page securely is another matter. A single IP address can serve several websites, and the browser still needs to know which site it is asking for. That makes a familiar action a surprisingly good starting point for a computing practical.
In this investigation, we will ask DNS for an address, look at the browser's connection and follow the requests that turn a response into a web page. You can start with Windows and Chrome or Edge. A Linux terminal gives you a closer look at DNS.
1. Pick apart the address
Use https://example.com/?lesson=dns as our example.
| Part | What it tells the browser |
|---|---|
https | Use HTTP over a secure connection. |
example.com | This is the hostname. |
/ | Request the root path. |
lesson=dns | Send this query string with the HTTP request. |
HTTPS normally uses port 443 when the URL leaves the port implicit. For a DNS address lookup, give the tool the hostname alone, example.com. The scheme, path and query string have jobs elsewhere in the process.
2. Who knows where the website is?
The Domain Name System (DNS) is a distributed system of records. An A record gives an IPv4 address. An AAAA record gives an IPv6 address. A CNAME record makes one name an alias for another, while NS records identify nameservers for a DNS zone.
If the browser needs a fresh address, the lookup typically goes through a recursive resolver. Depending on the setup, that might be a service supplied by your network, your ISP or your browser's secure DNS provider. The resolver can answer from its cache. If it has to work down the hierarchy from the top, a simplified lookup goes like this.
- A root nameserver points the resolver towards nameservers for
.com. - A .com nameserver points it towards the authoritative nameservers for
example.com. - An authoritative nameserver answers for the domain. If the answer is an alias, the resolver may need to follow it.
- The resolver returns the result. It can reuse cached records for a period governed by their time to live (TTL), measured in seconds.
I like to pause here and ask students which server actually knew the answer and which servers knew where to ask next. Drawing those two roles separately makes the hierarchy much easier to explain. It also helps make sense of why a second visit may skip much of this work.
3. Ask DNS yourself
Windows with nslookup
Open Command Prompt or PowerShell and run:
nslookup -type=A example.com
nslookup -type=AAAA example.com
nslookup -type=NS example.comFor the first two commands, find the server shown at the top and the address or addresses in the answer below. The first identifies the DNS server you asked. The latter are addresses returned for the hostname. The NS lookup asks a different question about the same domain.
If you see Non-authoritative answer, your responding resolver is reporting DNS information without itself being authoritative for that domain. You can record the answer as evidence of what that resolver returned.
Linux with dig
If dig is installed, open a terminal and run:
dig example.com A
dig example.com AAAA
dig example.com NS
dig example.com A +noall +answerRead the full output once, looking for status, ANSWER SECTION, Query time and SERVER. The final command shows just the answer section. A typical address record has the form name TTL IN A address. If the displayed TTL goes from 240 to 230 seconds over ten seconds, a cached answer counting down is one explanation.
Try it. Repeat the final command three times, about ten seconds apart. Record the time, TTL and returned addresses. Run it again for a larger site and compare the number of returned addresses. Use the same resolver throughout. A short query time alone cannot tell you which cache supplied the result. Several addresses may reflect a distributed service, and the browser may use just one of them for a particular connection.
A-level extension. Run dig +trace example.com A to follow referrals from the root. Look for where the .com delegation appears and where the answer comes back. This is a separate investigation performed by dig, so it can look different from your browser's lookup. Some managed networks block the direct DNS queries it needs.
4. Finding an address is the beginning
Once the browser has a usable address, IP gets packets across networks. Routers forward them towards the destination. That destination might be an edge server or reverse proxy acting on behalf of the website.
With HTTPS over HTTP/1.1 or HTTP/2, a fresh connection typically starts with a TCP handshake. TCP provides reliable, ordered delivery. TLS then establishes encryption and lets the browser verify that the server presents a trusted certificate valid for the hostname. If the browser uses HTTP/3, it uses QUIC over UDP. QUIC provides reliable streams and incorporates TLS into its connection setup.
The browser can then send an HTTP request for the path and query string, along with the target hostname in the request's authority information. The server returns an HTTP response. It might send HTML, redirect the browser or report an error. As the browser reads the HTML, it may fetch stylesheets, JavaScript, images and fonts. Some of those resources can come from entirely different hostnames.
This explains the IP-address puzzle. Typing an IP address into the address bar changes the host the browser is requesting. The server may choose a different site, and the certificate may be valid only for the original hostname. A server can have the right street address and still need to know which door you are looking for.
5. Watch the browser do the work
- In Chrome or Edge on a desktop computer, open Developer Tools and choose Network.
- Navigate to
https://example.com/?lesson=dns. Select the main document request. - In Headers, look for Request URL, Status Code and, where available, Remote Address. Compare the remote address with your DNS results.
- Open Timing. Look for DNS lookup, connection setup and waiting for the first response byte. Right-click the request table headings and enable Protocol if you want to see values such as
h2orh3. - Reload, then try a public page with several images. Count how many requests appear and inspect which hostnames they go to.
What if DNS timing is missing? The browser may already have the address or be reusing a connection. Try a different hostname that you have not visited during the exercise. The Disable cache setting in the Network panel controls the browser's HTTP cache while DevTools is open. DNS caching and connection reuse are separate, so a reload with that setting can still skip a fresh lookup.
A browser's remote address can also differ from your command-line answer. The browser may use another resolver, select IPv6, connect through a proxy or reuse an established connection. Write down what you observed before deciding which explanation fits.
6. Diagnose three failures
| Observation | What you can infer | What to check next |
|---|---|---|
DNS returns NXDOMAIN. | The resolver reports that the queried name does not exist. | Check the spelling and test the exact hostname, including any www. |
| DNS returns an address, but the browser reports a connection timeout. | Your DNS tool found an address. The browser still failed to establish or complete the connection in time. | Check whether other sites work and inspect which request failed. |
DevTools shows HTTP 404. | An HTTP server responded that it could not find the requested resource or would not disclose it. | Compare the hostname and path with the intended URL. |
At Hemel Private Tuition, I would give GCSE students three screenshots and ask them to match each to DNS, connection or HTTP. For A-level students, I would ask for a short explanation with evidence from both the terminal and DevTools. A student who can explain why an HTTP 404 is evidence of a response has learnt something they can use the next time a website appears to be down.
The next time a website fails, ask where it got to
I enjoy practicals where the equipment is something students already use every day. Here, the browser and terminal turn a routine click into a trail you can follow. A name has to be resolved, a connection has to work and a server has to answer for the resource you requested. Those jobs belong to different parts of the system, and each leaves different evidence.
Try it with a site you use regularly. Look up the hostname, open the Network panel and find the first document request. Then see whether you can explain one thing that changes when you reload. That is a better computing exercise than memorising a list of protocols because it starts with a question you can answer using your own evidence.
No comments:
Post a Comment