DNS + Routing: Cross-Subnet Resolution

The scenario

Subnet 10.0.1.0/24 holds a Workstation (10.0.1.10) and the DNS Server (10.0.1.2). Subnet 10.0.2.0/24 holds Web App (10.0.2.20, HTTP on TCP port 80) and Database (10.0.2.30, PostgreSQL on TCP port 5432). Core Router joins the two with 10.0.1.1 and 10.0.2.1. The Workstation and Web App are both set to use 10.0.1.2 as their DNS server, and both have a default gateway on Core Router. The DNS Server has an address but no default gateway: it can answer devices on its own subnet and nobody else. That one missing route is the problem this lab walks you into.

What you will work out

See a DNS lookup and the connection that follows as two separate conversations, each needing a path in both directions.

Why this matters

Servers look up names too: an application reaches its database by name, a web server calls an API by name. A DNS server that only works for clients on its own subnet is an easy mistake to make when a new subnet is added, and it shows up as an application error rather than a network one. The quick split is the same as for any lookup problem: does the connection work by address, and does the lookup get an answer?

Running it

DNS + Routing: Cross-Subnet Resolution opens on a canvas, already wired and addressed. Trace a packet through it hop by hop, or run the same topology live on real Linux network namespaces. How the two modes differ.