A DMZ, or demilitarized zone, is an isolated network segment that hosts public-facing services such as web, mail and DNS servers between the untrusted internet and the trusted internal network. In network security, its purpose is containment: if an exposed server is compromised, the attacker lands in a zone that has no direct path into internal systems.
The term borrows from the buffer strip between two hostile territories. Technically, a DMZ is defined less by its location than by its firewall rules, which allow traffic from the internet into the DMZ and from the internal network into the DMZ, but block connections from the DMZ into the internal network except for narrowly approved flows.
How a DMZ separates traffic
A DMZ separates traffic by placing exposed servers in their own subnet and security zone, with a firewall enforcing a rule set for every direction of travel. The default stance is deny by default, and each permitted flow is listed explicitly by source, destination, protocol and port.
The rule matrix below shows the classic policy. Its most important line is the third one: servers in the DMZ may only reach specific internal services, such as a database on one port, and nothing else.
| Direction | Default action | Typical exceptions |
|---|---|---|
| Internet to DMZ | Deny | TCP 443 to the web server, TCP 25 to the mail relay |
| Internet to internal network | Deny | None |
| DMZ to internal network | Deny | One application server to one database port |
| Internal network to DMZ | Deny | Administration over SSH or RDP from a jump host |
| DMZ to internet | Deny | Updates through a proxy, DNS to approved resolvers |
| Internal network to internet | Allow through proxy | Filtered web browsing |
Restricting outbound connections from the DMZ is often overlooked. A compromised web server that can open arbitrary connections to the internet can download tools and send stolen data out, so egress filtering is as important as ingress filtering.
DMZ architectures
Three designs are common, and they differ in cost, complexity and the number of independent barriers an attacker must cross.
| Design | Structure | Strength | Weakness |
|---|---|---|---|
| Three-legged firewall | One firewall with outside, inside and DMZ interfaces | Simple and inexpensive | Single device is a single point of failure |
| Dual firewall | Outer firewall to the DMZ, inner firewall to the LAN | Two independent layers | More hardware and rule sets to manage |
| Screened subnet with multiple zones | Separate DMZ segments per service class | Limits lateral movement within the DMZ | Higher design effort |
| Cloud DMZ | Public subnets with security groups and network ACLs | Elastic and automated | Easy to misconfigure with broad rules |
In a dual-firewall design, some organizations choose firewalls from two different vendors, so that a single software vulnerability cannot open both layers. The benefit is real but modest compared with the operational cost, and consistent rule review usually matters more.
What belongs in a DMZ
Only systems that must accept connections from outside belong in a DMZ, and each should hold as little sensitive data as possible. Data stores generally stay inside, reachable only through tightly defined application paths.
| Service | Recommended placement | Reason |
|---|---|---|
| Public web server or reverse proxy | DMZ | Accepts connections from anyone |
| Mail relay | DMZ | Receives mail from the internet and forwards it inward |
| Public authoritative DNS | DMZ or external provider | Answers queries from the internet |
| VPN gateway | DMZ or firewall edge | Terminates external tunnels |
| Customer database | Internal network | Contains sensitive data |
| Directory server | Internal network | Compromise would expose every account |
A common pattern places a reverse proxy in the DMZ in front of an application server that stays inside. The proxy terminates TLS and filters requests, so the internal application is never directly exposed to the internet.
DMZ compared with related security concepts
A DMZ is a specific form of network segmentation aimed at exposed services. Microsegmentation applies the same idea at a much finer level, often per workload, while zero trust network access removes the assumption that any network zone is trustworthy and authorizes each connection individually based on identity and device state.
Consumer routers use the term differently. Their DMZ host setting forwards every unsolicited inbound port to one internal device, which is not a separate segment at all. That device remains on the home network, so a compromise exposes everything else on it; forwarding only the needed ports is the safer choice.
In cloud environments the DMZ survives as a pattern rather than a box. Public subnets hold load balancers and gateways, while application and database tiers live in private subnets without public addresses. Security groups act as stateful per-instance firewalls and network ACLs as stateless subnet filters, so the same three questions apply: what may enter, what may leave, and which internal flows are truly required. Many organizations also move public entry points to a content delivery network or web application firewall, which shrinks the attack surface of the DMZ further but does not remove the need for strict rules behind it.
Common DMZ mistakes
- Broad DMZ-to-internal rules: allowing whole subnets or all ports turns the DMZ into a bridge rather than a buffer.
- Shared administration credentials: domain accounts used on DMZ servers let an attacker reach the internal directory.
- Flat DMZ: placing every public server in one segment lets one compromised host attack its neighbors.
- Unmonitored zone: without logging and intrusion detection, attacks inside the DMZ remain invisible.
- Stale rules: exceptions for retired services stay open for years unless rules are reviewed regularly.
Treating the DMZ as hostile territory is the most useful mindset. Servers there should be hardened, patched quickly, and administered from a dedicated jump host with separate credentials that are worthless elsewhere.
A non-technical view
Picture an office building with a public reception area. Visitors can enter the lobby, meet staff and drop off documents. They cannot walk into the offices behind it, because a locked door with a guard stands in the way.
A DMZ is that lobby for a computer network. Servers that the public must reach sit in the lobby, while everything valuable stays in the offices. If a troublemaker gets into the lobby, the locked door still protects the rest of the building.
A concrete example
A regional online retailer runs its shop on an application server and a customer database. Originally the web server sat on the same network as office computers and the database. The company redesigns the network with a dual-firewall DMZ: a reverse proxy and a mail relay move to the DMZ, while the application server and database move to a protected internal segment.
The inner firewall allows only HTTPS from the proxy to the application server on one port, and no connection at all from the DMZ to office computers. When an outdated plugin on the proxy is later exploited, the attacker gains a foothold there but cannot reach the database or office systems. The incident ends with one rebuilt server instead of a full breach.