Learn how data moves between computers: layers, IP addresses and subnets, ports, DNS, DHCP, HTTPS, and the tools to troubleshoot it.

Networking Fundamentals

Look up a name: run `nslookup example.com` (or `dig example.com`). Write down the IP address(es) and which DNS server answered.

Ask for other record types: `nslookup -type=MX gmail.com` and `nslookup -type=AAAA google.com` (or `dig gmail.com MX`, `dig google.com AAAA`). Note what each record type returns.

Find a CNAME: run `nslookup www.github.com` (or `dig www.github.com`) and note any alias (canonical name) before the final address.

Ask a specific resolver: `nslookup example.com 1.1.1.1` (or `dig @1.1.1.1 example.com`). Compare the answer with step 1.

If you have dig, run `dig +trace example.com` and identify the root servers, the .com servers and the example.com name servers in the output. (Without dig, read the trace walkthrough in the lesson instead.)

With dig, look at the TTL value in an answer, run the same query again a minute later, and note how the TTL has gone down (served from cache).

Look up a name that does not exist, such as `no-such-name.example.com`, and note the NXDOMAIN response.

## Why it matters

People remember names; networks route by IP address. The **Domain Name System (DNS)** translates one to the other. It is so central that "it's always DNS" is a running joke among engineers: a wrong record, an expired domain or a slow resolver can take down a service whose servers are perfectly healthy. Cloud and security engineers edit DNS records, and attackers abuse DNS for phishing and data theft, so you need to know how a lookup works.

## Names are a tree

A name such as `www.example.com.` is read right to left:

- `.` the **root** (usually hidden)
- `com` a **top-level domain (TLD)**
- `example` a domain registered under .com
- `www` a name inside that domain

Each level is run by different name servers. The root servers know who runs `.com`; the `.com` servers know who runs `example.com`; the `example.com` name servers are **authoritative** and hold the actual records.

## Who does the work

- Your computer has a **stub resolver**: it just asks one server and waits.
- A **recursive resolver** (your ISP's, your router's, or a public one such as 1.1.1.1 or 8.8.8.8) does the legwork and caches answers.
- **Authoritative servers** give the final answer for their zone.

## Worked example: tracing a lookup

You visit `www.example.com` with empty caches:

1. Your laptop checks its own cache and the hosts file. Nothing.
2. It asks the recursive resolver configured by DHCP, say `192.168.1.1`, over UDP port 53.
3. The resolver asks a **root server**: "where is www.example.com?" The root replies: "I don't know, but here are the .com servers."
4. The resolver asks a **.com server**, which replies with the name servers for example.com.
5. The resolver asks an **example.com name server**, which answers: `www.example.com A 93.184.215.14`, with a TTL.
6. The resolver caches the answer for the TTL and returns it to your laptop, which caches it too.

(The real address you see for example.com may differ; addresses in these lessons are illustrations.) The next visitor using that resolver gets the answer from cache in a millisecond or two.

## Record types you will meet

| Type | Holds | Example |
|---|---|---|
| A | IPv4 address | `example.com A 93.184.215.14` |
| AAAA | IPv6 address | `example.com AAAA 2606:2800:21f:cb07:6820:80da:af6b:8b2c` |
| CNAME | alias to another name | `www.shop.com CNAME shop.example-cdn.net` |
| MX | mail servers for a domain | `gmail.com MX 5 gmail-smtp-in.l.google.com` |
| TXT | free text: verification, SPF, DKIM | `"v=spf1 include:_spf.google.com ~all"` |
| NS | the zone's name servers | `example.com NS a.iana-servers.net` |

## Querying DNS yourself

```bash
nslookup example.com              # works on Windows, macOS, Linux
dig example.com                   # macOS / Linux, more detail
dig gmail.com MX                  # a specific record type
dig @1.1.1.1 example.com          # ask a specific resolver
dig +trace example.com            # follow the delegation from the root
```

In `dig` output, the ANSWER section shows the records, with the TTL in seconds:

```text
;; ANSWER SECTION:
example.com.   3600   IN   A   93.184.215.14
```

## TTL and caching

The **time to live (TTL)** tells resolvers how long to cache a record. Long TTLs (hours) reduce load and speed up lookups; short TTLs (60 to 300 seconds) let you move a service quickly. Before a planned migration, engineers lower the TTL a day ahead so the change spreads fast. "DNS propagation" is mostly old cached answers expiring.

## Security notes

Classic DNS is unencrypted, so anyone on the path can see and potentially tamper with lookups. **DNS over HTTPS (DoH)** and **DNS over TLS (DoT)** encrypt the query to the resolver, and **DNSSEC** lets resolvers verify that answers are signed by the zone owner.

## Common mistakes

- **Editing a record and expecting instant change** while the old TTL is still cached.
- **Putting a CNAME at the zone apex** (`example.com` itself). Standard DNS does not allow it; providers offer ALIAS or flattening records instead.
- **Blaming the server** when the problem is a resolver: test with a second resolver (`dig @1.1.1.1`).
- **Forgetting the hosts file**, which overrides DNS on that one machine.

## Quick recap

- DNS turns names into addresses through a tree: root, TLD, authoritative.
- A recursive resolver does the lookups and caches by TTL.
- Know A, AAAA, CNAME, MX, TXT and NS records.
- Use `nslookup` and `dig` to check what DNS really returns.

## Try it

Open the **Do** tab and trace a few lookups from your own computer.


Trace how a name like www.example.com becomes an IP address, and query DNS yourself with nslookup or dig.

How DNS Works - Computerphile

How a DNS Server (Domain Name System) works.

## Why it matters

When you join a Wi-Fi network, your phone gets an IP address, a gateway and DNS servers within a second, and then reaches the internet even though dozens of devices in the house share one public address. Two services make that happen: **DHCP** hands out the settings, and **NAT** shares the address. Both appear in cloud networks too (managed DHCP options and NAT gateways), and both are common sources of "no internet" problems.

## DHCP: automatic configuration

A device needs four settings to use an IP network:

1. an **IP address**
2. a **subnet mask**
3. a **default gateway** (the router that leads off the local network)
4. one or more **DNS servers**

Typing these by hand on every device would be slow and error-prone, so the **Dynamic Host Configuration Protocol** does it. On a home network, the DHCP server is built into the router.

### DORA: the four-message exchange

DHCP uses UDP (server port 67, client port 68). A device that has no address yet goes through **DORA**:

1. **Discover:** the client broadcasts "is there a DHCP server?" (it has no address, so it sends from `0.0.0.0` to `255.255.255.255`).
2. **Offer:** the server offers an address, for example `192.168.1.23`, plus mask, gateway and DNS.
3. **Request:** the client broadcasts "I'd like 192.168.1.23", so other servers know their offers were declined.
4. **Acknowledge:** the server confirms, and the client starts using the address.

### Leases

Addresses are **leased**, not given forever. A typical home lease is 24 hours. The client renews at about halfway through. When devices leave, their addresses return to the **pool**. A router often hands out a range such as `192.168.1.100` to `192.168.1.199`.

A **reservation** (static lease) makes the router always give the same address to one device's MAC address, which is handy for a printer or a home server.

If no server answers, the device gives itself a `169.254.x.x` address and cannot reach the internet. That address is a strong clue that DHCP failed.

## NAT: sharing one public address

Your ISP usually gives your home **one public IPv4 address**. Inside, devices use private RFC 1918 addresses such as `192.168.1.x`, which are not routable on the internet. **Network Address Translation (NAT)** on the router rewrites addresses as traffic leaves and returns.

The form used at home is **PAT** (port address translation, also called NAT overload): many inside devices share the one public address, told apart by port numbers.

### Worked example: the NAT table

Your public address is `203.0.113.7`. Two devices browse at the same time:

```text
Inside (private)        ->  Outside (public)          ->  Server
192.168.1.23:52814      ->  203.0.113.7:40001         ->  93.184.215.14:443
192.168.1.40:52814      ->  203.0.113.7:40002         ->  93.184.215.14:443
```

Both devices happened to pick source port 52814. The router rewrites each to a unique public port and records the mapping. When a reply arrives at `203.0.113.7:40002`, the router looks it up and forwards it to `192.168.1.40:52814`.

### Side effects of NAT

- **Inbound connections are blocked by default.** An outside device cannot start a connection to `192.168.1.40` because the router has no mapping for it. This acts like a basic firewall, but it is not a security control to rely on.
- **Port forwarding** creates a permanent mapping (for example public port 8443 to `192.168.1.50:443`) to expose one inside service. Do it only when you understand the risk.
- **Carrier-grade NAT (CGNAT):** some ISPs put customers behind another layer of NAT, so your router's "WAN" address may itself be private (often in `100.64.0.0/10`).
- **IPv6** has enough addresses that NAT is generally not needed; firewalls do the filtering.

## In the cloud

A cloud virtual network uses private subnets too. Instances in a private subnet reach the internet through a **NAT gateway**, which lets them download updates while blocking inbound connections. NAT gateways are usually billed per hour and per gigabyte, so they are a common surprise on a cloud bill.

## Common mistakes

- **Setting a static IP inside the DHCP pool.** The router may later hand the same address to another device, causing an address conflict. Use a reservation or an address outside the pool.
- **Running two DHCP servers on one network** (for example, a second router left in router mode). Devices get conflicting gateways.
- **Confusing your private and public addresses.** `ipconfig`/`ip addr` shows the private one; a "what is my IP" site shows the public one.
- **Treating NAT as a firewall.** Keep a real firewall enabled.

## Quick recap

- DHCP gives devices an address, mask, gateway and DNS servers via Discover, Offer, Request, Acknowledge, on a lease.
- NAT (PAT) lets many private addresses share one public address by rewriting ports.
- 169.254.x.x means DHCP failed; inbound traffic needs port forwarding through NAT.


Explain how a home router hands out addresses with DHCP and shares one public address with NAT.

DHCP and NAT

DHCP Explained - Dynamic Host Configuration Protocol

NAT Explained - Network Address Translation

Open any HTTPS site you use (for example, a news site). Click the icon left of the address bar and open the certificate details (in Chrome: "Connection is secure", then "Certificate is valid"; in Firefox: "Connection secure", "More information", "View Certificate").

Record the certificate's subject (Common Name and Subject Alternative Names), the issuer (which certificate authority signed it) and the validity dates. How many days until it expires?

Find the certificate chain (Certification Path or the tabs along the top). Write down the leaf, intermediate and root certificate names.

Open the developer tools (F12 or Cmd+Option+I), go to the Network tab, and reload the page.

Click the first request (the page itself). Note the request method, the status code, and the `content-type` and `cache-control` response headers.

Find one request that returned a 3xx or 304 status, or type the site's address with `http://` to see a redirect to HTTPS. Note the `location` header if there is one.

Visit https://expired.badssl.com/ (a test site made for this purpose) and read the browser warning. Do not click through; note which error it reports.

## Why it matters

Almost every application talks over **HTTP**, and almost all of that traffic is protected by **TLS** (HTTP over TLS is **HTTPS**). APIs, cloud consoles, database admin panels and model-serving endpoints all use it. Reading status codes and headers is a daily debugging skill, and understanding certificates helps you fix "your connection is not private" errors and spot attacks.

## HTTP: requests and responses

HTTP is a text-based request/response protocol. The client sends a **request**:

```http
GET /docs/start HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
```

The server sends a **response**:

```http
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=3600
Content-Length: 5120

<!doctype html> ...
```

**Methods** say what the client wants: `GET` reads, `POST` creates or submits, `PUT`/`PATCH` update, `DELETE` removes.

**Status codes** are grouped by the first digit:

| Range | Meaning | Common examples |
|---|---|---|
| 2xx | success | 200 OK, 201 Created, 204 No Content |
| 3xx | redirect or cached | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 4xx | client error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests |
| 5xx | server error | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout |

HTTP is **stateless**: each request stands alone. Logins work by the server setting a **cookie** that the browser sends back on later requests.

Versions: HTTP/1.1 sends one request at a time per connection, HTTP/2 multiplexes many over one TCP connection, and HTTP/3 runs over QUIC on UDP.

## The problem TLS solves

Plain HTTP crosses many networks (your Wi-Fi, your ISP, other carriers). Anyone on the path could read passwords or change the page. TLS provides three things:

1. **Confidentiality:** traffic is encrypted.
2. **Integrity:** tampering is detected.
3. **Authentication:** you are talking to the real `example.com`, proven by a certificate.

## Certificates and trust

A **certificate** binds a public key to one or more names (listed in the Subject Alternative Names). It is signed by a **certificate authority (CA)**. Your operating system and browser ship with a list of trusted **root CAs**. Sites usually send a **chain**: their leaf certificate plus an intermediate certificate, which was signed by a root you already trust.

The browser checks that:

- the chain leads to a trusted root,
- the name you typed matches the certificate,
- today is within the validity dates,
- the certificate has not been revoked.

Free CAs such as Let's Encrypt issue certificates valid for 90 days or less and renew them automatically, so expiry problems are usually an automation failure.

## The TLS 1.3 handshake, simplified

1. **ClientHello:** the browser lists supported cipher suites and sends a key share.
2. **ServerHello:** the server picks a cipher suite, sends its key share, its certificate and a signature proving it holds the private key.
3. Both sides compute the same **session keys** from the key shares (a Diffie-Hellman exchange). From here on, everything is encrypted with fast symmetric encryption.
4. The HTTP request travels inside the encrypted tunnel.

TLS 1.3 needs one round trip before data flows; TLS 1.0 and 1.1 are obsolete and disabled by modern browsers.

## What an observer still sees

With HTTPS, someone on your network cannot see page contents, paths, cookies or form data. They can still see your IP address, the server's IP address, timing and volume, and usually the site's name (from DNS and the Server Name Indication field), unless encrypted DNS and Encrypted Client Hello are in use.

## Worked example: reading a failure

A user reports `NET::ERR_CERT_DATE_INVALID`. You open the certificate and see it expired yesterday: the renewal job failed. A different error, `ERR_CERT_COMMON_NAME_INVALID`, would mean the certificate does not list the name used, for example a certificate for `example.com` served on `api.example.com`.

## Common mistakes

- **Treating the padlock as "safe site".** It means the connection is encrypted to that name; phishing sites have valid certificates too.
- **Clicking through certificate warnings** on public networks.
- **Mixing HTTP resources into an HTTPS page** (mixed content), which browsers block.
- **Reading 401 and 403 as the same.** 401: not authenticated (log in); 403: authenticated but not allowed.

## Quick recap

- HTTP: methods, status codes, headers; stateless, with cookies for sessions.
- TLS adds encryption, integrity and server authentication.
- Certificates chain up to a trusted root CA and must match the name and dates.

## Try it

Open the **Do** tab to inspect a certificate and real HTTP traffic in your browser.


Follow an HTTP request and response, explain what TLS adds, and inspect a website's certificate in your browser.

HTTP and TLS

SSL, TLS, HTTPS Explained

TLS Handshake Explained - Computerphile

DNS, DHCP and NAT, and HTTP with TLS: the services that make a network usable and secure.