|STDI Consulting Inc.|
Mississauga Ontario, Canada
|First published on December 14, 2005 |
Last revised on May 16, 2011
|BIND 9.3.1 by Internet Systems Consortium Inc.|
DNS Whitelist installation example for Windows 2000 Pro
NOTE: Revision(s) at bottom of document
This document is out of date, but the principle does still apply. I guess I leave it here for my own benefit when I finally get to install the Blacklist on my centOS system.
Whitelist (or Blacklist) DNS setup
This document explains the steps to setup a Whitelist DNS server that will run with the Domino R7 DNS Whitelist option. Please keep in mind that this is not intended for a high volume public Whitelist DNS server. Performance is less of an issue, but we don't cover security in much detail.
Before we go any further, you may want to review some of the DNS related expressions in the DNS Dictionary.
Verify Windows setup
Before we start the installation, we need to verify that the network is correctly configured on both servers, the new Whitelist DNS server and the Domino server.
Verify primary domain: If the host name is myDNS and the domain is stdi.com, then the DNS should resolve both the full name myDNS.stdi.com and the shortname myDNS. One way to check is with the ping utility. Open a DOS Command box and type ping myDNS (or whatever your host name is). You should get a ping statistics including the IP address. The myDNS should have been expanded to myDNS.stdi.com. You may want to check some other hosts in your domain as well. The ping utility may not always work, this depends on the gateway and firewall setup. Some Network Administrators block the ping command. If ping doesn't work, use the tracert command.
Whitelist DNS setup
We have three options:
The following examples show the option 3 configuration. The first (or existing DNS) is assumed to be a Microsoft DNS Server and the new DNS server will be a BIND DNS.
- Add the white list entries to the existing zonefile.
- Create a subdomain with it's own zone file on the existing DNS.
- Create a subdomain and run the whitelist DNS on a different server.
How does a Whitelist DNS differ from your DNS?
Technically they are the same. The purpose of a Whitelist DNS is to resolve a name into an IP address, that is a forward lookup. We use an A Type (address type) record to configure a forward lookup. The difference for the whitelist entries is the format of the name. We are all familiar with the host name such as mydns.stdi.com that will resolve in an IP address such as 192.168.1.200. This works fine because we know the name of the host and need to lookup the IP address.
In the case of an SMTP connection, we don't know the host name, but we have the connecting IP address. We can make use of the reverse lookup logic that uses the IP address in reversed order, but then we append the Whitelist name and we get a really long name.
Example: We have to check if the server on IP address 188.8.131.52 is in our Whitelist DNS with the name whitelist.myDNS.stdi.com
1. reverse the IP Address > 184.108.40.206
2. append the Whitelist name > 220.127.116.11.whitelist.mydns.stdi.com
and we get a perfect name with lots of subdomains. Blacklists and Whitelists DNS work the same way, the difference is in the resulting process. A positive Blacklist call can result in a rejection, a positive Whitelist call can result in a unconditional accept. Now we know that a DNS can be used for normal lookups as well as Blacklist and Whitelist lookups.
The result of a Whitelist or Blacklist call is not a corresponding IP address, but just any IP address. In most cases, a Blacklist call returns a 127.0.0.1 address. The point is, if we get an IP address back, the entry was found in the Whitelist (or Blacklist). If we get an error, the entry was not found.
Download and Install Software
This documentation refers to the DNS published by the Internet Systems Consortium Inc. (ISC). The DNS product name is BIND (Berkeley Internet Name Domain) and provides an openly redistributable reference implementation of the major components of the Domain Name System. BIND is available at no charge under the BSD License. Product and copyright information, visit Internet Systems Consortium and follow the >Download >DNS menu options.
You have now all the applications, but no configuration and a faulty access permission. When you try to start ISC Bind, you will get an error. The install process added the process to the Services with Startup type = Automatic.
- Download and unzip the software into a temporary folder
- Execute BINDInstall.exe which will launch the product installation - Accept the default values.
This is what happened in the install: The Installation process added a new user called 'named' and added a task in Services. The user is added, but no permission is assigned. When you try to start BIND later, you will get an [Error 1067] which is caused by lack of permission. Before we dig into the files, lets setup the permission.
Now we have the access permission out of the way. In a nutshell, we added a password to the user profile of named and added the same password in the Services that starts the DNS task. Keep in mind that we granted way too much permission for the DNS task. We urge you to protect the server by other means.
- In the Control Panel > Users and Passwords, select the user named and click on 'Set Password'.
- Click on the 'Group Membership' tab and change permission to 'Standard user'. Save and exit.
- In the Control Panel > Administrative Tools > Services, select the 'ISC BIND' and open the Properties
- Set the same Password as in step 1 above. Save and exit.
We need to create several configuration files for the myDNS.stdi.com Whitelist DNS. This is a stand-alone, master only configuration.
And we need to update the existing DNS by delegating a subdomain.
The DNS expects the configuration files in the etc folder.
|The default installation created a folder called dns in \windows\system32 with two subfolders, the bin for the programs and the etc for the files.|
Also included are several utilities. We will use the named-checkconf and the named-checkzone after creating the files. Running the utilities saves a lot of time when looking for syntax errors on the text files.
And then there is the file names. Some documentation suggests file names that work well on Unix systems. A zone file to use one example, is called stdi.com because it defines the stdi.com domain. Windows automatically assumes that a .com extenstion is an executable. To make it somewhat easier, I'm changing all the file extensions to .dns, the same extension as the Microsoft DNS Server uses.
named.root (or root.dns)
This file defines the top level domains. This file may not be required in all cases, but we include it anyway.
> named.root setup
Defines file locations and sets the DNS mode.
> named.conf setup
You will have several zone files. The number depends on your network.
> zone file setup
Delegating a subdomain
We have to add the mydns.stdi.com subdomain to the stdi.com domain on the Microsoft DNS server.
> delegation setup
Ready for a test?
Ok, keep one thing in mind, DNS server cache information. This is a good thing, unless you need to reconfigure something. Your workstation where you test the DNS my use a DNS that cached zone file information. In most cases, we have a TTL (time to live) of several hours and the server will not refresh the cache until the time elapsed. Not much we can do except restart the DNS or refresh the cache.
The fastest test is always the ping utility. If ping can resolve a host name correctly, we know that the DNS works fine. Testing a Whitelist entry works the same way, just the result is different. Lets say we have 18.104.22.168 in whitelist.mydns.stdi.com.
> ping 22.214.171.124.whitelist.mydns.stdi.com
< Pinging 126.96.36.199.whitelist.mydns.stdi.com [127.0.0.1] with 32 bytes of data:
The responses are not important, the Request timed out or Reply from 127.0.0.1: bytes=32 time=2ns TTL=128 are meaningless for whitelist operation.
But it is important that the ping utility can resolve the name into an IP address (see above). Now we know that the local workstation (or server) from where we just tested can correctly resolve the whitelist DNS queries. This logic is not limited to only your own whitelist, you can test any public blacklist the same way.
Configure the Domino Server
There is one thing we need to change, the Configuration Settings document for the SMTP server.
In the > Router/SMPT > Restrictions and Controls... > SMTP Inbound Controls
Enable the DNS Whitelist Filter
Add the Whitelist Site name
Select the desired action
Then save the changes and we're done.
That's all there is for the configuration.
Revision May 2011
The current version of BIND is now 9.8
Based on the countless hits to this page, I hope to find the time for an update to this documentation. At the same time, I have to get BIND running on one of my Linux boxes.
If you need to know all the nooks and crannies of BIND or DNS, get DNS and BIND from Paul Albitz & Cricket Liu, published by O'Reilly. You get over 500 pages of excellent information.
I'm currently updating the SUSE firewall to run the DHCP and DNS on the same box. With portable devices on the Wifi, there is almost no way to keep avoiding a DHCP.
The documentation for DHCP and DNS is here Linux Firewall