Lesson 1: DNS, DHCP, NAT, VLAN, and VPN

Two services are blamed for an absurd number of network problems: DHCP and DNS.

They are not the same thing.

They do not even solve the same problem.

DHCP helps an endpoint obtain network configuration. DNS helps applications turn names into addresses.

If you keep those jobs separate, several common support tickets become much easier to read.

Diagrams open at a readable shape-aware scale. Zoom or expand when you need more detail.

DHCP answers: what configuration should this client use?

A DHCP-managed IPv4 client can receive values such as:

IP address
subnet mask / prefix
default gateway
DNS server information
lease duration

That means DHCP sits early in the usable network path.

If the client never receives the expected address, gateway, and related configuration, there may be nothing useful for DNS to do yet.

Lease

A lease is a time-limited assignment of configuration to a client.

Scope

A scope defines the pool of addresses and related options DHCP can provide for a network.

network:     192.168.40.0/24
DHCP pool:   192.168.40.100-199
gateway:     192.168.40.1
DNS server:  192.168.40.10

Reservation

A reservation gives a known client a predictable assignment through DHCP.

That can be useful for a printer or service endpoint that should remain easy to find without unmanaged static values.

Exclusion

An exclusion marks addresses that the DHCP service should not distribute from an otherwise managed range.

The larger point is that address planning is a system. Static assignments, reservations, exclusions, and the dynamic pool should not collide.

System process animation

DHCP lease: discover to usable configuration

Animate the exchange that gives a client its address, route, and resolver settings.

RestartPreviousPlay sequenceNext

1. 1DiscoverThe client broadcasts that it needs configuration.
2. 2OfferA server proposes an address and options.
3. 3RequestThe client requests one offered lease.
4. 4AcknowledgeThe server commits and confirms the lease.
5. 5ConfigureThe client applies address, gateway, and DNS.
6. 6VerifyThe client tests local and routed connectivity.

Technician question: If a client uses 169.254.x.x, which exchange did not finish?

APIPA is evidence about missing expected configuration

Suppose a Windows client shows:

IPv4:   169.254.18.42
Gateway: none

while the site expects DHCP on 192.168.40.0/24.

The client has a link-local IPv4 address, but it did not receive the expected site configuration.

That points toward the DHCP and address-acquisition path.

It does not prove the NIC is dead, DNS is broken, or the provider is down.

DNS answers a different question: where does this name go?

People prefer names such as:

portal.example
files.example
mail.example

DNS connects those names to service information.

At A+ recognition depth, know these record types:

Mail systems may use TXT records for mechanisms such as SPF, DKIM, and DMARC-related policy or verification.

You are not administering a public mail domain here. The useful idea is that DNS stores different record types because different service relationships need different information.

System process animation

Name to service: DNS before the application

Keep resolution separate from the later route, transport, and application connection.

RestartPreviousPlay sequenceNext

1. 1Client asksAn application requests an address for a hostname.
2. 2ResolverThe configured resolver receives the query.
3. 3Authoritative pathDNS delegation locates authoritative data.
4. 4DNS answerThe resolver returns an address or explicit failure.
5. 5TransportThe client attempts the required port.
6. 6ApplicationThe service returns the expected response.

Technician question: Which result proves DNS, and which proves the service?

Worked case: remote IP works, hostname fails

Evidence:

local IP configuration: valid
gateway: reachable
remote documentation IP: reachable
portal.test: does not resolve

What has already been proven?

• local network configuration is usable enough for remote IP traffic;
• the gateway path works;
• at least one remote IP path works.

The strongest next checks belong around DNS configuration, query behavior, and the relevant record.

Replacing the Ethernet cable would ignore the evidence.

System process animation

NAT translates a conversation at the routed boundary

Track the tuple before translation, in state, and on the public side.

RestartPreviousPlay sequenceNext

1. 1Private sourceA client creates traffic with a private source tuple.
2. 2Gateway lookupThe router selects route and NAT policy.
3. 3TranslationThe router assigns a public source and port.
4. 4Public flowThe translated packet crosses the provider.
5. 5Return matchReply traffic matches translation state.
6. 6Private deliveryThe router restores the private destination.

Technician question: What proves translation exists while the return path still fails?

NAT translates addressing across a boundary

In many SOHO networks, internal clients use private IPv4 addresses while the router represents their traffic across an external boundary using Network Address Translation, or NAT.

192.168.40.25
       ↓
     router
       ↓
translated external-side traffic

NAT is not the same thing as a firewall.

A firewall applies traffic-control policy. NAT changes address information according to configured translation behavior.

One device may perform both functions, but the functions are different.

A VLAN creates a logical local boundary

A managed switch can support multiple VLANs on the same physical infrastructure.

switch
├── VLAN 10 staff
└── VLAN 20 guest

The cables may enter the same switch, but the endpoints belong to different logical Layer-2 networks.

Traffic between VLANs requires appropriate Layer-3 routing and policy.

A VLAN is not just a label. It changes the logical network boundary.

A VPN creates a protected logical path across another network

A virtual private network, or VPN, creates a protected logical connection according to its configured security model.

Common use cases include:

• remote user → organization network;
• site → site connection.

A VPN does not repair broken Wi-Fi.

The local path still has to work before the VPN can use it.

Put the jobs side by side

Use the table to reject wrong explanations, not as an acronym quiz.

Worked case: printer needs a predictable address

Requirement:

The shared printer should keep a predictable address, but the organization wants centralized DHCP management.

A DHCP reservation is a strong design.

Why is that better than randomly assigning an address manually?

Because the address remains part of the documented DHCP plan instead of becoming an unmanaged value that can later collide with the pool.

The goal is not merely to make it work today.

The goal is to make the system supportable tomorrow.

Identify the failed responsibility

For each symptom, name the mechanism you would inspect first and explain why.

1. Client has APIPA instead of the expected site address.
2. Client reaches remote IP addresses but names fail.
3. Guest device can reach staff resources that policy says should be separated.
4. Local internet works but the approved remote-access tunnel will not establish.
5. Two manually assigned endpoints collide with an address inside the dynamic pool.
6. Private LAN clients work locally, but the router's translated external path is misconfigured.

Do not answer with only the acronym.

State what evidence makes that responsibility relevant.

Before you move on

Separate the jobs:

DHCP → configuration
DNS  → naming
VLAN → logical local separation
gateway → off-subnet next hop
NAT → address translation
VPN → protected logical path

Next we add transport endpoints and ports, where another common mistake appears: treating a familiar port number as proof that the application behind it is healthy.