BIND: a DNS server

BIND is an excellent, high quality DNS server. Its configuration is complex though.

Documentation Resources

I've found the official documentation not very useful or clear. The following links are better:

• Setup a DNS server with BIND (Gentoo Wiki)
• DNS for Rocket Scientists, excellent documentation

There is also a book by Apress, Pro DNS and BIND, that can be useful.

General DNS facts

• There is no DNS cache on Linux at the OS level (libc *might* cache stuff).
• A good explanation of the general DNS system.

Using dig

• The dig tool (in net-dns/bind-tools) allows you to perform a lookup, but will not perform a full traversal of the DNS system. Have a look at this online tool to do this.
• You can use dig@server to force dig to ask a specific server. This is useful to see if the problem comes from your own BIND server or lies elsewhere.
• When using dig, the number next to the answers represent the number of seconds left until the given server will refresh his cache. It's very important if you changed some settings and are testing with dig to see if changes are applied.

Basics

• There is a main configuration file (/etc/bind/named.conf) that references zones for which the DNS daemon assumes responsibility. I think it is important to first understand what types of services a DNS server can perform: primary, secondary, cache, forward.

• There is a separate file for each such zone, that actually contains the record entries.

• named-checkzone is a very useful program that will check the syntax of a zone file and detect many errors. named-checkconf -z is probably an alias to this tool.

Setup

• On a DNS server that should be accessible from the public Internet, port 53 must be open, both TCP and UDP.

• If named won't start from the Gentoo init script, emerge syslog-ng and look at /var/log/messages.

• Be careful that zone files must be readable from the "named" user. If read permission is not available for a given zone file, it will just ignore it (again, looking at the logs is very useful to debug this kind of problems).

DNS name servers on OVH

• If you want to use a name server that has an address within the zone for which it is responsible, you must create a GLUE record. However, you can create the record only while the server IP can be resolved! To avoid this chicken and egg problem, you should usually use another name server to temporarily resolve the IP, before creating the GLUE record and changing the name servers to the correct ones after it is done.

Configuration

• Using a * wildcard is possible, although not recommended.
• NS records establish which servers are authoritative. SOA records define the "start" of authority, eg which servers among all authoritative ones is the master / canonical source of data. This is used mainly for zone transfers, slave servers etc.

Zone File

• The TTL (first directive on a zone file) represents the Time-To-Live of all records in the zone. You can override the TTL for a specific record. This value is in time units (s for seconds, h for hours, d for days, w for weeks). It should generally be quite high (like 1w) but when a change is planned this should be reduced to 2hours, and then moved back to the normal value.
• The TTL is distinct from the other values like Serial, Refresh, Expire etc. I think (not sure yet) that these values are used for the secondary (or caching) DNS server.
• The SOA (Start of Authority) records are at the top of the zone file.
• A comment (inactive line) on the zone file begins with a ";" (semi-colon).
• The @ symbol in the zone file is a shortcut for the name of the zone (eg, domain.com or elvanor.net).
• A name ending with a "." (dot) is considered a fully qualified name. If it does not end with a dot, it is assumed to end with the ORIGIN value for the zone. So be careful; if your CNAME records reference a hostname in another domain, the "." at the end is mandatory.

Setting an association for the domain name (without any hostname)

• If you own elvanor.net and want that this domain be linked to an A record, just enter in the zone file:

elvanor.net IN	A 213.251.168.141

• You could also use @ which will expand to the zone name: @ IN A 213.251.168.141

• Warning: you cannot use a CNAME record for this purpose. Indeed the zone file becomes corrupted with a line like @ IN CNAME valinor.

MX records

• It seems MX records must be the first in the zone file (before A records). Also there should be a name in the value of the MX record, not an IP address. Of course, the same short name should be the object of an A record.

Logging

• BIND can use the syslog daemon. A minimal configuration that will log everything to syslog:

logging 
{
        category default 
        {
                default_syslog;
        };
        category queries
        {
                default_syslog;
        };
};

DNS Round Robin

• DNS round robin is pretty easy to setup on BIND. Note that the DNS server returns the full array of IPs for a given host; after it is up to the client to make a choice. Consider client behavior undefined. Some programs such as wget will try a different IP than the first on failure, but this behavior is really client dependent.
• It does not seem possible to setup DNS round robin with CNAMEs.

Limitations

• If you have a zone file for named, you claim authority for it in full. You cannot have answers only for some given hosts and forward the requests to another DNS server if there is a request for a hostname not present on your zone file.