[#bind]:

Internet Systems Consortium (“ISC”)'s Berkeley Internet Name Daemon (“BIND”)

BIND is a very old name server. The DNS zone files used by BIND have become fairly well known.

Many technicians do not pronounce the name of this executable like the word “named” (the past tense of the verb “name”, but rather as “name dee”. This is done to intentionally reflect that the executable provides the “name” lookup service, and that the executable is a “daemon”/server.

Configuration file(s)

Different operating systems may store these in different locations by default. OpenBSD uses /var/named/etc/.

Main configuration file: named.conf

Start by performing any appropriate backups. For instance, if backing up files with common copying/archiving tools is a method that has been set up, this may be as simpel as running:

cpytobak /var/named/etc/named.conf

Figure out which IP addresses are assigned to the NICs on the machine that will be running the DNS server. (The link-local IPv6 addresses may not be needed, assuming that they are not the only IPv6 addresses on the machine, as long as it is accepted that other machines will not be using IPv6 addresses or, more likely, that other machines may use other IPv6 addresses that the DNS server has.)

If certain sections described in the following examples don't pre-exist in the named.conf file, feel free to create them as needed.

[#bindacl]: BIND Access Control Lists

The following text defines three ACLs.

acl clients {
localnets;
::1;
// 192.0.2.0/24;
};

acl ietfbcp5 {
192.168/16;
172.16/12;
10/8;
};

acl ipv6priv {
fd00::/8;
fe80::/10;
};

Simple steps to do
  • Understand that when a double-slash (“//)” is found, the rest of the line is considered to be “comment” and has no effect.
  • Also understand that the term localnets refers to any subnet that is part of a NIC configuration on the local machine. BIND will look on the local machine, determine what NICs exist, determine the IP address of every such NIC, determine the prefix length (a.k.a. “subnet mask”/netmask) that is used with that IP address, and use this information to generate a list of all subnets that are supported by the local NICs on the machine. (This term, “localnets”, is a pre-defined BIND ACL. (See pre-defined BIND ACL (BIND 9.10 documentation); the previously-used references to BIND 9.5 Administrator Reference Manual: ACL section have been updated, as the 9.5 documentation doesn't seem to be available at the old official location.) )
  • In the first acl block, which is named “clients”,, add any subnets that are used by local/internal/private networks, but which are not subnets that BIND will be directly listening to.

    For example, if there is a local network that is connected via Wi-Fi, and the Wi-Fi connections use a different subnet from the wired network, and the NIC running BIND is only configured to listen to one subnet (probably the wired network), then BIND will likely treat the Wi-Fi connections as an outside/external/public/less-trusted network. If the Wi-Fi connection should be treated as local/internal network, then the Wi-Fi subnet should probably be added to the list of client networks.

  • Add the other ACLs that are shown: ietfbcp5 and ipv6priv. These likely do NOT need to be changed/customized at all, and will be useful later.
Further discussion about this configuration text

Technically, the phrase “clients” is the name of an ACL, and so may be customizable. However, it is a known/recognized name, so there may be some benefit to leaving that name standardized/uncustomized. The idea is that the ACL named clients identifies which networks are part of the “local” network.

The phrase “localnets” refers to a pre-defined BIND ACL. This is documented by the pre-defined BIND ACL (BIND 9.10 documentation), but the simple description is that “localnets” will equate to all subnets that are used by any NIC on the local machine.

The “ 192.0.2.0/24; ” line refers to the example subnet used for documentation, so clearly it is meant to be customized if used. Actually, specifying a subnet like that may not be needed in some cases, as the “localnets” ACL is a reference to some, and possibly all interesting/needed, subnets. If an extra subnet is included, as demonstrated in the documentation, then this explicitly mentioned subnet is identified as being part of the ACL. The example shown is for a subnet that is a local local network, even if none of the NICs on the server has an address assigned to this subnet. However, although the subnet is not used by any of the addresses assigned to any of the NICs on this server, the subnet still belongs to the ACL.

A further, specific example may help to explain this better. If the DNS server is only physically connected to a wired LAN network, and there is also a wireless network, then the subnet of the wireless network could be explicitly added/defined in this configuration file. Through the technology of network traffic “routing”, DNS requests routed from this extra network may reach the DNS server, even though the DNS server does not have an IP address in that subnet.

[#bindopts]: Options

e.g.:

options {
include "etc/named.opt";
version "";

listen-on { localhost; };
listen-on-v6 { localhost; };

enable-zones-enable yes;

allow-recursion { clients; ietfbcp5; ipv6priv; };
};

The “empty-zones-enable yes;” likely pre-exists with newer versions of BIND. If using an older version of BIND that did not have that line by default, perhaps just leave that line off.

The phrase “localhost;” here refers to the pre-defined BIND ACL (BIND 9.10 documentation), and refers to all IP addresses that are assigned to any of the NICs on the local computer. (So, this is NOT simply a reference to the commonly-familiar DNS name of localhost which only points to loopback interfaces. This is a BIND-specific term that points to additional, different IP address(es) as well.)

Parts of that may be customized: the parts within the curly braces for the listen-on sections (in the above example, this refers to the phrase “localhost;”) may be replaced with an IP address followed by a semi-colon, or more than one IP address with a semi-colon after each IP address. (Another option is a pre-defined pre-defined BIND ACL (BIND 9.10 documentation) such as “any” which may, in fact, be the default value. Any such ACL should, like an IP address, be followed by a semi-colon.) Note that the reference to the etc/ subdirectory is relative to the DNS server's main configuraiton directory. That may be the parent directory (..) compared to where the named.conf file is stored. This specified directory may be (more specifically, it probably is) quite different than the /etc/ directory.

Using Split-horizon in BIND

It is also possible to have some zone(s) which are visible to the local LAN, but which are not shared to the public Internet.

(This is some old text, probably generalized (not BIND-specific) Split-Horizon is the concept of different records being provided based on what system is asking for this. (Split-Horizon is not limited to DNS, although it may be the most famous example. For example, one or more routing protocols may commonly use split horizon. As an example of how this is useful, internal machines may be pointed to an internal IPv4 address since an organization's external addresses may not really be used internally, and especially external addresses may not be the most efficient addresses to use (if the traffic would need to route to certain equipment that interacts with addresses from an external network, possibly to be then translated to an internal address and forwarded to that). Of course, private internal addresses like those in the ranges described by RFC 1918 may be essentially useless for legitimate external users (although the availability of information about such addresses may provide information to someone trying to gather information about the internal network, such as an attacker who has no legitimate need).

(This is still part of the documentation about editing the /var/named/etc/named.conf file.)

The private domain(s)

In the /var/named/etc/named.conf file, locate where the file starts talking about zones. In a default file, this will likely start with a comment that says “// Standard zones”. Either directly before this comment, or directly after this comment (whichever makes the most sense), add the following lines:

view "onlyint" {
match-clients { ietfbcp5; ipv6priv; };

Note that the view's curly brace is intentionally left unclosed; it will be closed as part of some of the following example text.

Things to customize: The reference to ietfbcp5 is a reference to an ACL. That needs to be defined elsewhere (and possibly must be defined earlier) in the file, in the section that creates the ACLs.

Put that text just above the default private domains. Ideally the default private domains should be indented, since they are now becoming part of a view. However, they may not end up being pre-indented. Simply making things fuctional does not have a strict technical requirement for indenting (particularly if in a rush to get this set up so that downtime may cease)). If the goal is to make the finest-looking configuration file that is easiest to understand, then indent all of the zones, because the zones are now part of the view configuration block.

The following may be some private domain data already found in the file. Place the start of the view above such lines.


// Standard zones
//

zone "." {
type hint;
file "etc/root.hint";
};

zone "localhost" {
type master;
file "standard/localhost";
allow-transfer { localhost; }";
};

zone "127.in-addr.arpa" {
type master;
file "standard/loopback";
allow-transfer { localhost; }";
};

zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
type master;
file "standard/loopback6.arpa";
allow-transfer { localhost; }";
};


(Note: There may be some more zones defined after that. Make sure to end the view after the private zones, but before any public zones.)

After the pre-defined private zones, insert the following lines. These lines point to a custom configuration file that allows for private domains, and then ends the section for private views.

include "etc/prvzones.cnf";

}; // end of view "onlyint"

Public view

Surround any existing default/demonstration zones with a world view. In the following example, the default named.conf did not have any public zones, although it did have some comments for public zones. So, those got placed into a newly-created world view.

view "worldview" {
match-clients { any; };

// Master zones
//
//zone "myzone.net" {
// type master;
// file "master/myzone.net";
//};

// Slave zones
//
//zone "otherzone.net" {
// type slave;
// file "slave/otherzone.net";
// masters { 192.0.2.1; [...;] };
//};

include "etc/pubzones.cnf";

} // end view "worldview"

Note that the references to the etc/ subdirectory is relative to the DNS server's main configuraiton directory. That may be the parent directory (..) compared to where the named.conf file is stored. This specified etc/ subdirectory may be (more clearly: probably is) a location that is different than the /etc/ directory. Confusing those directory locations can lead to things breaking, so understand that these are directories with the same name, but they have different locations and so they are different directories.

Similarly, master/ is a subdirectory of the DNS server's main configuration directory. (The line that says “type master;” is really referring to a type, not a subdirectory. The default subdirectory for this type of data is named after this type.)

Things to customize: the domain names, and reference to any filenames in the master/ subdirectory.

Options file

If the named.conf file makes a reference to an options file, make sure that options exists! (For example, if the “options {” block of configuration options has a reference to “include "etc/named.opt";” then make sure that etc/named.opt exists.

Setting up forwarders can allow internal machines to get information about external domains.

(Research may be needed to find out: how many DNS forwarders may we have?)

forwarders { 198.51.100.3; 203.0.113.4; 8.8.8.8; };

// Don't contact the root nameservers if the forwarders are unresponsive:
//forward only;

(Two of those sample addresses come from addresses reserved for documentation; the hyperlinks provide more details. Those addresses should be customized, and should not be used (uncustomized) as shown. The 8.8.8.8 is one of the public DNS Servers for clients to use.)

Files stating where there is zone data

In the example named.conf file shown, the references to the zones data is stored in separate configuration files (called etc/pubzones.cnf for the file with details about the public zones, and etc/prvzones.cnf for the file with details about private/internal zones.)

There is no compelling reason why this data absolutely must go into a separate file: the zone details could be included in the main named.conf file. One reason to separate things is to somehow limit access to the file that contains zone data, to make it less likely that a person/process may accidentally write to the wrong part of the main configuration file. (As this zone data is included, and the file could in theory have details other than zone data, this isn't being done primarily for security.) This method also places details of public zones into a separate file from private zones, which may decrease the likelihood of someone placing a zone into the wrong view because the person accidentally placed zone data into the wrong section of a file.

If the main configuration file does reference these filenames, then those filenames must exist! If getting a nameserver up and operational (perhaps just recursively serving domain names) is something to be done immediatley, then the filenames don't need to have functional content: they may have only white space. Then the details for domains may be added at a later time.

Here are some example contents of the filenames, which do start to specify a small amount of details for supported domains. (The domain names and the filenames will need to be customized as appropriate.)

Public Zones configuration file

Here is an example of contents for a custom file named /var/named/etc/pubzones.cnf (which may not pre-exist). Note that this file may not have any impact if it is used, and it is not used by default. The example configuration shown above, however, does make a reference to this file so that this file will be used.

zone "example.com" {
type master;
file "master/examplec";
};

zone "example.org" {
type master;
file "master/exampleo";
};

zone "example.net" {
type master;
file "master/examplen";
};

zone "sample.example" {
type master;
file "master/sampleex";
};

The recommended way to make this file is to have a tab at the beginning of each line. This way, if someone decides to make a change to the style of configuration files, and decides to put this data directly into the named.conf file, then this data can be placed directly into that file without requiring re-tabbing.

Internal/private zone file

Here is an example of contents for a custom file named /var/named/etc/prvzones.cnf (which may not pre-exist). Note that this file may not have any impact if it is used, and it is not used by default. The example configuration shown above, however, does make a reference to this file so that this file will be used.

; Private zones

zone "privdomain" {
type master;
file "master/internal/prvdom";
};

zone "yay" {
type master;
file "master/internal/yay";
};


; Private versions of the public names
zone "example.com" {
type master;
file "master/internal/iexamplc";
};

zone "example.org" {
type master;
file "master/internal/iexamplo";
};

zone "example.net" {
type master;
file "master/internal/iexampln";
};

zone "sample.example" {
type master;
file "master/internal/isampexa";
};

[#bndzonfl]: Zone files (for BIND)

The zone file format used by BIND is considered to be a standard in the industry. Some example zone data is shown by RFC 1034 (“Domain names - concepts and facilities”) Section 6.1: Example configuration used by the C.ISI.EDU name server and RFC 1035 section 5.3. (Following text also shows example configuration data.)

It makes sense to have the configuration file(s) of any private domain(s) in a separate directory than where the location used for the configuration of publicly-visible domains.

cd ../etc/../master && mkdir ../master/internal
cd ..

Some zone files do exist in standard/. They are for widely recognized domain names that are reserved for specific purposes, but might be rather sufficient to copy.

Example of a zone master file:

; 234567890123456789012345678901234567890123456789012345678901234567890123456789
; Adapted from: $OpenBSD: db.localhost,v 1.2 2005/02/07 06:08:10 david Exp $

$ORIGIN example.com. ;Optional Comment
$TTL 6h

@ IN SOA ( ; Parenthesis make lines become like just 1
@ ; ...
hostmaster.example.com. ; E-Mail w/ @ replaced
; timers:
0 ; serial
1h ; refresh
30m ; retry
7d ; expiration
1h ) ; minimum
NS ns ; Nameserver
NS a.ns ; Nameserver
NS ns1 ; Nameserver
NS b.ns ; Nameserver
NS ns2 ; Nameserver
AAAA 2001:db8::1 ; Primary Nameserver's IPv6
A 192.0.2.1 ; Primary Nameserver's IPv4
MX 100 mail ; Points to a system with AAAA/A record(s)
ns AAAA fec0:0:0:ffff::1 ; Primary Nameserver's IPv6
AAAA fec0:0:0:ffff::2 ; Primary Nameserver's IPv6
AAAA fec0:0:0:ffff::3 ; Primary Nameserver's IPv6
A 192.0.2.4 ; Primary Nameserver's IPv4
a.ns AAAA fec0:0:0:ffff::1 ; Primary Nameserver's IPv6
A 192.0.2.4 ; Primary Nameserver's IPv4
ns1 AAAA fec0:0:0:ffff::1 ; Primary Nameserver's IPv6
A 192.0.2.4 ; Primary Nameserver's IPv4
b.ns AAAA fec0:0:0:ffff::2 ; Secondary Nameserver's IPv6
A 198.51.100.5 ; Secondary Nameserver's IPv4
ns2 AAAA fec0:0:0:ffff::2 ; Secondary Nameserver's IPv6
A 198.51.100.5 ; Secondary Nameserver's IPv4
mail AAAA 2001:db8::25 ; Primary Nameserver's IPv6
A 192.0.2.25 ; Primary Nameserver's IPv4
smtp CNAME mail ; Multi names for easy future split
www CNAME @ ; Web server might be the same machine
ipv6 AAAA 2001:db8::1 ; IPv6-only
www.ipv6 CNAME www.ipv6 ; IPv6-only
  • Note: the periods at the end of refernces to domain name(s) are significant. Don't try to chop them off. (e.g.: Royal Pingdom's report of .se TLD being offline for about an hour in October, 2009: The entire domain that uses Sweden's country code stopped working right.)
  • Be careful with white space; it can matter and affect things. Make sure that the system names are at the start of lines; do not permit white space before the system name. For example, a line could start with “www”, but should not start with “ www”.

    HBruijn's comment to kubanczyk's answer to Renold's ServerFault.com question “Reverse zone not working with BIND 9” states, “A leading whitespace or TAB is Bind shorthand to indicate a repeat of the previous resource record's name.” Multiple lines that start with spaces can “each of the lines a repeat of” whatever prior line did not start with leading space (as shown in the example being described on that web page). If there is no prior line to provide such a value, then an error is generated (according to BIND FAQ, where it refers to “leading white” “space (tab/space)”.)

    To avoid this issue, Troubleshooters.com DNS step 5 states, “Make sure there are no spaces at the start of a left hand domain or an at sign, ESPECIALLY in the IN SOA line.”

Discussion of the settings in the example file

RFC 1035 (Domain names) Section 5 (Master files) discusses this style of zone file. However, there may be some differences. For instance, although RFC 1035 page 20 says “All times are in units of seconds.”, this is actually a configuration file for BIND and references to units of minutes, hours, or days may be supported.

Another resource may be RFC 1034: “Domain names - concepts and facilities”, section 3.6.1: “Textual expression of RRs”.

File structure

RFC 1035 (“Domain names - implementation and specification”) Section 5.1 (“Format of the Master files”) describes a file format like what is used by BIND. (There may be some dated information, such as RFC 1035 (“Domain names - implementation and specification”) Page 20 which states, “All times are in units of seconds.” Newer versions of BIND support other time units in the configuration file.) However, that RFC will be extensively cited, as it is expected that details will result in a configuration file compatable with BIND.

Section 5.1 of RFC 1035 notes, “Entries are predominantly line-oriented, though parentheses can be used to continue a list of items across a line boundary, and text literals can contain CRLF within the text. Any combination of tabs and spaces act as a delimiter between the separate items that make up an entry.” Later text states, “Parentheses are used to group data that crosses a line boundary. In effect, line terminations are not recognized within parentheses.” Actually, line terminations do effectively end comments. Other than that exception, line terminations within parenthesis are indeed effectively unrecognized. Using parentheses allows data on multiple lines to be treated as if it was just on one line.

(Zytrax.com open: Pro DNS and BIND: Chapter 8, SOA records provides a note to clarify usage of the left parenthesis on the SOA record line: the left parenthesis “MUST appear on the same line as the SOA record. This is defined in RFC 1035 and BIND will reject the whole zone if this rule is broken.”)

Also, any line may end with a semicolon and then a comment.

The $ORIGIN line

(Note that the semi-colon is not needed if there is no comment after the domain name. However, the semi-colon is a requried part of the line if there is a comment after the domain name.)

RFC 1035 (Domain names - implementation and specification) Section 5.1 (Format of the Master files) explains the $ORIGIN line as follows: “$ORIGIN is followed by a domain name, and resets the current origin for relative domain names to the stated name.” The impact is described later in the RFC section, noting, “Domain names that end in a dot are called absolute, and are taken as complete. Domain names which do not end in a dot are called relative; the actual domain name is the concatenation of the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as an argument to the master file loading routine. A relative name is an error when no origin is available.”

Once a current origin is used, relative names may be referenced. For example, if the file later includes a reference to a name like “a.ns ” (which does not end with a “full stop” (period) character), the reference will be treated like a full name with the specified partial name and then having the origin concatenated (resulting in something like “ a.ns.example.com. ”)

Another shortcut is that anytime that the origin's name is used without being directly surrounded by a non-whitespace character, RFC 1035 section 5.1 notes that a “free standing” @ may be “used to denote the current origin.” So, @ would be treated like “example.com.

TLDP.org DNS HOWTO: “A simple domain” is a guide that notes, “Some people like to start each zone file with a $ORIGIN directive, but this is superfluous. The origin (where in the DNS hierarchy it belongs) of a zone file is specified in the zone section of the named.conf file” where the information is presumably used by “the master file loading routing” referred to by the RFC 1035 section 5.1.

However, having an $ORIGIN directive may be nice, even if it is “superfluous”, as the origin is then clearly stated in the file.

A $TTL line
Presumably this sets the TTL value.
Resource record data

The resource records follow the basic syntax:

domainLabelUO TTLorUOClass ClassOrOptionalTTL RRType RDATA

This is discussed further by RFC 1034 section 3.6: Resource Records and RFC 1035 (DNS implementation/spec) section 3.2.1: Format.

domainLabelUO

The “label” is basically the “name” of the computer that is being looked up in DNS.

As explained the section about the $ORIGIN line, the reference to @ is usable to represent the domain name that is the current origin, if the @ is surrounded by white space.

(RFC 1034 (“Domain names - concepts and facilities”) Section 6.1: Example configuration used by the C.ISI.EDU name server shows an example where the specified system name was a period. This seems odd: RFC 2181 (“Clarifications to the DNS Specification”) Section 11 (“Name syntax”) states, “The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as” simply being a single period.)

Like the next couple of parameters, this first parameter is fairly optional for all resource record lines except for the first one. In that case, the value will simply be copied from the previous resource record type.

More parameters that are often optional

This domain zone configuration line may then specify the class or TTL value. Specifying such a value is Usually Optional (hence the “UA” text in the example), although the first line may require having a class. RFC 1034 (“Domain names - concepts and facilities”) Page 38 notes, “Since the class of all RRs in a zone must be the same, only the first RR in a zone need specify the class.” (RFC 1035: “Domain names - implementation and specification” Section 5.2: “Use of master files to define zones” backs up the requirement, noting “All RRs in the file should have the same class.”)

Use the IN class

The possible values for the class are listed in RFC 1035: “Domain names - implementation and specification” Section 3.2.4 and RFC 5395: “DNS IANA Considerations, section 3.2”: “RR CLASS IANA Considerations”. RFC 5395: “DNS IANA Considerations, section 3.3.2”: “Label contents and Use” states, “The IN, or Internet, CLASS is thus the only DNS CLASS in global use on the Internet at this time.”

The word IN refers to Internet. (Another option may be CH per RFC 1034. This is discussed more in this text's description of the “A” record type.)

The next parameter is similar to the one just described: it is usually optional. Before the RRType, there may be a TTL parameter and there may also be a class. If both a TTL and a class are specified, they may be specified in either order.

Resource record types

Details about possible values for this field are provided in the section about DNS Record Types.

RDATA

The specific details will depend on what type of resource record is being defined. This field typically contains the value that the DNS server will provide for a query of the related resource type and the domain from the first (optional) field.

...

SOA record information

The lines that start with numbers and then have a semi-colon and a comment are all part of an SOA record. For further information, see details about SOA resource records.

The second string after SOA, which in this example is “ root.example.com. ”, represents an E-Mail address. The E-Mail address can be derived from the text by replacing the first non-escaped period with an at sign. If \. is seen, that gets transformed into a period. The first period that isn't escaped by a backslash gets turned into an at sign. (The trailing dot should be an optional part of the E-Mail address.) So the E-Mail address specified in this file is “root@example.com”.

Understanding parentheses

It may be common to see parentheses used with an SOA line. All those parentheses do is to tell the DNS server to treat multiple lines like a single line. Therefore, there may be some flexibility about whether some terms are inside or outside of the parentheses. Basically, the parentheses are affecting how “white space” characters are treated. So, whether a term (like the E-Mail address) shows up before the left parenthesis or after the left parenthesis doesn't matter (as long as the term is considered to be part of the same line after the parenthesis had its effect).

Additional notes about zone files
What a private domain's zone file may look like

When creating a private internal zone file for a public domain, it may make sense to make heavy use of CNAME entries that point to a private name. This way, there will be less customization needed (because there won't be a need to customize both an AAAA record and an A record). This method is a bit sloppier, as it does increase network bandwidth (because clients will then just be needing to look up information on the private domain). This does, however, centralize the changes so that a successful change in one domain will end up impacting the configuration for another domain. (This may be a good idea for small networks where these zone files are created manually. This may be a less ideal solution when automation both takes care of such issues so that network bandwidth/performance may be a higher consideration.) Using this method does result in some fairly simple-looking configuration files.

For instance, both mail and smtp could just be a CNAME that points to label from the private domain/zone. (There is widespread recommendation to not daisy-chain CNAME entries. So, smtp should not point to mail in this domain if mail is just a CNAME to another domain. Instead, the smtp record in this domain should point directly to the same name that the mail record is pointing to.)

It is quite easy to end up creating a CNAME daisy chain. For instance, causing the mail label to have a CNAME value that points to another domain, but then not updating the MX label during the same update, will likely result in daisy chaining. The following template shows a working version that did not result in BIND reporting errors on startup. Be sure to check the log file after re-loading a changed configuration file, to see if BIND has any errors/warnings to report.

; 234567890123456789012345678901234567890123456789012345678901234567890123456789
; Adapted from another example $

$ORIGIN example.net. ;Optional Comment
$TTL 6h

@ IN SOA ( ; Parenthesis make lines become like just 1
@ ; ...
hostmaster.example.com. ; E-Mail w/ @ replaced
; timers:
0 ; serial
1h ; refresh
30m ; retry
7d ; expiration
1h ) ; minimum
NS ns.otherdomain. ; Nameserver
NS a.ns.otherdomain. ; Nameserver
NS ns1.otherdomain. ; Nameserver
NS b.ns.otherdomain. ; Nameserver
NS ns2.otherdomain. ; Nameserver
AAAA 2001:db8::1 ; Primary Nameserver's IPv6
A 192.0.2.1 ; Primary Nameserver's IPv4
MX 100 mail.otherdomain. ; Points to a system with
; AAAA/A record(s)
ns CNAME ns.otherdomain.
a.ns CNAME a.ns.otherdomain.
ns1 CNAME ns1.otherdomain.
b.ns CNAME b.ns.otherdomain.
ns2 CNAME ns2.otherdomain.
mail CNAME mail.otherdomain.
smtp CNAME mail.otherdomain.
www CNAME www.otherdomain.
ipv6 CNAME ipv6.otherdomain.
www.ipv6 CNAME ipv6.otherdomain.
Any other files
grep include named.conf
grep file named.conf

Make sure that any referenced file exists.

Re-loading configuration

After editing any of the configuration files, for them to take effect, send a SIGHUP to the software. (There is no need to do this if the software hasn't started running yet.) A way to do that may be to run:

sudo kill -HUP $(cat /var/run/named.pid)

Then, check that the software is running. (Details are available in the section about finding out what is running.)

If the software is not running, then it likely encountered an error with its configuration file. Details about such an error are likely sent to the system log, so check out the end of the /var/log/messages file. After fixing the errors, note the current time (by running the date command). That way, if the software again refuses to start, log messages about previous errors can be recognized as being old (and may, therefore, be ignored as further troubleshooting occurs).

If the server does seem to be running, then use a DNS client to query the server.

If this server is now working, consider letting other machines know that this nameserver may be used. (Especially do this if this is the first internal/private nameserver for the network, so that local machines will be able to start recognizing private domains.) Details about how to do this are in the section about automatic addressing. For example, with ISC DHCP, search for all occurrences of option domain-name-servers.

(Do not just change the first occurrence seen and consider the matter done; check all occurrences to determine whether they should be altered. However, if there is a single computer running the name resolution software, and if it has custom settings, it may be desirable to allow those custom settings to remain unaltered.) Naturally, the entire process of updating the relevant automatic addressing settings should be followed. (For instance, if the configuration settings are loaded from a text file, restart the automatic addressing server software so that it re-loads the text file, if that is necessary for an updated configuration to start being used. And then make sure that the restarted software did start up successfully, without logging a complaint, as it uses the new file.)

Starting the BIND software

Run:

sudo named

Then verify that the server is running. (See the section about seeing what is running.)

Check the logs. See if the end of /var/log/messages which should contain some text such as:

Mon DD hh:mm:ss serverSysName named[PID]: starting BIND #.#.#-P#
Mon DD hh:mm:ss serverSysName named[PID]: command channel listening on 127.0.0.1#953
Mon DD hh:mm:ss serverSysName named[PID]: command channel listening on ::1#953
Mon DD hh:mm:ss serverSysName named[PID]: running

Additional log entries could be indicating a problem.

Troubleshooting
Configuration file troubleshooting
View order
client 192.0.2.4#12345: view worldview: received notify for zone 'privateZone': not authoritative

This sort of error message has gone away by making sure that the view for the private zones was placed before the view for the public zones. Simply change the order of the views.

Listening to an unexpected port

If a saavy network administrator checks a machine and notices what ports are being listened to, the network administrator may find that it seems BIND is listening to a rather randomly-selected port.

Preliminary research indicates this is related to the query-source-v6 and query-source options.

A forum post about BIND's usage of a random port number discusses. (However, the post might be for an old version of BIND. The information which is supposedly logged might, actually, not be.) It states, “If a query is sent to this port, a” [warning?] “is generated in the logs.” Hmm, that sounds nice (to log the problem), but unnecessary (as the problem of BIND receiving unexpected traffic may not even occur if BIND didn't even listen to the port).

Installation guide for BIND on CentOS indicates a default config file had this option commented out, and slightly documented. (Apparently BIND 8.1 supported this option.)

Perhaps this only happens if “allow-recursion” is being used?

Some online BIND documentation notes, “With BIND 8, there's no port modifier. With BIND 9, you can specify a source port”.

BIND manual
Bind manual: “The primary documentation for BIND is the ARM, the Administrator's Reference Manual.” (So the reference to ARM has nothing to do with the Advanced/Acorn RISC Machine platform.) Some hyperlinks are provided: also, BIND 9 documentation on ISC's FTP site may show some folders for different versions of the software.