From local services to global networks. Sockets and ports, private IP translation, recursive DNS, and the orchestration that makes it all work on routers and firewalls in the real world.
In Session 01, we mastered IP addressing and MAC tables. Now we move up the OSI stack: from the address to the service living at that address. This is where networking becomes practical — where engineers troubleshoot why a web server is unreachable or why SSH is hanging.
IP Address: The street address of the office building (e.g., 192.168.5.41). It identifies which machine. Port: The office number inside the building. It identifies which service on that machine. Socket: The physical person (the process) sitting at the desk in that office, actively listening and responding to visitors (packets).
In networking terms:
Ports are 16-bit numbers: 0 to 65,535. The first 1,024 (0–1023) are privileged and managed by IANA. The rest are ephemeral and first-come, first-serve.
| Port Range | Name | Control | Allocation |
|---|---|---|---|
| 0–1023 | Well-Known Ports | IANA | Assigned by standard (HTTP, SSH, DNS) |
| 1024–49151 | Registered Ports | IANA | Named but not enforced (databases, custom apps) |
| 49152–65535 | Ephemeral/Dynamic | OS | Assigned temporarily to client connections |
A service listens on a port. On Linux/Windows, use these commands to see what's listening:
TCP (Transmission Control Protocol) is connection-oriented. It uses a three-way handshake before data flows. UDP skips this; it just sends.
No handshake, no reliability, just speed. Used for DNS, VoIP, video streaming.
Public IP addresses are expensive. A single class C (/24) costs money and administrative overhead. NAT (Network Address Translation) solves this by hiding 254 internal devices behind one public IP. This is the cornerstone of every private network, every home router, every corporate firewall.
Public IP (The Pilot Number): Sprint UG's main switchboard number: +256 701 123 456. It appears on business cards. The world calls this number. Private IPs (The Extensions): Internal extensions: 101 (David), 102 (Irene), 103 (Ibrahim), 104 (Msabi). Your laptop inside the network talks to servers using extension numbers, but nobody outside knows they exist. NAT Gateway (The Receptionist / PBX): The system that translates incoming calls: "Call +256 701 123 456" becomes "Route to extension 101." Outgoing calls: "Call from extension 102" becomes "Call from +256 701 123 456." The caller sees only the public number.
Before NAT existed, networking was simpler but wasteful: every device needed a globally-routable IP. NAT solved this, but it created a paradox:
This is the asymmetry:
On MikroTik RouterOS, you can see the NAT translations in real-time:
| Type | Also Called | Behavior | Real-World Use |
|---|---|---|---|
| Source NAT | SNAT, Masquerade | Rewrite src IP on outbound traffic | Home routers, corporate outbound |
| Destination NAT | DNAT, Port Forwarding | Rewrite dst IP/port on inbound traffic | Expose internal server to internet |
| Bidirectional NAT | NAT64, NPTv6 | Rewrite both directions (IPv4↔IPv6) | IPv6 migration, dual-stack networks |
| Static NAT | 1:1 NAT | Fixed private:public IP mapping | Dedicated servers, fixed hosts |
Now we descend into the actual mechanics. NAT doesn't happen magically. The gateway (whether a MikroTik router, Linux box with iptables, or a Juniper device) is a packet interceptor and rewriter. It's the switchboard operator who knows the extension mapping.
When Dennis (192.168.1.100) initiates a request to Google, the gateway does NOT just rewrite the packet and forget it. It creates a connection state entry that holds the mapping. This is critical:
The gateway maintains a table of ALL active NAT translations. This is the heart of the system. On MikroTik, you see it here:
Dennis's laptop asks the OS for a port to use for outbound DNS. The OS hands it port 54321 (ephemeral, chosen from the available range). But once it goes through NAT, it remains 54321 on the public side (in this case). This is called hairpin NAT or port preservation.
Outbound works by accident (because the internal device initiates, creating a state entry). Inbound requires explicit rules. This is the asymmetry that trips up engineers.
Every active connection consumes memory in the gateway. This is a real bottleneck on high-traffic networks.
A telephone switchboard in 1970 is the perfect model for NAT:
NAT was designed for client-server: clients initiate, servers listen outside. But some protocols expect bidirectional openness:
DNS is the second pillar of the internet. It translates names (google.com) to addresses (142.251.41.14). Without DNS, you must memorize IP addresses — humans can't scale that. DNS makes the internet usable.
Most junior engineers confuse "DNS" with "Router." They are completely different:
| Role | Device/Service | Port | Question It Answers |
|---|---|---|---|
| Router | MX80, CCR2116, EdgeRouter | varies | "Where do I send packets destined for 192.168.3.0/24?" |
| Firewall | pfSense, MikroTik filter | varies | "Is this packet allowed by policy?" |
| DNS Server | Bind9, Unbound, DJBDNS | 53 (TCP/UDP) | "What IP address is google.com?" |
| DHCP Server | ISC-DHCP, Mikrotik DHCP | 67/68 (UDP) | "What IP can I assign to this new laptop?" |
Authoritative DNS: You own sprint-tech.codeandcore.dev. You published this domain at a registrar (GoDaddy, Route53). YOU are the authoritative server — you are the one who says "sprint-tech.codeandcore.dev = 197.248.25.100." Recursive DNS: Your laptop uses 8.8.8.8 (Google's public DNS). When you type google.com, your laptop asks 8.8.8.8: "What is google.com?" Google's server doesn't own google.com; they are just researchers. They go ask the authoritative servers for you, cache the answer, and give it back. They are the librarian; you are the customer asking, "Where is the book on dogs?"
Thirteen root servers (a–m) are operated globally. They are the apex of trust. When you ask a recursive resolver, it uses at least one root server to bootstrap the query.
Without caching, DNS would be catastrophically slow. Every query would require a full recursion. Instead, results are cached at multiple levels:
On MikroTik, you can see (and manage) the DNS cache:
| Type | Purpose | Example | Held By |
|---|---|---|---|
| A | IPv4 address | google.com → 142.251.41.14 | Authoritative |
| AAAA | IPv6 address | google.com → 2607:f8b0:4004:80c::200e | Authoritative |
| CNAME | Canonical name (alias) | www.google.com → google.com | Authoritative |
| MX | Mail server | google.com → aspmx.l.google.com | Authoritative |
| NS | Nameserver authority | google.com → ns1.google.com | Parent zone (.com) |
A critical diagnostic lesson:
Sockets. NAT. DNS. These aren't separate—they work in concert on every request. This is where theory becomes craft. You see the MX80 and MikroTik CCR2116 in front of you. Now you understand what they actually do.
Environment: Dennis sits at 192.168.1.100 (private). Gateway 192.168.1.1 translates. Public IP: 197.248.25.100. Default DNS: 8.8.8.8. Let's trace one HTTP request end-to-end.
Standing in front of a MikroTik CCR2116, here's what you'd see:
An engineer comes to you and says:
On a Juniper MX80, you'd configure DNS for the control plane like this:
A world-class network engineer understands the entire stack, not just IP routing. You now know: