Networking for developers: DNS, IPs, ports and TLS

When you type https://brewandbean.example/menu into a browser, a lot happens before a single byte of the menu arrives. Deployment problems such as 'it works on my laptop but not on the server', 'connection refused' or 'certificate error' almost always come from one of a few networking ideas. This lesson gives you the map: names, addresses, ports, encryption and the tools to check each one.

Think of it as posting a letter. DNS is the phone book that turns a name into a street address. The IP address is the building. The port is the flat number inside the building (which program should receive it). TLS is a sealed envelope that only the recipient can open. HTTP is the language written on the letter.

An IP address identifies a machine on a network. IPv4 addresses look like 203.0.113.10 (four numbers from 0 to 255). IPv6 addresses are longer (2001:db8::1) and exist because IPv4 addresses ran short; both are in use today.

Some IPv4 ranges are private: they only work inside a home, office or cloud network and cannot be reached from the internet directly. Your home Wi-Fi gives your phone something like 192.168.1.7. Private ranges are 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Your router uses NAT to share one public address among all your devices.

The /8 or /16 notation (CIDR) says how many leading bits are fixed. 10.0.0.0/16 means 'all addresses from 10.0.0.0 to 10.0.255.255'. You will use CIDR when you create cloud networks and firewall rules.

A port is a number from 0 to 65535 that selects the program on a machine. A server listens on a port; a client connects to it. Some are standard:

localhost (address 127.0.0.1) always means 'this same machine'. A server that listens only on 127.0.0.1 can be reached only from the same machine. A server that listens on 0.0.0.0 accepts connections on every network interface of the machine.

This causes one of the most common deployment bugs: your app works on your laptop, but inside a Docker container or on a cloud VM nobody outside can reach it, because it was bound to 127.0.0.1. For example, run Uvicorn with --host 0.0.0.0 inside containers. Inside a container, localhost means the container itself, not your laptop and not another container.

DNS is a worldwide, cached database. You own a domain name (bought from a registrar) and you create records at your DNS provider:

Each record has a TTL (time to live): how many seconds resolvers may cache the answer. After you change a record, some people still see the old one until the TTL expires. This is why a new site 'works for me but not for my friend' for a while. Lower the TTL before a planned migration.

dig +short A example.com
nslookup example.com
ping -c 3 example.com

dig and nslookup ask DNS for the records. ping checks if the machine answers (some servers deliberately block ping, so a failed ping does not always mean the server is down). On Windows, ping -n 3 example.com is the equivalent of -c 3, and nslookup works in the same way.

TLS encrypts traffic so people on the same Wi-Fi or along the route cannot read or change it, and it proves you are talking to the real server. The server presents a certificate that says 'this key belongs to brewandbean.example', signed by a certificate authority (CA) that your browser already trusts. If the name does not match, the certificate has expired or the CA is unknown, the browser shows a warning.

Certificates are free today: Let's Encrypt issues them automatically, and most hosts and cloud load balancers can manage them for you. They expire (Let's Encrypt certificates last a few months) so renewal must be automatic. An expired certificate is a classic outage.

curl -v https://example.com 2>&1 | head -n 25

-v shows each step: the DNS lookup, the connection to port 443, the TLS handshake (including who issued the certificate and when it expires) and the HTTP response. 2>&1 merges the verbose messages (printed to stderr) into the output so head can limit them.

A firewall allows or blocks traffic by port and source address. In the cloud it is usually called a security group or network security rule. The safe default is to deny everything and open only what you need: 443 (and 80 to redirect) to the world, 22 for SSH only from your own IP, and the database port only from your application servers, never from the internet.

A load balancer sits in front of several copies of your app, spreads requests across them and can terminate TLS for you. A reverse proxy such as Nginx does something similar on one machine: it receives requests on port 443 and forwards them to your app on port 8000.

ss -tlnp
curl -i http://localhost:8000/menu

ss -tlnp lists TCP ports that programs are listening on and which program owns each (-p may need sudo). A line showing 0.0.0.0:8000 or *:8000 means the app accepts outside connections; 127.0.0.1:8000 means only local ones.

My app is [framework, e.g. FastAPI] running on [where, e.g. an AWS EC2 Ubuntu server / a Docker container]. When I open [URL or IP:port] from [my laptop / the same server] I get this error: [exact error]. Here is what I already checked: [list]. Give me a checklist of causes in the order I should test them, with one command for each (DNS, firewall or security group, listening address, process running, TLS).

What to expect: A good answer follows the layers: name resolution, reachability, port open, app listening on the right address, then TLS or application errors, and gives real commands such as dig, curl -v, ss -tlnp.

Common questions: what happens when you type a URL in the browser (use the five steps above), the difference between TCP and UDP (TCP is reliable and ordered, used by HTTP; UDP is faster with no guarantees, used for DNS lookups and video calls), what a CNAME is, how HTTPS works at a high level, what a private IP is, and how you would debug 'connection refused' versus 'timed out'. Covered next in practice: *Docker: images and containers* shows port mapping, and *AWS core services* shows security groups.