How Machines Talk: Ports, Packets, Protocols and DNS

Security work is mostly reasoning about things you can't see directly. Networking is where that starts — you can't assess a system without a mental model of how its traffic moves.

Everything below runs with tools already on your machine. Follow along.

Addresses and ports

An IP address identifies a machine. A port identifies a service on it. Together they're an endpoint: 93.184.216.34:443 means the HTTPS service on that host.

See what's listening on yours:

$ ss -tulpn
Netid State  Local Address:Port   Process
tcp   LISTEN 127.0.0.1:631        cups
tcp   LISTEN 0.0.0.0:22           sshd

The distinction in that output matters more than it looks. 127.0.0.1 is reachable only from the machine itself. 0.0.0.0 means every interface — that service is exposed to the network. Confusing the two is how databases end up on the internet.

Ports worth knowing on sight:

• 22 — SSH.

• 53 — DNS.

• 80 / 443 — HTTP and HTTPS.

• 3306 / 5432 — MySQL and PostgreSQL. Should almost never face the internet.

• 3389 — RDP.

TCP and UDP

TCP establishes a connection first — SYN, SYN-ACK, ACK — then guarantees ordered delivery and retransmits losses. Web, SSH, email.

UDP just sends. No handshake, no ordering, no delivery guarantee. DNS, video calls, games — where late data is worse than missing data.

This has a practical consequence. Because TCP requires a handshake, a closed port answers differently from an open one, so you can tell them apart reliably. UDP gives you far less signal, which is why UDP scanning is slow and often inconclusive.

DNS, hands-on

DNS turns names into addresses. Ask it directly:

$ dig +short example.com A
93.184.216.34

# who handles mail for the domain
$ dig +short google.com MX
10 smtp.google.com.

# the anti-spoofing records
$ dig +short google.com TXT

On Windows without dig, use nslookup example.com.

The record types: A maps a name to IPv4, AAAA to IPv6, CNAME aliases one name to another, MX directs mail, and TXT holds arbitrary text — including the SPF and DKIM records that decide whether your domain can be spoofed.

Watch the full resolution path, one nameserver at a time:

$ dig +trace example.com

That output is the entire hierarchy — root servers, then the .com nameservers, then the domain's own. Worth reading once properly.

What actually happens when you load a page

1. DNS resolves the hostname to an IP address.

2. TCP connects to port 443 via the three-way handshake.

3. TLS negotiates — certificate presented, validated, session keys agreed.

4. The HTTP request goes over the encrypted channel.

5. The server responds with a status code, headers and a body.

6. The browser parses it and repeats for every asset the page references.

You can watch steps 3 to 5 directly:

$ curl -sSv https://example.com -o /dev/null

The lines beginning * are connection and TLS detail, > is your request, < is the response. For just the response headers:

$ curl -sSI https://example.com
HTTP/2 200
content-type: text/html; charset=UTF-8
strict-transport-security: max-age=63072000

Security headers live here. strict-transport-security forces HTTPS on later visits; content-security-policy constrains what the page may load. Their absence is a finding in almost every web assessment.

Your exercise: trace a page load

Twenty minutes, entirely on your own connection:

1. Resolve a site you use: dig +short <domain> A. More than one address? That's load balancing.

2. Run dig +trace <domain> and identify which nameserver gave the final answer.

3. Fetch the headers: curl -sSI https://<domain>. Does it set strict-transport-security? A content-security-policy?

4. Open Wireshark, capture on your main interface, apply the filter tcp.flags.syn == 1 && tcp.flags.ack == 0, then load a page. Every packet shown is a connection opening.

5. Compare curl -sSI http://<domain> against the HTTPS version. Most sites answer with a 301 redirect — you're seeing the upgrade happen.

Step 4 is the one that makes the theory concrete. Watching a real handshake beats any diagram, including mine.

Where to go next

• Wireshark's official user guide — start with capture filters and the display filter syntax.

• Cloudflare Learning Center — clear, accurate explainers on DNS, TLS and HTTP.

• TryHackMe — guided networking rooms with labs you're explicitly authorised to use.

• MDN HTTP reference — the authoritative source on headers and status codes.

Next lesson: Smart Contract Security — where these habits meet code that holds money.

---

Run this on your own machine or a lab you're authorised to use. Every command here is safe against systems you control. Pointing the same tools at infrastructure you don't own is a criminal offence in most countries, including under the US Computer Fraud and Abuse Act. The practice labs linked above exist so you can do this legally.