Monday, 9 February 2015

DNS on the DMZ

Servers on the inside of my network have IPs like 10.x.y.z, but servers in my DMZ have IPs like 192.168.y.z. So when I want to talk to a server "fred", then the IP address I need to use, depends on whether I'm calling fred from inside, or from the dmz.

The pix has a clever way of dealing with this. I think. It's so clever, I don't have a hope in hell of understanding it. It does "DNS doctoring", and it looks ... difficult. But I already know how to set up a DNS server, so I decided to do it that way.

Now, I have two DNS servers; the one that people on the outside use, that translates my accessible server names into accessible IP addresses. And I have another DNS server on the inside, that translates my internal names into IP addresses. So I don't have to remember that fred is at

Another way to do this, is with a hosts file. But the trouble with that, is that you need a copy of the hosts file on every computer that's going to talk to other computers, and keeping that up to date is a nightmare - I know this, because that's what I did before I got the hang of DNS.

But in future, I'll need three DNS servers. One for people on the outside, so that names like "" are translated into IP addresses that you can access. The second is the same inside one I already have; the third will be another one for use by servers sitting on the DMZ, because they'll use a different address for servers on the inside, from the addresses that insiders use.

I hope that's clear. It wasn't very clear to me. And I made a lot of blunders while setting it up.

First, I found that pinging from the DMZ to the outside worked ... but very slowly. Ping times were good, but I was only seeing one ping every 20 seconds, instead of the one per second you should see. Eventually, I realised that if I used ping -n instead of ping, the pings came one per second. -n tells it not to translate ip addresses back into names, and the reason what that was so much faster than without the -n, was that I'd forgotten to do reverse DNS. I hadn't actually forgotten, I was planning to do it later, because unless you have accurate reverse DNS, AOL (and some other companies) won't accept your email. But I hadn't planned on doing it just yet. Well, it's easy to do, so I did it.

By the way, if you think that you might be having reverse DNS problems, you can test whether yours is working, go here.  Or here.

So after I got reverse DNS working, pings went quickly. But then I did a bit more editing of the DNS files that resulted in DNS not working, and it took me ages to realise that the "SERVFAIL" message I kept getting from dig, was because, although the DNS server was working, it wasn't working for the domain name that I was testing.

The cause was a hole I I have tripped over so many times. If you want to put a comment in your zone file (or comment out one of the lines) you start the line with a semicolon. For most of the things I use, that would be an octothorpe (#). If you put an octothorpe as the first character in a line of a zone file, then the DNS server (bind9) barfs on that file, and although bind9 will still run, it won't be doing anything for the domain with the octothorpe. I've made that mistake so many times, you'd think I'd have learned by now.

So I fixed that, and then I ran my regression test, that I set up a few days ago. That checks that all the things that should be allowed, are allowed, and all the things that should be denied, are denied. And that worked well. So I think I've got my three DNS servers working; inside, dmz and outside. Except, of course, that I can't make any of this stuff active until my line arrives, which might be in April. But definitely before Christmas. Definitely.

No comments:

Post a Comment