The simple answer to the title is "yes". However, that is really not the exact question I am asking here. The question is really "are DMZ’s actually still DMZ’s?" Let me ’splain.
I had a client ask me the other day if I was seeing a drop in the use of DMZ’s out there. We had a quick discussion about it, but it got me to thinking more of the concept of a DMZ, the various implementations of DMZ’s (the point of this post is not to get into the security or various benefits of the different models, so I won’t discuss that or make any judgements on which is the best), the progression of the DMZ concept into the zone concept (and even a little further), and if the term DMZ is even really applicable anymore in the larger scope (or if it even matters).
Oh, and as a note, you might need to take some of my terminology with a grain of salt if you started your firewall experience with Checkpoint. I started out with Netscreen, so that affects the way I think about networks and DMZ, and zones. It all comes out in the wash since they are all doing the same thing, but just wanted to give a warning there. Also, be prepared for rambling as I flesh this out. It’s my style.
So anyway, to dig in a bit, let’s briefly define what a DMZ is and look at some of the more common implementations. The rationale behind a DMZ is to place externally accessible servers (such as HTTP, SMTP, etc) on a segment where potentially dangerous traffic can be isolated. Simply, you don’t want direct external access to your internal servers. Makes complete sense. So, how is this implemented?
Some people implement a DMZ by squashing a bunch of servers in between two firewalls like this:
The external firewall controls access from the Internet to your DMZ, and the internal firewall controls access from your DMZ to your internal network. Traffic may need to flow between your DMZ and internal network, but at least you can control that to a larger degree than just opening up the world to your servers as you must in the DMZ. This is physically identical to the military term DMZ, which is the space between two opposing army lines. Each army controls access to their side of the line.
But the original concept of a DMZ generally costs a bit more because of more hardware. So in comes the concept of using three interfaces. Basically, with a three interface box, you let the firewall become the single point where all inside and outside traffic flows, as seen below:
This gives you control in a single box, which keeps cost down. The DMZ is virtual in this case, since it is created and controlled by routing and policies, but the benefit is the same.
But many smart people outside and inside firewall manufacturers started looking at this at started saying, "Hey, why can’t we put even more interfaces on this?" Basically, they started allowing for more than one DMZ. So if you had some externally accessible boxes that you wanted to keep isolated from your internal network AND each other, this allowed you to do so without building more firewalls and adding complexity to your network design.
This was the precursor to the concept of zones, where you could create multiple areas where you wanted to segment off traffic with your firewall. So if you had multiple server farms, you could have a zone for each one. That is the point where I think the term DMZ becomes somewhat less effective, but it is still realistic if only used in the segmenting potentially dangerous traffic that is coming from the Internet. It is still not a DMZ in the physical sense (just like the three interface box), but it still serves the same purpose.
But what about those people who put a firewall between internal segments or between two nodes on their private WAN? As an example, if you work at ABCCorp and your company bought XYZCorp, you might put in a firewall between the companies when you setup a WAN link. In that case, you probably would rename zones to something more representative, like "ABCCorp_Network" and "XYZCorp_Network".
Here you are not really isolating traffic in the traditional sense in this case because you are creating a wall between the units. There is likely not an area where you have some isolated servers. You are simply controlling access between the two areas. So there is really no trusted or untrusted side (well, I guess that depends on which side of the firewall you are on and who implemented the firewall, but you know what I mean). This is more like the concept of a checkpoint in more modern urban warfare scenarios. There is no real DMZ, just checkpoints as you move from one hostile area to another. That doesn’t exactly fit since there are no distinctive lines in modern urban warfare, but I think there is a decent fit there. So the term DMZ does not fit.
Now you can go the next step by creating virtual firewalls, with each FW treated as a separate entity with its own policy set, routing table, etc. But that is generally used in more of a carrier type of environment or a very large enterprise that needs to maintain total separation between units. Though this setup can be utilized to perform the same function as a DMZ or a zone, it is generally too complicated for that.
But saying all of this makes me also come back to how I view many issues such as these, meaning what terms make sense or don’t make sense, which terms have been outdated, etc. Though I thoroughly believe that accuracy is needed when defining terms, I also think that in this case the term is not terribly important. I think the term is still very valid, even if the DMZ is virtual.
So basically, use the term if you want (aren’t you glad I gave you permission?) But I think "zone" is really more accurate in how most DMZ’s are implemented today, both in the hardware and in the actual production installs.
Vet
OK, so the Matasano people accidentally let everyone know what the DNS flaw was. I posted my thoughts on that at 
