Konfigurimi i nje Primary DNS Server

Add pointers to the named.config.local

To add a new zone you should add a new record at the file /etc/bind/named.config.local

The zone file would point to the forward zone file and to the reverse zone file.

record pointing to the forward zone file

zone "ict.local" { type master; file "/etc/bind/db.ict.local"; };

Create a forward Lookup Zone

It is important at this point to make it clear that we are setting up a primary DNS server. For a simple DNS caching or secondary name server, the setup is a lot simpler .

$TTL

The first entry for our file is the Default TTL - Time To Live. This is defined using the $TTL control statement. $TTL specifies the time to live for all records in the file that follow the statement and don't have an explicit TTL. We are going to set ours to 24 hours - 86400 seconds.

The units used are seconds. An older common TTL value for DNS was 86400 seconds, which is 24 hours. A TTL value of 86400 would mean that, if a DNS record was changed on the authoritative nameserver, DNS servers around the world could still be showing the old value from their cache for up to 24 hours after the change.

Newer DNS methods may have some records deliberately set extremely low on TTL. For example a 300 second TTL would help key records expire in 5 minutes to help ensure these records are flushed world wide quickly. This gives administrators the ability to edit and update records in a timely manner. TTL values are "per record" and setting this value on specific records is normally honored automatically by all standard DNS systems world-wide. Dynamic DNS (DDNS) usually have the TTL value set to 5 minutes, or 300 seconds.

Next up is the SOA Record. The SOA (Start Of Authority) resource record indicates that this name server is the best source of information for the data within this zone (this record is required in each db.DOMAIN and db.ADDR file), which is the same as saying this name server is Authoritative for this zone. There can be only one SOA record in every data zone file (db.DOMAIN).

$TTL 86400

ict.local. IN SOA voyager.ict.local. admin.voyager.ict.local. (

1 ; Serial Number

3h ; Refresh after 3 hours

1h ; Retry after 1 hour

1w ; Expire after 1 week

1h ) ; Negative caching TTL of 1 hour

et's explain the above code:

ict.local. is the domain name and must always be stated in the first column of our line, be sure you include the trailing dot "." after the domain name, we'll explain later on why this is needed.

The IN stands for Internet.

The SOA is an important resource record. What follows is the actual primary name server for ict.local. In our example, this is the server named "voyager" and its Fully Qualified Domain Name (FQDN) is voyager.ict.local. Notice the trailing "." is present here as well.

Next up is the entry admin.voyager.ict.local. which is the email address of the person responsible for this domain. Take the dot "." after the admin entry and replace it with a "@" and you have a valid email address: admin@voyager.ict.local. Most times you will see root, postmaster or hostmaster instead of "admin".

The "(" parentheses allow the SOA record to span more than one line, while in most cases the fields that follow are used by the secondary name servers and any other name server requesting information about the domain.

The serial number "1 ; Serial Number" entry is used by the secondary name server to keep track of changes that might have occured in the master's zone file. When the secondary name server contacts the primary name server, it will check to see if this value is the same. If the secondary's name server is lower than the primary's, then its data is out of date and, when equal, it means the data is up to date. This means when you make any modifications to the primary's zone file, you must increment the serial number at least by one.

Note that anything after the semicolon (;) is considered a remark and not taken into consideration by the DNS BIND Service. This allows us to create easy-to-understand comments for future reference.

The refresh "3h ; Refresh after 3 hours" tells the secondary name server how often to check the primary's server's data, to ensure its copy for this zone is up to date.

If the secondary name server tries to contact the primary and fails, the retry "1 h ; Retry after 1 hour" is used to tell the secondary name server how long to wait until it tries to contact the primary again.

If the secondary name server fails to contact the primary for longer than the time specified in the fourth entry "1 w ; Expire after 1 week", then the zone data on the secondary name server is considered too old and will expire.

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.

Next up in the file are the name server (NS) records:

; Name Servers defined here

ict.local. IN NS voyager.ict.local.

ict.local. IN NS gateway.ict.local.

These entries define the two name servers (voyager and gateway) for our domain ict.local. 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:

; Mail Exchange servers defined here

ict.local. IN MX 10 voyager.ict.local.

ict.local. IN MX 20 gateway.ict.local.

Let's explain what exactly these entries mean. The first line specifies that voyager.ict.local is a mail exchanger for ict.local, just as the second line (...IN MX 20 gateway...) specifies that gateway.ict.local is also a mail exchanger for the domain. 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.ict.local is a higher priority mail server than gateway.ict.local. If another server trying to send email to ict.local fails to contact the highest priority mail server (voyager.ict.local), it will then fall back to the secondary, in which our case is gateway.ict.local.

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 ict.local, it will try to contact first the mail exchanger with the smallest number, which in our case is voyager.ict.local. The smaller the number, the higher the priority if there are more than one mail servers.

In our example, if we replaced:

ict.local. IN MX 10 voyager.ict.local.

ict.local. IN MX 20 gateway.ict.local.

with

ict.local. IN MX 50 voyager.ict.local.

ict.local. IN MX 100 gateway.ict.local.

the result in matter of server priority, would be the same.

Let's now have a look our next part of our zone file: Host IP Addresses and Alias records:

; Host addresses defined here

localhost.ict.local. IN A 127.0.0.1

voyager.ict.local. IN A 192.168.0.15

enterprise.ict.local. IN A 192.168.0.5

gateway.ict.local. IN A 192.168.0.10

admin.ict.local. IN A 192.168.0.1

; Aliases

www.ict.local. IN CNAME voyager.ict.local.

Most fields in this section are easy to understand. We start by defining our localhost (local loopback) "localhost.ict.local. IN A 127.0.0.1" and continue with the servers on our private network, these include voyager, enterprise, gateway and admin. The "A" record stands for IP Address. So "voyager.ict.local. IN A 192.168.0.15" translates to a host called voyager located in the ict.local domain with an INternet ip Address of 192.168.0.15. See the pattern? :)

The second block has the aliases table, where we created a Canonical Name (CNAME) record. A CNAME record simply maps an alias to its canonical name; in our example, www is the alias and voyager.ict.local is the canonical name.

When a name server looks up a name and finds CNAME records, it replaces the name (alias - www) with its canonical name (voyager.ict.local) and looks up the canonical name (voyager.ict.local).

For example, when a name server looks up www.ict.local, it will replace the 'www' with 'voyager' and lookup the IP Address for voyager.ict.local.

This also explains the existance of "www" in all URLs - it's nothing more than an alias which, ultimately, is replaced with the CNAME record defined.

The Complete db.domain Configuration File

That completes a simple domain setup! We have now created a working zone file that looks like this:

$TTL 86400

ict.local. IN SOA voyager.ict.local. admin.voyager.ict.local. (

1 ; Serial Number

3h ; Refresh after 3 hours

1h ; Retry after 1 hour

1w ; Expire after 1 week

1h ) ; Negative caching TTL of 1 hour

; Name Servers defined here

ict.local. IN NS voyager.ict.local.

ict.local. IN NS gateway.ict.local.

; Mail Exchange servers defined here

ict.local. IN MX 10 voyager.ict.local.

ict.local. IN MX 20 gateway.ict.local.

; Host Addresses Defined Here

localhost.ict.local. IN A 127.0.0.1

voyager.ict.local. IN A 192.168.0.15

enterprise.ict.local. IN A 192.168.0.5

gateway.ict.local. IN A 192.168.0.10

admin.ict.local. IN A 192.168.0.1

; Aliases

www.ict.local. IN CNAME voyager.ict.local.

A quick glance at this file tells you a lot about our lab domain ict.local, and this is probably the best time to explain why we should not omit the trailing dot at the end of the domain name:

If we took gateway.ict.local as an example and omitted the dot "." at the end of our entries, the system would translate it like this: gateway.ict.local.ict.local - definately not what we want!

As you see, the 'ict.local' is appended to the end of our Fully Qualified Domain Name for the particular resource record (gateway). This is why it's so important to never forget that extra dot "." at the end!

Create a reverse lookup zone

The db.192.168.0 zone data file is the second file we are creating for our DNS server. As outlined in the DNS-BIND Introduction, this file's purpose is to provide the IP Address -to- name mappings. Note that this file is to be placed on the Master DNS server for our domain.

Constructing db.192.168.0

While we start to construct the file, you will notice many similarities with our previous file. Most resource records have already been covered and explained in our previous articles and therefore we will not repeat on this page.

The first line is our $TTL control statement, followed by the Start Of Authority (SOA) resource record:

$TTL 86400

0.168.192.in-addr.arpa. IN SOA voyager.ict.local. admin.ict.local. (

1 ; Serial

3h ; Refresh after 3 hours

1h ; Retry after 1 hour

1w ; Expire after one week

1h ) ; Negative Caching TTL of 1 hour

As you can see, everything above, except the first column of the first line, is identical to the db.ict.local file. The "0.168.192.in-addr.arpa" entry is our IP network in reverse order. The trick to figure out your own in-addr.arpa entry is to simply take your network address, reverse it, and add an ".in-addr.arpa." at the end

Name server resource records are next, follwed by the PTR resource record that creates our IP Address-to-name mappings. The syntax is nearly the same as the db.domain file, but keep in mind that we don't enter the full reversed IP Address for the name servers but only the first 3 octecs which represent the network they belong to:

; Name Servers defined here

0.168.192.in-addr.arpa. IN NS voyager.ict.local.

0.168.192.in-addr.arpa. IN NS gateway.ict.local.

; IP Address to Name mappings

1.0.168.192.in-addr.arpa. IN PTR admin.ict.local.

5.0.168.192.in-addr.arpa. IN PTR enterprise.ict.local.

10.0.168.192.in-addr.arpa. IN PTR gateway.ict.local.

15.0.168.192.in-addr.arpa. IN PTR voyager.ict.local.

Time to look at the configuration file with all its entries:

$TTL 86400

0.168.192.in-addr.arpa. IN SOA voyager.ict.local. admin.ict.local. (

1 ; Serial

3h ; Refresh after 3 hours

1h ; Retry after 1 hour

1w ; Expire after one week

1h ) ; Negative Caching TTL of 1 hour

; Name Servers defined here

0.168.192.in-addr.arpa. IN NS voyager.ict.local.

0.168.192.in-addr.arpa. IN NS gateway.ict.local.

; IP Address to Name mappings

1.0.168.192.in-addr.arpa. IN PTR admin.ict.local.

5.0.168.192.in-addr.arpa. IN PTR enterprise.ict.local.

10.0.168.192.in-addr.arpa. IN PTR gateway.ict.local.

15.0.168.192.in-addr.arpa. IN PTR voyager.ict.local.

This completes the db.192.168.0 Zone data file.

Remember the whole purpose of this file is to provide an IP Address-to-name mapping, which is why we do not use the domain name in front of each line, but the reversed IP Address followed by the in-addr.arpa. entry.