// networking basics — module 04

Module 4 — Networking III: The Protocols You'll Live In (and DNS in Depth)

Thesis: Layer 7 is where named services live. You need a core set of ports memorized cold and a deep understanding of DNS — because DNS appears in nearly every investigation and nearly every attack chain, and because "port 4444 where I expected 443" is an instinct that starts here.

Prerequisite: Module 3 — Networking II: Transport, Ports, and the Three-Way Handshake. Ports and TCP/UDP are the vocabulary this module uses constantly.

4.1 Why memorize ports at all

You cannot interpret traffic, triage an alert, or plan an assessment without knowing what normally talks on which port. When you see a connection to port 22, you should think "SSH" instantly, the way you read a word without spelling it out. That fluency is what lets you notice the abnormal — a service on a port it has no business being on. Baselining "normal" is the whole game for a defender, and knowing what services exist to attack is the whole game for the attacker doing reconnaissance.

4.2 The core ports — know these on sight

Drill these until they're instant. Group them by what they do; note especially which are plaintext (readable straight off the wire) versus encrypted — a distinction that matters enormously for both attack and defense, and which you'll prove in Module 5.

The pattern worth internalizing: the plaintext protocols (Telnet, FTP, HTTP, POP3, IMAP, plain SMTP) send everything — including passwords — in the clear, while their encrypted cousins (SSH, HTTPS, IMAPS, SMTPS, LDAPS) protect it. This is the recurring theme. Anything plaintext can be read by anyone who can see the traffic.

4.3 DNS — the internet's phone book (learn this thoroughly)

DNS (Domain Name System) translates human-friendly names like example.com into the IP addresses machines actually route to. It's on port 53 (UDP for normal queries, TCP for larger responses). You memorize services by port; DNS is the service that turns names into those addresses in the first place. Learn it deeply — it earns its own long section because it's everywhere.

4.3.1 The resolution process

You almost never talk to the authoritative source directly. Instead your resolver (typically run by your ISP or a public service like 8.8.8.8) walks a hierarchy on your behalf, top down:

  You ask resolver:  "What's the IP of www.example.com?"

  Resolver → ROOT server:  "Where do I find .com?"
  Root → "Ask the .com TLD servers, here they are."

  Resolver → TLD (.com) server:  "Where do I find example.com?"
  TLD → "Ask example.com's authoritative servers, here they are."

  Resolver → AUTHORITATIVE server:  "What's www.example.com?"
  Authoritative → "It's 93.184.216.34."

  Resolver → You:  "93.184.216.34."  (and caches it — see 4.3.3)

Two words for the query styles:

• Recursive — "do all the work and just give me the final answer." That's what you ask your resolver.
• Iterative — "tell me the next place to ask." That's what the resolver does to each server in the hierarchy, following referrals down the tree.

The hierarchy — root → TLD → authoritative — is the shape to lock in. There are a small number of root server clusters at the top; TLD servers own each suffix (.com, .org, .io); authoritative servers own each individual domain.

4.3.2 Record types

A DNS zone holds different record types, each answering a different question. Know these:

• A — name → IPv4 address. The most common lookup.
• AAAA — name → IPv6 address.
• CNAME — an alias: "this name is really another name; go look that up."
• MX — mail exchange: which mail servers accept email for this domain.
• TXT — arbitrary text. Used for domain verification, and for SPF/DKIM/DMARC email-authentication records.
• NS — the name servers authoritative for the domain.
• PTR — the reverse lookup: IP → name. Lives in a special reverse zone.
• SOA — start of authority: administrative info about the zone (primary server, serial number, refresh timers).

4.3.3 Caching and TTL

Every answer comes with a TTL (time-to-live) — how many seconds it may be cached before it must be looked up fresh. Caching happens at every level (your OS, your resolver) to cut load and latency; without it, the root servers would collapse under the world's queries. TTL is a trade-off: long TTLs mean fast, cheap lookups but slow propagation of changes; short TTLs mean the opposite. Stale caches matter for both troubleshooting ("why am I still getting the old IP?") and attacks (poisoning a cache pollutes everyone who trusts it until the TTL expires).

4.3.4 Why DNS is a security battleground

DNS touches all three legs of the CIA triad from Module 0, which is why it shows up constantly:

• Confidentiality — classic DNS is plaintext, so anyone on-path can see every name you look up. Your DNS queries are a record of everywhere you go.
• Integrity — cache poisoning / spoofing feeds a resolver a forged answer, silently sending victims to an attacker's server.
• Availability — DNS is a favorite DDoS target (knock out DNS and names stop resolving, taking everything "offline" even though the servers are fine).
• Abuse as a channel — because DNS traffic is ubiquitous and often unmonitored, attackers hide command-and-control and data exfiltration inside DNS queries (DNS tunneling — encoding stolen data into the subdomains of lookups). Defenders, in turn, treat DNS logs as one of the richest sources of detection — weird, long, high-entropy domain names are a classic tell.

4.4 DHCP — how a device gets its address automatically

When a device joins a network, it usually has no IP yet. DHCP (Dynamic Host Configuration Protocol, ports 67/68, UDP) hands it one automatically through a four-step exchange you remember by the acronym DORA:

  DISCOVER  — client broadcasts: "Is there a DHCP server? I need an address."
  OFFER     — server replies:    "Here's an address you can have: 192.168.1.50."
  REQUEST   — client:            "I'd like that one, please."
  ACKNOWLEDGE — server:          "It's yours, for this lease time. Here's also
                                  your gateway, subnet mask, and DNS server."

Notice DHCP hands out not just an IP but the whole starter kit from Modules 2–4: subnet mask, default gateway, and DNS server. That's why plugging into a network "just works." It's also why a rogue DHCP server is dangerous — it can hand victims a malicious gateway or DNS server and reroute their traffic.

4.5 HTTP / HTTPS at a glance

HTTP (port 80) and HTTPS (port 443) are the web's protocol — request/response, methods, status codes. It's the busiest protocol on earth and gets a full module of its own (Module 6 — How the Web Works (Because Everything Is Web Now)). For now, just place it: HTTP is plaintext Layer 7, HTTPS is the same wrapped in TLS encryption (crypto in Module 7 — Cryptography Fundamentals).

4.6 ICMP — the network's diagnostics

ICMP (Internet Control Message Protocol) isn't about carrying user data — it's the network's own signaling and diagnostics layer. Two everyday tools ride on it:

• ping sends an ICMP "echo request" and times the "echo reply." It answers "is this host reachable, and how long does a round trip take?"
• traceroute (tracert on Windows) reveals the hop-by-hop path from Module 2's routing. It sends packets with deliberately small TTL values (the IP time-to-live, a hop counter — not the DNS TTL) so each router along the way is forced to send back an ICMP "time exceeded," revealing itself. The result is a numbered list of every router between you and the destination.

ICMP is also security-relevant: attackers use ping sweeps to find live hosts, and can tunnel data over ICMP; defenders often rate-limit or filter it. But its core purpose is diagnostic, and it's how you see routing happen.

4.7 The remote-access and file trio: SSH, RDP, SMB

Three Layer-7 services show up in nearly every environment and are simultaneously high-value targets and high-value telemetry:

• SSH (22) — encrypted remote shell into Linux/Unix hosts. The admin's front door — and the attacker's, if credentials leak.
• RDP (3389) — Windows Remote Desktop, a full graphical remote session. Endlessly targeted; exposing it to the internet is a classic fatal mistake.
• SMB (445) — Windows file sharing (and much of Windows networking). Historically the source of famous, wormable vulnerabilities, and the protocol lateral movement often rides on inside a network.

Wherever these live, both tracks pay attention: attackers because compromising them grants access and movement, defenders because their logs are gold and their misuse is a bright signal.

4.8 Plaintext vs. encrypted, one more time

It's worth stating the recurring theme on its own: anything plaintext can be read straight off the wire by anyone positioned to see it. Telnet, FTP, HTTP, and plain mail protocols hand over credentials and content in the clear. You will literally watch a plaintext login expose a password in Module 5. This single fact drives an enormous amount of both offense (sniff for creds) and defense (kill plaintext protocols, encrypt everything).

4.9 → Red/Blue

Red teams enumerate services by port (that's what a port scan produces — a list of "what's talking here"), then abuse the protocols: DNS tunneling for covert channels, SMB for exploitation and lateral movement, plaintext protocols for free credentials. Blue teams baseline what's normal on each port and alert on anomalies: DNS to freshly-registered or high-entropy domains, SMB connections from hosts that should never speak SMB, plaintext credentials crossing the wire, RDP exposed where it shouldn't be. The port map and the DNS knowledge in this module are the shared reference both sides read the world through.

Lab 4

Do these in your lab (some need the temporary NAT/internet access from Module 1).

1. Query DNS by record type. Use dig example.com A, dig example.com MX, and dig example.com NS (or nslookup -type=MX example.com). Read the answer section each time. What IP does the A record give? Which servers handle its mail? Which are its name servers?

2. Trace a full resolution. Run dig +trace example.com. Watch it start at the root, get referred to the TLD (.com) servers, then to the domain's authoritative servers, and finally get the answer. Identify each tier in the output. This is §4.3.1 happening live.

3. Reverse it. Run dig -x 8.8.8.8 (a PTR lookup). Note that IP → name is a separate record type from name → IP.

4. Watch routing with your own eyes. ping a host and read the round-trip times. Then traceroute (or tracert) the same host and explain, per hop, what ICMP is telling you — each line is one router on the path, exactly the hop-by-hop forwarding from Module 2.

5. Drill the ports. Make a flashcard set of the §4.2 table (port → service, and plaintext vs. encrypted). Drill until every one is instant, both directions. This pays off in every later module.

✅ Mastery Check — do not proceed until true

Answer out loud, without notes:

1. Name the service on ports 22, 23, 25, 53, 80, 443, 445, and 3389. Which of those are plaintext, and why does that matter?
2. Walk through DNS resolution from your resolver to the answer, naming the root, TLD, and authoritative tiers, and the difference between recursive and iterative queries.
3. What do A, CNAME, MX, NS, PTR, and TXT records each hold?
4. What is a DNS TTL, and why does caching matter for both performance and attacks?
5. Give one way DNS can be attacked for each leg of the CIA triad, and explain DNS tunneling.
6. Recite the DORA exchange and say what a DHCP server hands out besides an IP.
7. What does traceroute exploit about IP TTL to reveal the path, and how does that connect to Module 2's routing?
8. Why are SSH, RDP, and SMB simultaneously high-value targets and high-value telemetry?

And perform cold:

• Resolve a domain's A, MX, and NS records with one tool, and trace one full resolution identifying each server tier.

When all of that is effortless: Module 5 — Reading Traffic: tcpdump & Wireshark