Bind domain zone file

The Resource Records RRs are all defined separately and clicking on any highlighted RR type will take you to a detailed description. An alternate file including only hosts externally visible to the domain is also provided.

The associated reverse map zone file is provided. Problems, comments, suggestions, corrections including broken links or something to add? Please take the time from a busy life to 'mail us' at top of screen , the webmaster below or info-support at zytrax.

The last line " 1 h ; Negative caching TTL of 1 day " is how long a name server will send negative responses about the zone. These negative responses say that a particular domain or type of data sought for a particular domain name doesn't exist.

Notice the SOA section finishes with the " " parentheses. These entries define the two name servers voyager and gateway for our domain firewall. These entries will be also in the db.

ADDR file for this domain as we will see later on. It's time to enter our MX records. These records define the mail exchange servers for our domain, and this is how any client, host or email server is able to find a domain's email server:. Let's explain what exactly these entries mean. The first line specifies that voyager.

IN MX 20 gateway The MX record indicates that the following hosts are mail exchanger servers for the domain and the numbers 10 and 20 indicate the priority level. The smaller the number, the higher the priority. This means that voyager.

If another server trying to send email to firewall. These entries were introduced to prevent mail loops. When another email server unlikely for a private domain like mine, but the same rule applies for the Internet wants to send mail to firewall. The smaller the number, the higher the priority if there are more than one mail servers. IN MX 10 voyager. IN MX 20 gateway. IN MX 50 voyager.

We recommend not omitting it, however, lest something change and all your zone files suddenly be broken after a BIND update! The next two arguments are FQDNs—at least, they look like it. Note that you can use unterminated hostnames here—for example, we could have just used ns1.

The second FQDN, hostmaster. Instead, it's a perverse way of rewriting an email address. It's incredibly common to see this screwed up in real-life zone files—thankfully, it doesn't much matter. We're not aware of literally anyone who actually uses this feature of a DNS zone to contact anyone.

Moving on, we have serial , refresh , retry , expire , and negative TTL for the zone inside parentheses. Note that the comments you see here labeling them are not required—and in real life, you'll rarely see them. We strongly prefer to put these comments in production zone files in order to make it easier to read them, but BIND itself doesn't care! One of the most common areas for confusion in the SOA record is what effect the refresh , retry , and expire arguments have.

These arguments don't affect DNS resolvers at all—only secondary authoritative nameservers for the domain. One final note: older versions of BIND required all of these times to be in seconds BIND9—released almost 20 years ago, in October —supports human-readable time sufffixes such as "m" for minutes, "h" for hours, and "d" for days. Please use these human readable suffixes when writing zone files; nobody should have to break out a calculator to figure out that 86, seconds is one day!

In these two records, we define the hostnames, which are authoritative nameservers for our zone. Once again, we've used dot-terminated FQDNs for these records. Once again, we could have used unterminated hostnames— ns1.

Doing so would make the zone more confusing and difficult to read, though. Note that the NS record specifies hostnames , not IP addresses. This is a common source of confusion for DNS newbies, and it's important to get it right.

You cannot specify a bare IP address as the nameserver for a domain; you absolutely must specify a hostname here. Finally, note that we haven't specified the domain name itself on either line—this is because we've inherited it from the SOA record above.

The file usually contains A record, MX record, domain name, mail servers, nameservers details and so on. So, this file is critically important as it holds the domain details. Any error in this file can cause trouble while loading the domain.

Because DNS lookup resolves a domain with the help of this zone file. A zone file is a text file so it can contain syntax errors. Hence we need to check the syntax and integrity of this important configuration file. For this, we can make use of the command, named-checkzone. Alternatively, we can check the configuration file of BIND.

For this, we can make use of the command, named-checkconf. The command usage is as,. In short, to check the BIND9 zone file we can use the command named-checkzone. Today, we saw how our Support Engineers check the zone file in an Ubuntu server. Never again lose customers to poor server speed! Let us help you.