Having a DNS can serve 2 purposes: Your client machines on the internal network need a DNS server to send their requests to, as they do not have direct access to the internet, secondly, you want outsiders to be able to resolve queries about YOUR domain.
However, having your own authoritative DNS for your own domain, requires that DNS to be registered with the hostmaster function in your country/TLD. This sometimes has a cost (at least in Denmark). Instead, it is possible to have your DNS hosted with your domain registrar, but you can also use one of the free services available. I am using GratisDNS (pages in danish) and ZoneEdit. It will make configuration of both DNS and firewall a lot simpler. This page will try to explain how to configure a DNS server relying on some other service's name servers being configured already.
This page explains how to configure the DNS service which is available on a Windows 2000 Server (it is not available on Windows 2000 Workstations). On my to-do list is to write a page on how to set up BIND.
In the DNS Manager, several things need to be set up correctly:
A forward lookup zone should be configured for the domain in question.
(In fact this is not mandatory, but it makes sense to have a local definition
after all, so that local queries does not need to be sent across the
internet.)
This can be done in two ways:
- Secondary zone, which simply downloads the zone information from the real
authoritative servers.
- Primary zone, which you have to configure.
This actually makes more sense in several ways, if you don't need to be a real
authoritative name server.
First of all, if you are using private ip addresses like 192.168.x.x, and have
a network card with such an address in the gateway, you would probably prefer
to give THIS address to the internal clients instead of the external address.
Besides having your own primary zone allows you to configure your internal
machines in the DNS as well, so that they too can be found through DNS from
the inside.
This is in fact faster than using NETBIOS names, which is what Windows will
try, if DNS fails.
Remember to specify the server itself as the (only) name server for the
domain in the DNS configuration itself.
You can even just allow dynamic updates (has to be done on both server and
client, but do NOT do this for the network adapter connected to the internet,
or it will make services.exe attempt to contact DNS servers too, as this is
done by the DHCP client service residing in services.exe), and you
don't have to configure the machines yourself (works on Windows 2000 and later
only) - but you must at least configure the name for the dns server you have
chosen, it cannot automatically register itself as it needs to find the dns
server first, and it is not registered yet...
Next, a reverse lookup zone should be defined. If you are using 192.168.x.x addresses as I am, the zone must be a primary zone named 168.192.in-addr.arpa or 0.168.192.in-addr.arpa depending. How this zone is otherwise set up really doesn't matter. You can allow dynamic updates, you can predefine your local servers, or whatever you like. This zone is simply created to avoid reverse lookups in your local network to be sent out on the internet. See Kent Crispin's quite good explanation on this topic.
You should also set the global server properties correctly:
Specify to listen only on the internal interface.
(This will be set in the firewall too later.)
You would also like to enable forwarders.
This is not mandatory, but it makes it easier to configure the firewall later,
if you also specify that the server should not use recursion.
(NOTE: Do NOT disable recursion altogether, on the Advanced page, just check
it on the Forwarders page, to require the forwarders to use recursion
instead of you.)
The forwarders will typically be the DNS servers offered by your ISP.
Now you can manually set the DNS servers on your TCP/IP protocol to be simply the local address (specified as the listening address in the DNS configuration). This means, that NO further applications need to be allowed to do port 53 traffic on the internet, they can all just use the local DNS server. This is quite good, as no applications will need to allow incoming UDP traffic from port 53. On your client machines on the internal network, the same DNS address should be specified. Just leave the second DNS entry blank.
In my firewall, I have allowed the DNS server (dns.exe or named.exe depending on the the dns server chosen) to perform UDP traffic in and out on the remote port 53, and outgoing TCP connections to port 53, but all this traffic is allowed on only a small number of DNS servers. (For this purpose I use the "Custom Address Group" feature in the firewall.) If you instructed the DNS server to use forwarders and to not use recursion, this list will be short and only contain trusted DNS servers. It will include the DNS servers at your ISP, and, if you have specified a secondary zone for your domain, transferring zone data from the authoritative DNS servers for your domain, these servers will be included too.
Of course, DNS.EXE should also be allowed to do UDP traffic to and from it's own port 53 on the internal network, otherwise your client machines will not be served. But DNS.EXE should NOT be allowed to accept any traffic to it's own port 53 from the internet. Since it is not going to be an authoritative name server for the domain, anyone should not be allowed to use it as their DNS. DNS.EXE should itself be configured to only listen on the internal network, but good deed cannot be done too often.
If using Bind instead, it should be considered more carefully, if it should be allowed to accept traffic to it's own port 53 from the internet. Bind can be set up as a primary DNS feeding the external DNS service server's as secondary yet authoritative DNS servers, so all configuration can be done locally and automatically propagated to the authoritative servers, and in this case it should be allowed to answer requests, both UDP and TCP to it's own port 53, from the authoritative name servers. Since it is not trivial to determine the exact set of name servers required to have access to your DNS, it is easier to simply allow general access, than it is to allow access for the authoritative servers only.
Sometimes a UDP response from a server will arrive too late, and the local port is already closed. When this happens, the firewall will typically log that a packet has arrived to a closed port. If you wish to avoid this "noise" in your firewall log, you can configure your firewall to simply disallow all UDP packages from port 53 in the custom address group. (This rule should of course appear AFTER the rule for DNS.EXE as it does indeed need to receive these packets.)
Last revised: 2008-03-08
·