DNS Forwarding in Kerio Control


2013/07/04

Let's start with the basics: during your initial setup Kerio Control, you'll probably either plug in your ISP's DNS server or some public DNS like Goggle's 8.8.8.8 and 8.8.4.4. That's the simplest possible case and will let you resolve Internet host names so that you can type "facebook.com" into your browser rather than memorizing an IP address.

DNS also serves to resolve in the other direction: should some outside person access something inside our network, DNS will be called upon with a "reverse lookup" so that we have something more than an IP address to go by if we want to know who they are.

You may need more than that. You may want to also resolve internal machines and you may or may not already have a DNS server (perhaps a Microsoft or Apple Domain Controller) that provides that function. If you do have another DNS server, you'll need to figure out how Control and that server can work together.

To show you that, let's take a look at a fictional setup. It's a real Kerio Control firewall, but it's not actually connected to anything: it's just running in VMWare on my Mac. The first thing I did was set the Internet interface to use Google's servers for DNS.

Setting DNS servers

By the way, when you put more than one DNS server here, you are NOT specifying preference by the order you put them in. That's easy to forget - I forget that myself frequently. Control will pick one or the other, but not necessarily in the order you put them in. This can cause great confusion if you don't know that.

I can now resolve Internet host names:

$ dig +short @192.168.11.93 mail.aplawrence.com
96.126.98.231
 

The "@192.168.11.93" tells dig to ask that Control firewall rather than my real firewall. If I wanted to, I could send things through this "fake" firewall by telling my browser to use it as a proxy. I might do that to test certain rules, but for what we are doing today, "dig @" is enough.

Google's servers know nothing about my local machines, of course. If I want the firewall and therefore the people who use it to be able to resolve internal machine names, I could just add them to Control's Hosts file.

entries in hosts file

Notice that "foobar.example.com" is at 10.14.3.2. Obviously that's not on the same LAN as the firewall (it's on 192.168.11.0) - perhaps it is a machine on the other side of a VPN tunnel? Whatever you need, you can put it in here and Control will look here first, before it tries the Internet name servers.

$ dig +short @192.168.11.93 foobar.example.com
10.14.3.2
 

But we may very well have a machine that does know about other local machines. It may or may not know about that "foobar.example.com", but it does know about other local example.com machines. We can tell Control to ask it when appropriate:

Forward example.com to local DNS

I don't have any such server on my network (there are only two of us here, so we don't need it). To simulate a local DNS server I used this DNS server Perl code. With that, I can ask Control about "foo.example.com" (not "foobar", but "foo") and get an answer that actually comes from that Perl code.

$ dig +short @192.168.11.93 foo.example.com
10.1.2.3
 

That code only knows about "foo.example.com", by the way. You also need to understand that the hosts table gets looked at first. If I add "foo.example.com" there, that's the IP I'll get.

$ dig +short @192.168.11.93 foo.example.com
192.168.11.4
 

OK, that's all good. What happens when we ask about a machine nobody knows about?

Server doesn't know FOOWHO

$ dig +short @192.168.11.93 foowho.example.com
$ 
 

In this case, we get an instant response. After checking Hosts, the query was forwarded to my fake local DNS server, but that simply returned nothing - it doesn't know. Control won't ask the Internet servers because it has been told that my fake DNS server will handle example.com.

If we wanted that query to go to the Internet, we could exclude "foowho" from forwarding.

Exclude FOOWHO from forwarding

Excluding FOOWHO from forwarding, server isn't asked

$ dig +short @192.168.11.93 foowho.example.com
$
 

Because there is no "foowho.example.com" that Google's servers know of, our query fails.

There actually is a "www.example.com", though. If I leave things as shown here, that lookup would fail, because my fake dns server know nothing about that. However, if I add that to be excluded from forwarding just like "foowho", Google's servers will resolve it:

$ dig +short @192.168.11.93 www.example.com
192.0.43.10
 

There's one more thing I should do, though. If that bit of Perl code were actually a DNS server, I'd want to specify the reverse loookup, too:

Missing reverse lookups

With that, everything should now work perfectly. If you want to experiment with these sorts of things, remember to hit the "Clear Cache" button after each change; reqursts will be filled from cache before anything else.



Got something to add? Send me email.





(OLDER) <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> DNS Forwarding in Kerio Control




Increase ad revenue 50-250% with Ezoic


More Articles by

Find me on Google+

© Anthony Lawrence



Kerio Connect Mailserver

Kerio Samepage

Kerio Control Firewall

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us





Educate the children and it won't be necessary to punish the men. (Pythagoras)

We are questioning more than the philosophy behind our dependence upon limited and limiting systems. We question the power structures that have grown up around such systems (Frank Herbert).








This post tagged: