VLANs: why network segmentation matters

A VLAN is a logical broadcast domain layered on top of a single physical switch fabric. It is how one switch can appear to be several. Network engineers use VLANs to keep different traffic populations isolated without buying separate physical hardware for each.

What 802.1Q actually does#

A VLAN tag (IEEE Std 802.1Q) is a 4-byte header inserted into the Ethernet frame right after the source MAC address. It says: this frame belongs to VLAN N; only forward me to ports configured for VLAN N.

┌─────────┬─────────┬───────────────┬──────┬────────────┬─────┐
│ dst MAC │ src MAC │ 802.1Q tag(*) │ type │ payload    │ CRC │
└─────────┴─────────┴───────────────┴──────┴────────────┴─────┘
                    │
                    └─ TPID 0x8100, 3-bit priority (PCP), 1-bit DEI,
                       12-bit VLAN ID (0..4095; usable 1..4094)

(*) The tag is only present on trunk links: switch-to-switch (or switch-to-router) links carrying multiple VLANs. On an access port (a port assigned to exactly one VLAN) the tag is stripped on egress and added on ingress, so the end device never sees it.

Two kinds of port:

Access port: one VLAN. Frame in: tag added. Frame out: tag stripped. The end device runs untagged Ethernet and is unaware of VLANs.
Trunk port: multiple VLANs. Frames stay tagged. Both ends must agree on which VLAN IDs are allowed to traverse the link.

One caveat to "frames stay tagged": most trunks designate one native VLAN whose frames cross the link untagged. If the two ends disagree on which VLAN that is, untagged frames silently hop from one VLAN to the other with no error anywhere. A native-VLAN mismatch is a classic hard-to-spot failure; when in doubt, tag everything and use the native VLAN for nothing.

That distinction is where most "the network looks fine but nothing works" problems live.

Why segment a network?#

Different traffic populations have different trust levels, different access requirements, and different blast radii when something goes wrong. A VLAN gives each population its own broadcast domain and a chokepoint where policy can be enforced.

Segment purpose	Why it gets its own VLAN
Management plane (switches, hypervisors, out-of-band management, network appliances)	A compromise here owns the infrastructure. Keep it isolated and require explicit firewall rules to reach it.
Internal servers (resolvers, monitoring, identity services)	These receive connections from clients but should not freely initiate arbitrary outbound connections. Different ACL profile from clients.
Client workstations and VMs	Routine outbound traffic. Allowed to reach internal services and the internet; not allowed onto the management VLAN.
Isolated test workloads	Fully sandboxed segments for experiments, staging, or demos. Traffic should not bleed into production segments.
IoT / untrusted devices / guest Wi-Fi	Anything you would rather not let scan the rest of the network. Internet access only; no path to internal services.

A single managed switch with an L3-capable router or firewall enforcing policy between the VLANs replaces what would otherwise require separate physical networks.

Where this bites DNS#

Three classic "DNS is broken" failures that turn out to be VLAN misconfiguration:

1. Resolver on a different VLAN, no L3 path#

The classic. A new host is placed on VLAN 20 but the switch port or virtual NIC has VLAN tagging mis-configured, so the frame lands on the wrong segment and never reaches the gateway that routes to the resolver's VLAN. Every DNS lookup times out.

Tell: ping to the resolver IP also fails. Pure DNS-only failures are rare; usually L3 connectivity is broken as well. Start at the network layer, not the resolver.

2. Forwarder pointed at the wrong-VLAN gateway address#

The resolver sits on VLAN 20 and is configured to forward upstream queries to 192.0.2.1 (an RFC 5737 documentation address standing in for a real gateway), the gateway's interface on a different VLAN. Many gateway DNS services only answer on the interface facing each client segment, so a query aimed at a different-VLAN interface is dropped or refused. Result: every external query returns SERVFAIL after a timeout.

Tell: internal-zone queries resolve correctly; external queries fail. The fix is to point the forwarder at the same-VLAN gateway address: the gateway IP on the same segment as the resolver.

See query-types for why the forwarder's reachability matters even when the resolver has recursion enabled.

3. Trunk allows VLAN 20 but the host link is access-mode on VLAN 1#

A host is cabled into a switch port still set to "access, VLAN 1" instead of "trunk, allow 1,20,30." All its traffic lands on the wrong VLAN. Two symptoms follow, depending on policy: if the inter-VLAN firewall drops the traffic, every query times out silently; if the queries do get routed through, the resolver sees them arriving from an unexpected source range and its ACL answers REFUSED.

Tell (the drop case): the host "cannot reach DNS," but tcpdump on the host's interface shows queries leaving normally. They are just never answered. In the REFUSED case the resolver is answering; the rcode tells you it is an ACL and source-range problem, not connectivity. Either way, audit the switch port configuration, not the resolver.

The three-line VLAN sanity check#

When a host cannot reach its resolver, work from L2 up before touching DNS configuration.

Step 1: confirm the interface is tagged correctly (Linux).

Inspect the VLAN sub-interface, not the parent. On Linux a tagged interface is a child device named parent.vlanid (for example eth0.101 for VLAN 101 on eth0):

ip -d link show eth0.101 | grep vlan

Expected output when the sub-interface is correctly tagged:

    vlan protocol 802.1Q id 101 <REORDER_HDR> addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536

The id value is the VLAN ID assigned to this sub-interface. Note that this detail line only appears on the sub-interface itself; running the same command against the parent (ip -d link show eth0) prints nothing VLAN-related even when tagging is configured correctly, so a quiet parent tells you nothing. If the command instead reports Device "eth0.101" does not exist., the sub-interface was never created and the host is not sending or receiving tagged frames on that VLAN.

macOS: macOS does not ship the ip tooling; VLAN interfaces are managed with networksetup. List them with networksetup -listVLANs, inspect one with ifconfig vlan0 (macOS names them vlan0, vlan1, ...), and create one with networksetup -createVLAN <name> <parent-device> <tag> or via System Settings > Network > the Action menu > Manage Virtual Interfaces > New VLAN (Apple's guide). Most end hosts on macOS connect to access ports and never see raw 802.1Q tags; this step is mainly relevant when troubleshooting a Linux-based host, container, or VM.

Step 2: check for ARP activity on the segment.

ip neigh

A healthy segment shows neighbor entries for the gateway and nearby hosts in REACHABLE or STALE state. STALE is normal, not a fault; it only means the entry has not been confirmed recently (ip-neighbour(8)). An empty table, or the gateway stuck in INCOMPLETE or FAILED, means L2 is broken before any DNS query can leave.

Step 3: confirm the gateway responds at L3.

ping -c 3 <gateway-ip>

Replace <gateway-ip> with the segment's actual gateway address; on Linux, ip route show default prints it. If this succeeds, L2 and L3 are healthy and DNS troubleshooting is appropriate. If it fails, the problem is not DNS, with one caveat: some networks filter ICMP. If ping fails but step 2 shows the gateway REACHABLE, L2 is fine and ping is simply being dropped.