How to configure a Domain Name Server (DNS) (BIND).

Introduction.

Bind (Berkeley Internet Name Domain).

BIND (acronym for Berkeley Iinternet Nlove Domain) is an implementation of the DNS protocol and provides a free implementation of the main components of the Domain Name System, which include:

The BIND DNS Server is widely used on the Internet (99% of DNS servers) providing a robust and stable solution.

DNS (Domain Name System).

DNS (acronym for Domain Nlove System) is a distributed and hierarchical database that stores the necessary information for domain names. Its main uses are the assignment of domain names to IP addresses and the location of the corresponding email servers for each domain. The DNS It was born from the need to facilitate human beings access to the servers available through the Internet, allowing them to do so by a name, something easier to remember than an address IP.

The DNS servers they use TCP Y UDP on port 53 to answer queries. Almost all inquiries consist of a single request UDP From a DNS client followed by a single answer UDP from the server. TCP intervenes when the size of the response data exceeds 512 bytes, as occurs with tasks such as zone transfer.

NIC (Network Information Center).

NIC (acronym for Network Information Center or Network Information Center) is an institution in charge of assigning domain names on the Internet, whether they are generic domain names or by countries, allowing people or companies to set up Internet sites through a ISP using a DNS. Technically there is aNIC for each country in the world and each one of these is responsible for all domains with the termination corresponding to their country. For example: NIC Mexico is the entity in charge of managing all domains with termination .mx, which is the corresponding termination assigned to the domains of Mexico.

FQDN (Fully Qualified Domain Name).

FQDN (acronym for Fully Qualified Domain Name or Fully Qualified Domain Name) is an ambiguous Domain Name that specifies the absolute position of the node in the hierarchical DNS tree. It is distinguished from a regular name because it has a period at the end.

As an example: assuming you have a device whose host name is "machine1" and a domain called "domain.com", the FQDN would "machine1.domain.com.", So the device is uniquely defined while there could be many hosts called" machine1 ", there can only be one called"machine1.domain.com.». The absence of the period at the end would define that it could only be a prefix, that is, «machine1.domain.com»Could be a domain of a longer one like«machine1.domain.com.mx».

The maximum length of a FQDN is 255 bytes, with an additional restriction of 63 bytes for each label within the domain name. Only ASCII characters AZ, digits, and the "-" character are allowed. They are not case sensitive.

Since 2004, at the request of several European countries, there is the standard IDN (acronym for Internationalized Domain Name) which allows non-ASCII characters, encoding characters Unicode within byte strings within the normal character set of FQDN. As a result, the length limits of domain names IDN they depend directly on the very content of the name.

Components of a DNS.

DNS operates through three components: DNS Clients, DNS Servers, and Zones of Authority.

DNS clients.

They are programs that a user executes and that generate query requests to resolve names. They basically ask for the IP address that corresponds to a certain name.

DNS servers.

They are services that answer the queries made by the DNS clients. There are two types of nameservers:

A large number of DNS server operation problems are attributed to poor secondary server options for DNS zones. According to RFC 2182, DNS requires that at least three servers existfor all delegated domains (or zones).

One of the main reasons for have at least three servers for each zone is to allow that the information of the same zone is always available and reliable to the DNS clients through the Internet when a DNS server in that zone fails, is unavailable and / or unreachable.

Having multiple servers also makes it easy to spread in the area and improve overall system efficiency by providing options to DNS clients in case they find it difficult to make a consultation in a DNS server. In other words: having multiple servers for a zone allows have redundancy and service support.

With multiple servers, usually one acts as Master or Primary Server and the others like Slave or Secondary Servers. Correctly configured and once the data for a zone has been created, it will not be necessary to copy them to each Slave or Secondary Server, as it will be in charge of transferring the data automatically when necessary.

The DNS servers they answer two types of queries:

Zones of Authority.

They allow the Master or Primary Server load the information of a zone. Each Authority Zone it encompasses at least one domain and possibly its sub-domains, if the latter are not delegated to other areas of authority.

The information of each Authority Zone is stored locally in a file on the DNS server. This file can include several types of records:

The areas that can be resolved are:

Forwarding Zones.

Return IP addresses for searches made for names FQDN (Fully Qualified Domain Name).

In the case of public domains, the responsibility for the existence of a Authority Zone for each Forwarding Zonecorresponds to the domain authority itself, that is, and generally, whoever is registered as the domain authority after consulting a database WHOIS. Those who buy domains through a NIC (for example: www.nic.mx) are those who take charge of the Forwarding Zones, either through your own DNS server or through DNS servers from his ISP.

Unless it is a domain for use in a local network, every domain must first be processed with a NIC as a requirement to have the legal right to use it and to be able to spread it over the Internet.

Reverse Resolution Zones.

They return names FQDN (Fully Qualified Domain Name) for searches made for IP addresses.

In the case of public network segments, the responsibility for the existence of a Authority Zone for each Inverse Resolution Zone corresponds to the authority of the segment itself, that is, and generally, whoever is registered as the authority of the segment after consulting a database WHOIS.

The big ones ISP, and in some cases some companies, are the ones who take charge of the Reverse Resolution Zones.

Search and query tools.

Host command.

The mandate host a simple tool for searching DNS servers. It is used to convert names to IP addresses and vice versa.

By default, it performs searches in the DNS servers defined in the file /etc/resolv.conf, optionally defining the DNS server To consult.

host www.unidadlocal.com

The above performs a search in the DNS servers defined in the file /etc/resolv.conf from the system, returning an IP address as a result.

host www.unidadlocal.com 200.33.146.217

The above performs a search in the DNS server at IP address 200.33.146.217, returning an IP address as the result.

Mandate dig.

The mandate dig (domain information groper) is a flexible tool for querying on DNS servers. It performs searches and shows the answers that are returned by the servers that were consulted. Due to its flexibility and clarity in the output is that most administrators use dig to diagnose DNS problems.

By default, it performs searches in the DNS servers defined in the file /etc/resolv.conf, optionally defining the DNS server To consult. The basic syntax would be:

dig @server name TYPE

Where server corresponds to the name or IP address of the DNS server To consult, Name corresponds to the name of the record of the resource that is being searched and KIND corresponds to the type of query required (ANY, A, MX, SOA, NS, etc.)

Example:

dig @ 200.33.146.209 unitylocal.com MX

The above performs a search in the DNS server at IP address 200.33.146.209 for logs MX for the domain unitlocal.com.

dig localunit.com NS

The above performs a search in the DNS servers defined in the file /etc/resolv.conf system for records NS for the domain unitlocal.com.

dig @ 200.33.146.217 unitylocal.com NS

The above performs a search in the DNS server at IP address 200.33.146.217 for logs NS for the domain unitlocal.com.

Jwhois (whois) command.

The mandate jwhois is a query tool through servers WHOIS. The basic syntax is:

jwhois domain

Example:

jwhois unitylocal.com

The above returns the information corresponding to the domain unitlocal.com.

Necessary logical support.

Installation through yum.

If using CentOS 4 or White Box Enterprise Linux 4, or later versions, it can be installed using the following:

yum -y install bind bind-chroot bind-utils caching-nameserver

Installation via Up2date

If using Red Hat ™ Enterprise Linux 4, or later versions, it can be installed using the following:

up2date -i bind bind-chroot bind-utils caching-nameserver

Procedures

Preparations.

Ideally the following data should be defined first:

It is important to be clear that points 2, 3 and 4 involve data that must exist previously and be fully resolved by another DNS server; The above means they cannot use data that is part of or depends on the same domain that is intended to be resolved. Similarly, the server where the DNS must have a name FQDN and that it is previously and fully resolved in another DNS.

As a general rule, a forwarding zone will be generated for each domain over which there is full and absolute authority and a reverse resolution zone will be generated for each network over which there is full and absolute authority. that is, if you own the domain «Anycosa.com», the corresponding zone file must be generated in order to resolve said domain. For each network with private IP addresses over which there is control and full and absolute authority, a reverse resolution zone file must be generated in order to reverse the IP addresses of said zone. Regularly, the reverse resolution of public IP addresses is the responsibility of the service providers since they are the ones who have full and absolute authority over said IP addresses.

All zone files must belong to the user "named" in order for the service to named can access these or modify them in the case of slave zones.

Creation of zone files.

The following would correspond to the contents for the zone files required for the local network and for the NIC with which the domain has been registered. Please note that in forwarding areas at least one Mail Exchanger is always specified (MX) So what tabs (TAB key) are used instead of space. You will only need to replace names and IP addresses, and perhaps add new records to complement your local network.

Local network forwarding zone /var/named/chroot/var/named/red-local.zone

$TTL 86400 @ INSOAdns.red-local.jperez.red-local. (2006031601; serial number 28800; refresh time 7200; time between query retries 604800; time after which zone 86400 expires; total lifetime) @INNSdns @ INMX10mail @ INA192.168.1.1 intranetINA192.168.1.1 machine2INA192 .168.1.2 machine3INA192.168.1.3 machine4INA192.168.1.4 wwwINCNAMEintranet mailINA192.168.1.1 ftpINCNAMEintranet dnsINCNAMEintranet

Local network reverse resolution zone /var/named/chroot/var/named/1.168.192.in-addr.arpa.zone

$TTL 86400 @ INSOAdns.red-local.jperez.red-local. (2006031601; serial number 28800; refresh time 7200; time between query retries 604800; time after zone 86400 expires; total time to live) @ INNSdns.red-local. 1INPTRintranet.red-local. 2INPTRmaquina2.net-local. 3INPTRmaquina3.network-local. 4INPTRmaquina4.network-local.

Domain forwarding zone /var/named/chroot/var/named/dominio.com.zone

Assuming that hypothetically you are the authority for the domain "Domain.com", you can create a Forwarding Zone with content similar to the following:

$TTL 86400 @INSOAfqdn.domain-resolved.account.email.existing. (2006031601; serial number 28800; refresh time 7200; time between query retries 604800; time after zone 86400 expires; total lifetime) @INNSdns @ INMX10mail @ INA148.243.59.1 serverINA148.243.59.1 wwwINCNAMEserver mailINA148.243.59.1 ftpINCNAMeserver dnsINCNAMeserver

Domain reverse resolution zone /var/named/chroot/var/named/1.243.148.in-addr.arpa.zone

Assuming that hypothetically se is the authority for the network segment 148.234.1.0/24, you can create a Inverse Resolution Zone with content similar to the following:

$TTL 86400 @INSOAfqdn.domain-resolved.account.email.existing. (2006031601; serial number 28800; refresh time 7200; time between query retries 604800; time after which zone 86400 expires; total time to live) @ INNSdns.domain.com. 1INPTRserver.domain.com. 2INPTRmaquina2.domain.com. 3INPTRmaquina3.domain.com. 4INPTRmaquina4.domain.com.

Every time you make any changes to a zone file, you must change the serial number (serial) so that the changes take effect immediately when the service is restarted named, since otherwise you would have to restart the computer, which is inconvenient.

Parameter configuration in the /etc/named.conf file

options {directory "/ var / named /"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; allow-recursion;
forwarders;
forward first;
}; zone "." {type hint; file "named.ca"; }; zone "0.0.127.in-addr.arpa" {type master; file "0.0.127.in-addr.arpa.zone"; allow-update {none; }; }; zone "localhost" {type master; file "localhost.zone"; allow-update {none; }; };
zone "domain.com" { 
type master; 
file "domain.com.zone"; allow-update {none; };
};
zone "1.243.148.in-addr.arpa" { 
type master; 
file "1.243.148.in-addr.arpa.zone"; allow-update {none; };
};
zone "red-local" { 
type master; 
file "red-local.zone";
allow-update {none; };
};
zone "1.168.192.in-addr.arpa" { 
type master; 
file "1.168.192.in-addr.arpa.zone";
allow-update {none; };
};

Additional DNS security for public use.

A DDoS (Distributed Denial orF Service) is an extension of the attack Two, is carried out with the installation of several remote agents on many computers that may be located in different parts of the world. The attacker manages to coordinate these agents in order to massively amplify the volume of information saturation (flood), with the possibility of an attack by hundreds or thousands of computers directed at a target machine or network. This technique has been revealed as one of the most efficient and simple when it comes to collapsing servers, distributed technology has become more sophisticated to the point of giving power to cause serious damage to people with little technical knowledge.

A DNS configured to allow indiscriminately recursive queries can allow the server to suffer or participate in a DDoS. Solution to the problem is to add in the file /etc/named.conf, in the options section, the parameter allow-recursion defining the network, the networks or the ACLs that will be allowed to make all kinds of queries in the DNS, be they local or from other domains.

/Etc/named.conf file

options {directory "/ var / named /"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt";
allow-recursion;
forwarders; forward first; }; zone "." {type hint; file "named.ca"; }; zone "domain.com" {type master; file "domain.com.zone"; allow-update {none; }; }; zone "1.243.148.in-addr.arpa" {type master; file "1.243.148.in-addr.arpa.zone"; allow-update {none; }; };

The above means that only 192.168.1.0/24 can perform all kinds of queries in the DNS, either for a domain name hosted locally and other domains resolved on other servers (Examples: www.yahoo.com, www.google.com, www.unidadlocal.com, etc.). The rest of the world will only be able to inquire about the zonesdomain.com Y 1.243.148.in-addr.arpa, which are hosted locally.

Additional security in DNS for exclusive use in local network.

If it is going to be a domain name server for exclusive use in a local network, and you want to avoid security problems of different kinds, you can use the parameter allow-query, which will serve to specify that only certain addresses will be able to make queries to the domain name server. You can directly specify IP addresses, complete networks or access control lists that must be defined before anything else in the file/etc/named.conf.

/Etc/named.conf file

acl "redlocal";
options {directory "/ var / named /"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; allow-recursion {redlocal; }; forwarders; forward first;
allow-query {redlocal; 192.168.1.15; 192.168.1.16; };
}; zone "red-local" {type master; file "red-local.zone"; allow-update {none; }; }; zone "1.168.192.in-addr.arpa" {type master; file "1.168.192.in-addr.arpa.zone"; allow-update {none; }; };

The slave zones.

Slave zones refer to those hosted on secondary domain name servers and that perform the functions of duplicating the master zones on primary domain name servers. The content of the zone file is the same as on the primary server. The difference is in the section of text used in /etc/named.conf, where the zones are defined as slaves and define the servers where the master zone is hosted.

File /etc/named.conf Secondary DNS server.

zone "domain.com" { 
type slave;
file "domain.com.zone";
masters;
}; zone "1.243.148.in-addr.arpa" { 
type slave;
file "1.243.148.in-addr.arpa.zone";
masters;
}; zone "red-local" {
type slave;
file "red-local.zone";
masters;
}; zone "1.168.192.in-addr.arpa" { 
type slave;
file "1.168.192.in-addr.arpa.zone";
masters;
};

Additionally, if you want to increase security and want to specify on the Primary DNS Server which servers will be allowed to be secondary domain name servers, that is, make transfers, you can use the parameter allow-transfer as follows:

File /etc/named.conf Primary DNS Server.

zone "domain.com" {type master; file "domain.com.zone"; allow-update {none; };
allow-transfer;
}; zone "1.243.148.in-addr.arpa" {type master; file "1.243.148.in-addr.arpa.zone"; allow-update {none; };
allow-transfer;
}; zone "red-local" {type master; file "red-local.zone"; allow-update {none; };
allow-transfer;
}; zone "1.168.192.in-addr.arpa" {type master; file "1.168.192.in-addr.arpa.zone"; allow-update {none; };
allow-transfer;
};

Restart service and configuration debugging.

When you finish editing all the files involved, it will only be enough to restart the domain name server.

service named restart

If we want the domain name server to be added among the services at system startup, we must do the following in order to enable named along with system boot:

chkconfig named on

Perform debug test and verify zone loaded with serial number:

tail -80 / var / log / messages | grep named

The above, if it is working correctly, should return something like the following:

Aug 17 17:15:15 linux named [30618]: starting BIND 9.2.2 -u named Aug 17 17:15:15 linux named [30618]: using 1 CPU Aug 17 17:15:15 linux named: Initiation of named succeeded Aug 17 17:15:15 linux named [30622]: loading configuration from '/etc/named.conf' Aug 17 17:15:15 linux named [30622]: no IPv6 interfaces found Aug 17 17:15:15 linux named [30622]: listening on IPv4 interface lo, 127.0.0.1#53 Aug 17 17:15:15 linux named [30622]: listening on IPv4 interface eth0, 192.168.1.1#53 Aug 17 17:15:15 linux named [30622] : command channel listening on 127.0.0.1#953 Aug 17 17:15:16 linux named [30622]: zone 0.0.127.in-addr.arpa/IN: loaded serial 3
Aug 17 17:15:16 linux named [30622]: zone 1.168.192.in-addr.arpa/IN: loaded serial 2006031602
Aug 17 17:15:16 linux named [30622]: zone localhost / IN: loaded serial 1
Aug 17 17:15:16 linux named [30622]: zone my-domain.com.mx/IN: loaded serial 2006031602
Aug 17 17:15:16 linux named [30622]: running Aug 17 17:15:16 linux named [30622]: zone 1.168.192.in-addr.arpa/IN: sending notifies (serial 2006031602) Aug 17 17: 15:16 linux named [30622]: zone my-domain.com.mx/IN: sending notifies (serial 2006031602)