10. DNS

Introduction

There are two possibilities to get the name resolution going on the clients. We could set up every client to use the name server of our service provider. This would mean that the firewall is configured in such a way that it allows dns traffic to pass. This is a valid approach, but has some disadvantages. When there are multiple clients some programs will sometimes query the dns server for a reverse lookup. It could then happen that they ask your ISP's name server something like "what is the name of the server with IP address 192.168.1.5", which is a computer on your local network. The DNS server does not know about this address, and will usually not respond.

DNSMasq

A better approach is to install a little program that forwards dns queries to your ISP but is intelligent enough to know about what IP addresses not to forward to your ISP. One such a program is dnsmasq. On top of it's functionality it also caches the responses for the clients, thus lowering the traffic to your outside network.

Installing it is a straightforward package install of the dnsmasq package. This will also remove bind, which is a full fledged dns server, but way over the top for our project.

Configuring DNSMasq

There is not much to configure about dnsmasq, but some things need to be done however.

First, we don't want dnsmasq to be listening on both network interfaces, it should only server our intranet, not the internet. So, we uncomment the line in the /etc/dnsmasq.conf file, so that it says interface=eth1.

So, how will this thing work? You get your nameservers from your ISP, in our setup via a DHCP client interface to the internet. This is handled by a DHCP client program called pump. This will update the nameserver list in /etc/resolv.conf and your computer can do name resolving of every address on the internet.

But, what we want is for this computer to also do name resolving for the intranet via de dnsmasq cache. So, what we need is a static entry in the /etc/resolv.conf file pointing to this computer, and this computer only. As a consequence, this setup conflicts with pump trying to change the /etc/resolv.conf file. What to do?

Actually, this situation is common and there is a solution for it in a little program called resolvconf. Installing it will make both pump and dnsmasq behave a little differently and update the /etc/resolv.conf file in a way that they cooperate instead of conflict.

So, installing this resolvconf package will do. Unfortunately, at the time of writing, installing this package was not easy because of a bug in the package, and the troubleshooting section of the Configuring the Package Manager section was written for this specific case. It's not that hard, but it's a bit of a stain on the carpet, I must admit. Go for it, though!

Afterwards, we can just start dnsmasq by typing the command /etc/init.d/dnsmasq start.

Firewall Configuration

All DNS traffic is running on port 53. You need to make sure that the firewall can connect to the nameservers of your ISP, so that dnsmasq can do it's lookups when a new request is served from the intranet or from the knoppixbox self. For the intranet to be able to connect to DNSMasq, you need to make sure there is a rule that allows connection from the intranet to the firewall on port 53 too. Mind you, DNS uses both TCP/IP and UDP to connect to a nameserver, so you should enable both. That should be all.

For clarity, here's the table for your firewall:
Action Source Destination Protocol Source ports Destination ports
Accept Firewall Zone Net TCP Any 53
Accept Firewall Zone Net UDP Any 53
Accept Zone Local Firewall TCP Any 53
Accept Zone Local Firewall UDP Any 53

line
Updated $LastChangedDate: 2004-11-05 23:24:59 +0100 (Fri, 05 Nov 2004) $
line
Kristof Van Landschoot
Author

line
Summary: When using a Masquerading firewall for you local network, it is handy to have a DNS cache around, so that at least all the local computers are known to each other by name.
line
Copyright 2003-2004 Coin-C bvba. Questions, Comments, Corrections? Email knoppix@coin-c.com.