Руководство по bind

Данное руководство описывает установку и конфигурацию BIND для домена и локальной сети.

Введение

BIND — самый часто используемый DNS-сервер в Интернете. Данное руководство объяснит, как настроить BIND для домена, используя различные конфигурации, одну для локальной сети, и одну для остального мира. Для этого будут использованы два вида (views):

1. Вид для внутренней зоны (локальная сеть).
2. Вид для внешней зоны (остальной мир).

Данные, которые будут использоваться в примерах

Конфигурация BIND

Установка

Сначала, установите net-dns/bind.

Настройка /etc/bind/named.conf

Сначала нужно сконфигурировать /etc/bind/named.conf. Первым шагом будет указание корневого каталога bind, порт, который будет прослушиваться, PID-файл и строка для протокола IPv6.

ФАЙЛ /etc/bind/named.confРаздел options

options {
        directory "/var/bind";
  
        listen-on-v6 { none; };
        listen-on port 53 { 127.0.0.1; ВАШ_ЛОКАЛЬНЫЙ_IP; };
  
        pid-file "/var/run/named/named.pid";
};

Вторая часть named.conf — внутренний вид, используемый для нашей локальной сети.

ФАЙЛ /etc/bind/named.confВид для внутренней сети (internal view)

view "internal" {
        match-clients { ВАША_ЛОКАЛЬНАЯ_СЕТЬ; localhost; };
        recursion yes;
  
        zone "ВАШ_ДОМЕН" {
                type master;
                file "pri/ВАШ_ДОМЕН.internal";
                allow-transfer { any; };
        };
};

Третья часть named.conf — внешний вид, используемый для разрешения наших доменных имен для остального мира, и разрешения всех остальных доменных имен для нас (и всех, кто захочет использовать наш DNS сервер).

ФАЙЛ /etc/bind/named.confВид для внешней сети (external view)

view "external" {
        match-clients { any; };
        recursion no;
  
        zone "." IN {
                type hint;
                file "named.ca";
        };
  
        zone "127.in-addr.arpa" IN {
                type master;
                file "pri/127.zone";
                allow-update { none; };
                notify no;
        };
  
        zone "ВАШ_ДОМЕН" {
                type master;
                file "pri/ВАШ_ДОМЕН.external";
                allow-query { any; };
                allow-transfer { ПОДЧИНЕННЫЙ_DNS_СЕРВЕР; };
        };
};

Последняя часть named.conf это политика логов.

ФАЙЛ /etc/bind/named.confПолитика логов

logging {
        channel default_syslog {
                file "/var/log/named/named.log" versions 3 size 5m;
                severity debug;
                print-time yes;
                print-severity yes;
                print-category yes;
        };
       category default { default_syslog; };
};

Каталог /var/log/named/ должен существовать и принадлежать named:

Создание файла внутренней зоны

Мы используем имена хостов и IP-адреса из примера сети, показанного ниже. Заметьте, что почти все (но не все) доменные имена оканчиваются на «.» (точку).

ФАЙЛ /var/bind/pri/ВАШ_ДОМЕН.internal

$TTL 2d
@	IN SOA	ns.ВАШ_ДОМЕН.	АДМИНИСТРАТОР.ВАШ_ДОМЕН. (
	ИЗМЕНЕНИЕ	; serial
	3h	; refresh
	1h	; retry
	1w	; expiry
	1d )	; minimum
  
ВАШ_ДОМЕН.		IN MX	0 mail.ВАШ_ДОМЕН.
ВАШ_ДОМЕН.		IN TXT	"v=spf1 ip4:ВАШ_ПУБЛИЧНЫЙ_IP/32 mx ptr mx:mail.ВАШ_ДОМЕН ~all"
ВАШ_ДОМЕН.		IN NS	ns.ВАШ_ДОМЕН.
ВАШ_ДОМЕН.		IN NS	ПОДЧИНЕННЫЙ_DNS_СЕРВЕР
www.ВАШ_ДОМЕН.	        IN A	192.168.1.3
ns.ВАШ_ДОМЕН.		IN A	192.168.1.5
mail.ВАШ_ДОМЕН.	        IN A	192.168.1.3
router.ВАШ_ДОМЕН.	IN A	192.168.1.1
hell.ВАШ_ДОМЕН.	        IN A	192.168.1.3
heaven.ВАШ_ДОМЕН.	IN A	192.168.1.5
desktop.ВАШ_ДОМЕН.	IN A	192.168.1.4

Создание файла внешней зоны

Здесь у нас только поддомены, информацию о которых мы хотим отдавать для внешних клиентов (www, mail и ns).

ФАЙЛ /var/bind/pri/ВАШ_ДОМЕН.external

$TTL 2d
@	IN SOA	ns.ВАШ_ДОМЕН.	АДМИНИСТРАТОР.ВАШ_ДОМЕН. (
	ИЗМЕНЕНИЕ	;serial
	3h	;refresh
	1h	;retry
	1w	;expiry
	1d )	;minimum
  
ВАШ_ДОМЕН.		IN MX	0 mail.ВАШ_ДОМЕН.
ВАШ_ДОМЕН.		IN TXT	"v=spf1 ip4:ВАШ_ПУБЛИЧНЫЙ_IP/32 mx ptr mx:mail.ВАШ_ДОМЕН ~all"
ВАШ_ДОМЕН.		IN NS	ns.ВАШ_ДОМЕН.
ВАШ_ДОМЕН.		IN NS   ПОДЧИНЕННЫЙ_DNS_СЕРВЕР
www.ВАШ_ДОМЕН.    	IN A	ВАШ_ПУБЛИЧНЫЙ_IP
ns.ВАШ_ДОМЕН.		IN A	ВАШ_ПУБЛИЧНЫЙ_IP
mail.ВАШ_ДОМЕН.	        IN A    ВАШ_ПУБЛИЧНЫЙ_IP

Окончательная конфигурация

Вам нужно добавить named к уровню доступ по умолчанию:

Конфигурация клиентов

Теперь вы можете использовать свой DNS сервер для всех машин в вашей локальной сети для разрешения доменных имен. Измените файл /etc/resolv.conf на всех машинах вашей локальной сети.

ФАЙЛ /etc/resolv.conf

search ВАШ_ДОМЕН
nameserver IP_ВАШЕГО_СЕРВЕРА_DNS

Заметьте, что IP_ВАШЕГО_СЕРВЕРА_DNS тот же, что и ВАШ_ЛОКАЛЬНЫЙ_IP, который мы использовали в данном документе. В примере он был 192.168.1.5.

Тестирование

Мы можем протестировать наш новый сервер DNS. Сначала нам нужно запустить сервис.

Теперь мы собираемся выполнить некоторые host-команды к некоторым доменам. Для этого теста мы можем использовать любой компьютер в нашей локальной сети. Если у вас нет пакета net-dns/host, вы можете вместо него использовать ping. В противном случае сначала запустите emerge host.

www.gentoo.org has address 209.177.148.228
www.gentoo.org has address 209.177.148.229

hell.ВАШ_ДОМЕН has address 192.168.1.3

router.ВАШ ДОМЕН has address 192.168.1.1

Защищаем сервер программой iptables

Во время использования DNS-сервиса, для дополнительной защиты, можно настроить iptables такими правилами:

iptables -A INPUT -p udp --sport 53 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j ACCEPT

This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Vicente Olivert Riera, nightmorph
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article’s associated history page.

BIND (or named) is the most widely used Domain Name System (DNS) server.

Note: The organization developing BIND is serving security notices to paying customers up to four days before Linux distributions or the general public.[1]

Installation

Install the bind package.

Start/enable the named.service systemd unit.

To use the DNS server locally, use the 127.0.0.1 nameserver (meaning clients like Firefox resolve via 127.0.0.1), see Domain name resolution.
This will however require you to #Allow recursion while a firewall might block outside queries to your local named.

Configuration

BIND is configured in /etc/named.conf. The available options are documented in named.conf(5).

Reload the named.service unit to apply configuration changes.

Restrict access to localhost

BIND by default listens on port 53 of all interfaces and IP addresses. To only allow connections from localhost add the following line to the options section in /etc/named.conf:

listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };

Set up DNS forwarding

To make BIND forward DNS queries to another DNS server add the forwarders clause to the options section.

Example to make BIND forward to the Google Public DNS servers:

forwarders {
    8.8.8.8; 2001:4860:4860::8888;
    8.8.4.4; 2001:4860:4860::8844;
};

(As of 9.18, only plaintext DNS servers are supported as forwarders.)

Serve DNS over TLS or HTTPS

To enable serving DNS over TLS or HTTPS in BIND 9.18, define a tls block specifying your certificate, then add listen-on clauses enabling DNS over TLS and HTTPS listeners (as well as a standard DNS listener).

/etc/named.conf

tls mycert {
    cert-file "<path>.crt";
    key-file "<path>.key";
};

options {
    // Standard port 53 listeners need to be re-added explicitly
    listen-on    { any; };
    listen-on-v6 { any; };
    
    // Add a DNS over TLS listener on standard port 853
    listen-on    tls mycert { any; };
    listen-on-v6 tls mycert { any; };
    
    // Add a DNS over HTTPS listener on custom port
    listen-on    port 9443 tls mycert http default { any; };
    listen-on-v6 port 9443 tls mycert http default { any; };
    
    // If needed, add a cleartext HTTP listener for a reverse proxy
    //listen-on    port 8443 tls none http default { 127.0.0.1; };
    //listen-on-v6 port 8443 tls none http default { ::1; };
};
...

Note that tls{} is defined at the top level, not inside the options{} block.

A configuration template for running a domain

Following is a simple home nameserver being set up, using domain.tld as the domain being served world-wide like this wiki’s archlinux.org domain is.

A more elaborate example is DNS server with BIND9, while this shows how to set up internal network name resolution.

Creating a zonefile

Create /var/named/domain.tld.zone.

$ORIGIN domain.tld.
$TTL 2h

@               SOA     ns1 hostmaster (
                                2018111111 ; Serial
                                8h         ; Refresh
                                30m        ; Retry
                                1w         ; Expire
                                1h )       ; Negative Cache TTL
                NS      ns1
                NS      ns2
                
@               A       203.0.113.1
                AAAA    2001:db8:113::1
                MX      10 mail
                TXT     "v=spf1 mx"

www             A       203.0.113.1
                AAAA    2001:db8:113::1

ns1             A       203.0.113.4
                AAAA    2001:db8:113::4

ns2             A       198.51.100.5
                AAAA    2001:db8:5100::5

mail            A       198.51.100.6
                AAAA    2001:db8:5100::6
imap            CNAME   mail
smtp            CNAME   mail

$ORIGIN defines the default suffix for all names which do not already end with a . (dot), e.g. mail will be expanded to mail.$ORIGIN ⇒ mail.domain.tld. everywhere.

$TTL defines the default time-to-live (i.e. cache expiry time) for all records which do not have their own TTL specified. Here it is 2 hours.

Serial must be incremented manually before reloading named every time you change a resource record for the zone. Otherwise secondary servers (replicas or slaves) will not re-transfer the zone: they only do it if the serial is greater than that of the last time they transferred the zone. This example uses the somewhat common YYYYMMDDXX format, but this is not required; the serial number can also just start at 1.

Configuring master server

Add your zone to /etc/named.conf:

zone "domain.tld" IN {
        type master;
        file "domain.tld.zone";
        allow-update { none; };
};

Reload the named.service unit to apply the configuration change.

Allow recursion

If you are running your own DNS server, you might as well use it for all DNS lookups, or even #Serve the root zone locally by yourself. The former will require the ability to do recursive lookups. In order to prevent DNS Amplification Attacks, recursion is turned off by default for most resolvers. The default Arch /etc/named.conf file allows for recursion only on the loopback interface:

allow-recursion { 127.0.0.1; ::1; };

If you want to provide name service for your local network; e.g. 192.168.0.0/24, you must add the appropriate range of IP addresses to /etc/named.conf:

allow-recursion {
    192.168.0.0/24;
    fd01:2345:6789::/64;
    127.0.0.1;
    ::1;
};

Configuring BIND to serve DNSSEC signed zones

DNSSEC validation is enabled by default. Do not forget to check that «edns» is not disabled.

On master DNS server:

• generate KSK and ZSK keys:

 $ dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE example.com
 $ dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE example.com

• change zone configuration:

 zone "example.com" {
       type master;
       allow-transfer { ... };
       auto-dnssec maintain;
       inline-signing yes;
       key-directory "master/";
       file "master/example.com.zone";
 };

Now bind will sign zone automatically. (This example assumes that all required files are in /var/named/master/)

Then you should pass DS records (from dsset-example.com. file) to parent zone owner probably using your registrar website. It glues parent zone with your KSK.

KSK (and corresponding DS records) should be changed rarely because it needs manual intervention, ZSK can be changed more often because this key is usually shorter to be faster in signature checking.

You can schedule old ZSK key expiration and generate new one using:

 $ dnssec-settime -I +172800 -D +345600 Kexample.com.+000+111111.key
 $ dnssec-keygen -S Kexample.com.+000+111111.key -i 152800

Bind should automatically use new ZSK key at appropriate time.

There are external mechanisms such as OpenDNSSEC with fully-automatic key rollover available.

Automatically listen on new interfaces

By default bind scan for new interfaces and stop listening on interfaces which no longer exist every hour. You can tune this value by adding :

interface-interval <rescan-timeout-in-minutes>;

parameter into named.conf options section. Max value is 28 days. (40320 min)
You can disable this feature by setting its value to 0.

Then restart the service.

Running BIND in a chrooted environment

Running in a chroot environment is not required but improves security.

Creating the jail house

In order to do this, we first need to create a place to keep the jail, we shall use /srv/named, and then put the required files into the jail.

# mkdir -p /srv/named/{dev,etc,usr/lib/engines,var/{run,log,named}}

Copy over required system files:

# cp -av /etc/{localtime,named.conf} /srv/named/etc/
# cp -av /usr/lib/engines-1.1/* /srv/named/usr/lib/engines/
# cp -av /var/named/* /srv/named/var/named/.

Set up required nodes in /dev/:

# mknod /srv/named/dev/null c 1 3
# mknod /srv/named/dev/random c 1 8

Set ownership of the files:

# chown -R named:named /srv/named

This should create the required file system for the jail.

Service unit

Next we need a replacement unit file so that the service calls bind which will allow force bind into the chroot:

/etc/systemd/system/named-chroot.service

ExecStart=/usr/bin/named -4 -f -u named -t "/srv/named"

Now, reload systemd with daemon-reload, and start the named-chroot.service.

Serve the root zone locally

If you do not want to rely on third-party DNS services, you can serve the root zone locally following RFC:7706. This can be achieved by using BIND as a DNS recursive resolver.

To manage a recursive resolver, you typically need to configure a root hints file. This file contains the names and IP addresses of the authoritative name servers for the root zone.

Grab the file from IANA website and place it into /var/named. Alternatively, use iana-root-hints^AUR.

Edit your server config, adding the respective file:

/etc/named.conf

zone "." IN {
    type hint;
    file "named.root";
};

Recursion also should be allowed in the config. See #Allow recursion.

See also

• BIND 9 Administrator Reference Manual (ARM)
• BIND ARM on readthedocs
• BIND knowledgebase
• Internet Systems Consortium, Inc. (ISC)
• Pro DNS and BIND with abbreviated version online
• DNS Glossary^{[dead link 2020-03-28 ⓘ]}
• Archived mailing list discussion on BIND’s future
• root zone transfer made simple — serve root@home copy the /etc/named.conf , restart BIND & enjoy!
• DNSSEC
• a BIND configuration template

Background

Note: There are some issues with this Howto, too numerable to fix quickly, and it requires bringing up to standard. I’m mentioning this to help anyone to avoid the unnecessary time trying to resolve their DNS, owing the the inconsistencies in this document, particularly if you’re new to DNS configuration. One example is here…

box IN A 192.168.1.10

… in all other places, the document uses the machine name example ns. Here it changes to box (I believe the author was simply trying to show that additional computers would be listed, but failed to use a different address for box. I modified the example file to give box an address of 192.168.1.21).

Introduction

Domain Name Service (DNS) is an Internet service that maps IP addresses and fully qualified domain names (FQDN) to one another. In this way, DNS alleviates the need to remember IP addresses. Computers that run DNS are called name servers. Ubuntu ships with BIND (Berkley Internet Naming Daemon), the most widely deployed DNS server.

This guide is aimed at people looking to learn how to configure and maintain a DNS server, such as for a network (caching name server) or to serve DNS zones for a domain name.

Installation

BIND9 is available in the Main repository. No additional repository needs to be enabled for BIND9.

Before we begin, you should be familiar with RootSudo.

To install the server simply install the bind9 package. See InstallingSoftware for details on using package managers.

A very useful package for testing and troubleshooting DNS issues is the dnsutils package. Also, the BIND9 Documentation can be found in the bind9-doc package.

BIND9 Configuration Scenarios

BIND9 can provide many different DNS services.

Some of the most useful setups are:

Caching Server

In this configuration BIND9 will find the answer to name queries and remember the answer for the next query. This can be useful for a slow internet connection. By caching DNS queries, you will reduce bandwidth and (more importantly) latency.

Primary Master Server

BIND9 can be used to serve DNS records (groups of records are referred to as zones) for a registered domain name or an imaginary one (but only if used on a restricted network).

Secondary Master Server

A secondary master DNS server is used to complement a primary master DNS server by serving a copy of the zone(s) configured on the primary server. Secondary servers are recommended in larger setups. If you intend to serve a registered domain name they ensure that your DNS zone is still available even if your primary server is not online.

Hybrids

You can even configure BIND9 to be a Caching and Primary Master DNS server simultaneously, a Caching and a Secondary Master server or even a Caching, Primary Master and Secondary Master server. All that is required is simply combining the different configuration examples.

Stealth Servers

There are also two other common DNS server setups (used when working with zones for registered domain names), Stealth Primary and Stealth Secondary. These are effectively the same as Primary and Secondary DNS servers, but with a slight organizational difference.

For example, you have 3 DNS servers; A, B and C.

A is the Primary, B and C are secondaries.

If you configure your registered domain to use A and B as your domain’s DNS servers, then C is a Stealth Secondary. It’s still a secondary, but it’s not going to be asked about the zone you are serving to the internet from A and B

If you configure your registered domain to use B and C as your domain’s DNS servers, then A is a stealth primary. Any additional records or edits to the zone are done on A, but computers on the internet will only ever ask B and C about the zone.

DNS Record Types

There are lots of different DNS record types, but some of the most common types are covered below.

Address Records

The most commonly used type of record. This record maps an IP Address to a hostname.

www      IN    A      1.2.3.4

Alias Records

Used to create an alias from an existing A record. You can create a CNAME record pointing to another CNAME record. But it doubles the number of requests made to the nameserver, thus making it an inefficient way to do so.

mail     IN    CNAME  www
www      IN    A      1.2.3.4

Mail Exchange Records

Used to define where email should be sent to and at what priority. Must point to an A record, not a CNAME. Multiple MX records can exist if multiple mail servers are responsible for that domain.

        IN    MX  10    mail.example.com.

        [...]

mail    IN    A       1.2.3.4

Name Server Records

Used to define which servers serve copies of this zone. It must point to an A record, not a CNAME.

This is where Primary and Secondary servers are defined. Stealth servers are intentionally omitted.

        IN    NS     ns.example.com.

        [...]

ns      IN    A      1.2.3.4

Configuring BIND9

BIND9 Configuration files are stored in:

/etc/bind/

The main configuration is stored in the following files:

/etc/bind/named.conf
/etc/bind/named.conf.options
/etc/bind/named.conf.local

Caching Server configuration

The default configuration is setup to act as a caching server.

All that is required is simply adding the IP numbers of your ISP’s DNS servers.

Simply uncomment and edit the following in /etc/bind/named.conf.options:

        [...]

        forwarders {
             1.2.3.4;
             5.6.7.8;
        };

        [...]

(where 1.2.3.4 and 5.6.7.8 are the IP numbers of your ISP’s DNS servers)

Now restart the bind daemon:

sudo /etc/init.d/bind9 restart

Testing

If you installed the dnsutils package you can test your setup using the dig command:

dig -x 127.0.0.1

If all goes well you should see output similar to:

; <<>> DiG 9.4.1-P1 <<>> -x 127.0.0.1
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13427
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

[...]

;; Query time: 1 msec
;; SERVER: 172.18.100.80#53(172.18.100.80)
;; WHEN: Mon Nov 26 23:22:53 2007
;; MSG SIZE  rcvd: 93

The dig command can also be used to query other domains for example:

dig google.com

If you «dig» a domain name multiple times you should see a drastic improvement in the Query time: between the first and second query. This is due to the server caching the query.

Primary Master Server configuration

In this section BIND9 will be configured as the primary master for the domain example.com. Simply replace example.com with your fully qualified domain name.

Zone File

To add a DNS zone to BIND9, turning BIND9 into a Primary Master server, all you have to do is edit named.conf.local:

        [...]

        zone "example.com" {
             type master;
             file "/etc/bind/db.example.com";
        };

        [...]

Now use an existing zone file as a template:

sudo cp /etc/bind/db.local /etc/bind/db.example.com

Edit the new zone file /etc/bind/db.example.com change localhost. to the FQDN of your server, leaving the additional «.» at the end. Change 127.0.0.1 to the nameserver’s IP Address and root.localhost to a valid email address, but with a «.» instead of the «@». also leaving the «.» at the end.

Also, create an A record for ns.example.com the name server in this example:

;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     ns.example.com. root.example.com. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns.example.com.
ns      IN      A       192.168.1.10

;also list other computers
box     IN      A       192.168.1.21

You must increment the serial number every time you make changes to the zone file. If you make multiple changes before restarting BIND9, simply increment the serial once.

Now, you can add DNS records to the bottom of the zone.

Tip: Many people like to use the last date edited as the serial of a zone, such as  2005010100  which is yyyymmddss (where s is serial)

Once you’ve made a change to the zone file BIND9 will need to be restarted for the changes to take effect:

sudo /etc/init.d/bind9 restart

Reverse Zone File

Now that the zone file is setup and resolving names to IP Adresses a Reverse zone is also required. A Reverse zone allows DNS to convert from an address to a name.

Edit /etc/bind/named.conf.local and add the following:

zone "1.168.192.in-addr.arpa" {
        type master;
        notify no;
        file "/etc/bind/db.192";
};

Note: replace 1.168.192 with the first three octets of whatever private network you are using. Also, name the zone file db.192 in the example appropriately.

Now create the db.192 file:

sudo cp /etc/bind/db.127 /etc/bind/db.192

Next edit /etc/bind/db.192 changing the basically the same options as in /etc/bind/db.example.com:

;
; BIND reverse data file for local loopback interface
;
$TTL    604800
@       IN      SOA     ns.example.com. root.example.com. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns.
10      IN      PTR     ns.example.com.

; also list other computers
21      IN      PTR     box.example.com.

The serial number in the reverse zone needs to be incremented on each changes as well. For each A record you configure in /etc/bind/db.example.com you need to create a PTR record in /etc/bind/db.192.

After creating the reverse zone file restart bind9:

sudo /etc/init.d/bind9 restart

Testing

You should now be able to ping example.com and have it resolve to the host configured above:

ping example.com

You can also use the named-checkzone utility that is part of the bind9 package:

named-checkzone example.com /etc/bind/db.example.com

and

named-checkzone 1.168.192.in-addr.arpa. /etc/bind/db.192

This is a great way to make sure you haven’t made any mistakes before restarting bind9.

You can use the dig utility to test the reverse zone as well as the new domain name:

dig 1.168.192.in-addr.arpa. AXFR

You should see output resolving 1.168.192.in-addr.arpa. to your nameserver.

Secondary Master Server configuration

Once a Primary Master has been configured a Secondary Master is needed in order to maintain the availability of the domain should the Primary become unavailable.

First, on the primary master server, the zone transfer needs to be allowed. Add the allow-transfer option to the sample Forward and Reverse zone definition in /etc/bind/named.conf.local:

        [...]

        zone "example.com" {
             type master;
             file "/etc/bind/db.example.com";
             allow-transfer { @ip_secondary; };
        };

        [...]

        zone "1.168.192.in-addr.arpa" {
             type master;
             notify no;
             file "/etc/bind/db.192";
             allow-transfer { @ip_secondary; };
        };

       [...]

Note: replace @ip_secondary with the actual IP Address of your secondary server.

Next, on the Secondary Master, install the bind9 package the same way as the primary. Then edit the /etc/bind/named.conf.local and add the following declarations for the Forward and Reverse zones:

        [...]

        zone "example.com" {
             type slave;
             file "/var/cache/bind/db.example.com";
             masters { @ip_master; };
        };

        [...]

        zone "1.168.192.in-addr.arpa" {
             type slave;
             file "/var/cache/bind/db.192";
             masters { @ip_master; };
        };

        [...]

Note: replace @ip_master with the IP Address of the Primary. The zone file must be in /var/cache/bind/ because, by default, AppArmor only allows write access inside it (this was made specifically for a slave configuration. See AppArmor’s configuration in /etc/apparmor.d/usr.sbin.named).

Restart the server, and in /var/log/syslog you should see something similar to:

syslog.5.gz:May 14 23:33:53 smith named[5064]: zone example.com/IN: transferred serial 2006051401
syslog.5.gz:May 14 23:33:53 smith named[5064]: transfer of 'example.com/IN' from 10.0.0.202#53: end of transfer
syslog.5.gz:May 14 23:33:35 smith named[5064]: slave zone "1.168.192.in-addr.arpa" (IN) loaded (serial 2006051401)

Note: A zone is only transfered if the Serial Number on the Primary is larger than the one on the Secondary.

Testing

Testing the Secondary Master can be done using the same methods as the Primary. Also, you could shutdown BIND9 on the Primary then try pinging example.com from a host configured to use the Secondary as well as the Primary for name resolution. If all goes well the Secondary should resolve example.com.

Chrooting BIND9

Chrooting BIND9 is a recommended setup from a security perspective if you don’t have AppArmor installed. In a chroot enviroment, BIND9 has access to all the files and hardware devices it needs, but is unable to access anything it should not need. AppArmor is installed by default on recent Ubuntu releases. Unless you’ve explicitly disabled AppArmor, you might want to read this before you decide to attempt a chrooted bind. If you still want to go forward with it, you’ll need this information, which isn’t covered in the instructions that follow here.

To chroot BIND9, simply create a chroot enviroment for it and add the additional configuration below

The Chroot Enviroment

Create the following directory structure

$ sudo mkdir -p /chroot/named
$ cd /chroot/named
$ sudo mkdir -p dev etc/namedb/slave var/run

Set permissions for chroot environment

$ sudo chown root:root /chroot
$ sudo chmod 700 /chroot
$ sudo chown bind:bind /chroot/named
$ sudo chmod 700 /chroot/named

Create or move the bind configuration file.

$ sudo touch /chroot/named/etc/named.conf

or

$ sudo cp /etc/bind/named.conf /chroot/named/etc

Give write permissions to the user bind for /chroot/named/etc/namedb/slave directory.

$ sudo chown bind:bind /chroot/named/etc/namedb/slave

This is where the files for all slave zones will be kept. This increases security, by stopping the ability of an attacker to edit any of your master zone files if they do gain access as the bind user. Accordingly, all slave file names in the /chroot/named/etc/named.conf file will need to have directory names that designate the slave directory. An example zone definition is listed below.

zone "my.zone.com." {
        type slave;
        file "slaves/my.zone.com.dns";
        masters {
                10.1.1.10;
        };
};

Create the devices BIND9 requires

$ sudo mknod /chroot/named/dev/null c 1 3
$ sudo mknod /chroot/named/dev/random c 1 8

Give the user bind access to the /chroot/named/var/run directory that will be used to strore PID and statistical data.

$ sudo chown bind:bind /chroot/named/var/run

BIND9’s Configuration

Edit the bind startup options found in /etc/default/bind9. Change the line the reads:

/etc/default/bind9:

OPTIONS="-u bind"

So that it reads

/etc/default/bind9:


OPTIONS="-u bind -t /chroot/named -c /etc/named.conf"

The -t option changes the root directory from which bind operates to be /chroot/named. The -c option tells Bind that the configuration file is located at /etc/named.conf. Remember that this path is relative to the root set by -t.

The named.conf file must also recieve extra options in order to run correctly below is a minimal set of options:

/chroot/named/etc/named.conf:

options {
    directory "/etc/namedb";
    pid-file "/var/run/named.pid";
    statistics-file "/var/run/named.stats";
};

Ubuntu’s syslod Daemon Configuration

/etc/init.d/sysklogd:


        [...]

SYSLOGD="-u syslog -a /chroot/named/dev/log"

        [...]

(Author Note: Check this config)

Restart the syslog server and BIND9

$ sudo /etc/init.d/sysklogd restart
$ sudo /etc/init.d/bind9 restart

At this point you should check /var/log/messages for any errors that may have been thrown by bind.

Starting, Stopping, and Restarting BIND9

Use the following command to start BIND9 :

$ sudo /etc/init.d/bind9 start

To stop it, use :

$ sudo /etc/init.d/bind9 stop

Finally, to restart it, run

$ sudo /etc/init.d/bind9 restart

Status

To check the status of your BIND9 installation:

$ host localhost

or

$ dig @localhost

(where localhost is the system you are setting BIND9 up on. If not localhost, use the appropriate IP number.)

Logging

BIND9 has a wide variety of logging configuration options available. There are two main options to BIND9 logging the channel option configures where logs go, and the category option determines what to log.

If no logging option is configured for the default option is:

logging {
     category default { default_syslog; default_debug; };
     category unmatched { null; };
};

Next we will configure BIND9 to send debug messages related to DNS queries to a separate file.

Channel Option

First, we need to configure a channel to specify which file to send the messages to. Edit /etc/bind/named.conf.local and add the following:

logging {
    channel query.log {
        file "/var/log/query.log";
        // Set the severity to dynamic to see all the debug messages.
        severity dynamic;
    };
};

Category Option

Next, configure a category to send all DNS queries to the query file:

logging {
    channel query.log {
        file "/var/lib/bind/query.log";
        // Set the severity to dynamic to see all the debug messages.
        severity debug 3;
    };

    category queries { query.log; };
};

Note: the debug option can be set from 1 to 3. If a level isn’t specified level 1 is the default.

Now restart BIND9 for the changes to take affect:

sudo /etc/init.d/bind9 restart

You should see the file /var/log/query.log fill with BIND9 log information. This is a simple example of the BIND9 logging options available see bind9.net manual for more information.

Additional Possibilities

You can monitor your BIND9 server usage by installing the bindgraph package from the Universe (To enable Universe — see AddingRepositoriesHowto) and following configuration details as outlined in bindgraph’s README documents

Further Information

Online Recources

«ISC’s BIND9 Manual»

TLDP’s «DNS HOWTO» (For General Overview)

«Chroot BIND Howto»

Debian BIND Wiki

BIND reference guide

Printed Resources

«DNS & BIND» — Paul Albitz & Cricket Liu — 5th Edition — «O’Reilly Press» (Amazon.com)

DNS & BIND Cookbook — Cricket Liu — 4th Edition — «O’Reilly Press» (Amazon.com)

CategoryNetworking CategoryInternet

DNS (Domain Name System, система доменных имён) — система, в которой все доменные имена серверов находятся в определённой иерархии. Для чего она нужна? 

Представим, что нам нужно обратиться к устройству с IP-адресом 92.53.116.191. Чтобы это сделать мы можем ввести адрес в командной строке и получить нужную информацию. Но запомнить много таких комбинаций цифр очень трудно. Поэтому были придуманы специальные серверы, которые позволяют преобразовывать доменные имена в IP-адреса. Так, когда вы вводите в поисковой строке браузера cloud.timeweb.com, данные запроса отправляются на DNS-сервер, который ищет совпадения в своей базе. Затем DNS-сервер посылает на устройство нужный IP-адрес и только тогда браузер обращается непосредственно к ресурсу.

Настройка собственной DNS позволяет более гибко и точно конфигурировать систему и не зависеть от третьих лиц. В этой статье мы рассмотрим, как настроить DNS с помощью сервера имён BIND на Ubuntu. 

Термины

Зона — часть иерархии доменных имён, которая размещается на DNS-сервере. Она нужна для того, чтобы установить рамки, в пределах которых распространяется ответственность конкретного сервера или группы серверов. 

Корневые серверы — это DNS-серверы, которые содержат информацию о доменах первого уровня (.ru, .com и так далее). 

Доменом называют именованную часть в иерархии DNS. Это определённый узел, который включает в себя другие узлы. DNS-адреса читаются справа налево и начинаются с точки, точкой также отделяются домены.То есть домен cloud.timeweb.com правильно читать так: .com.timeweb.cloud. Чаще всего доменное имя отражает структуру иерархии DNS, но последняя точка опускается. 

FQDN — это имя полное имя домена, которое включает в себя имена всех родительских доменов. 

Ресурсная запись — это единица хранения информации. Проще говоря, это запись, которая содержит связь имени с какой-либо служебной информацией. Ресурсная запись состоит из следующих элементов:

1. Имя (NAME) — имя или IP-адрес, которому принадлежит зона. 
2. Время жизни (Time to Live, TTL) — время хранения записи в кэше DNS, по прошествии которого запись удаляется. 
3. Класс (CLASS) — тип сети, чаще всего IN — Internet.
4. Тип (TYPE) — назначение записи
5. Различная информация (DATA)

Самые частые ресурсные записи

A-запись. Имя хоста на адрес IPv4. Для каждого сетевого интерфейса можно сделать только одну A-запись. 

timeweb.com.              86400     IN     A      185.114.246.105

AAAA-запись. Это то же самое, что А-запись, только справедливо для IPv6.

CNAME. Каноническая запись. Содержит псевдоним реального имени для перенаправления.

ftp             86400   IN      CNAME       store.cloud.timweb.com.

MX. Указывает хосты для доставки почты, адресованной домену. Поле NAME содержит домен назначения, а поле DATA — приоритет и хост для приёма почты. 

website.ru.             17790   IN      MX      10 mx.website.ru.
website.ru.             17790   IN      MX      20 mx2.website.ru.

NS. Указывает на DNS-сервер, которым обслуживается домен. 

PTR. IP-адрес в доменное имя. Необходимо для обратного преобразования имён.

SOA. Описывает основные настройки зоны.

SRV. Содержит адреса серверов, которые обеспечивают работу внутренних служб домена. Например, Jabber.

Инфраструктура

Для того, чтобы следовать всем инструкциям в статье, вам необходимо иметь как минимум два сервера Ubuntu в одном ЦОД. Любой из этих серверов вы можете заказать на cloud.timeweb.com.

Нам понадобится два сервера на Ubuntu 18.04, они будут использоваться в качестве первичного и вторичного DNS-серверов — ns1 и ns2 соответственно. А также дополнительные серверы, которые будут использовать наши настроенные серверы. 

Вы должны иметь права суперпользователя на каждом из серверов. Чтобы узнать, как это получить административные доступ, воспользуйтесь статьёй в нашем блоге — Редактирование файла sudoers.

В этой статье мы будем использовать bind в качестве DNS-сервера. Установим пакет bind9 из репозитория Linux:

sudo apt update && sudo apt upgrade -y
sudo apt install bind9

Кроме этого рекомендуем установить сразу инструменты мониторинга сети: 

sudo apt install dnsutils

После установки запускаем службу bind9:

sudo service bind9 start

Основной конфигурационный файл сервера — /etc/bind/named.conf. Он описывает общие настройки и обычно разбивается на несколько других для удобства. С работы с параметрами внутри этого файла начинается настройка DNS.

named.conf.options. Этот файл содержит общие параметры сервера. В нём укажем данные для конфигурации DNS.

options {
        dnssec-validation auto;
        auth-nxdomain no;
        directory "/var/cache/bind";
        recursion no; # запрещаем рекурсивные запросы на сервер имён
        listen-on {
                     172.16.0.0/16; 
                     127.0.0.0/8;    };
        forwarders { 
172.16.0.1;
            8.8.8.8;  
        };
};

Чтобы проверить, что всё внесено верно, нужно воспользоваться одной из утилит демона named — named-checkconf.

sudo named-checkconf

Если всё написано верно, bind-сервер начал работать. 

Первичный DNS-сервер

Первичный DNS-сервер — сервер, который хранит главную копию файла данных зоны. Все зоны будем хранить в каталоге /etc/bind/master-zones основного DNS-сервера. Создадим директорию:

sudo mkdir /etc/bind/master-zones

В ней создадим файл для описания зоны:

sudo touch /etc/bind/master-zones/test.example.com.loсal.zone

… и добавим в него SOA-, NS- и A-записи:

$ttl 3600 
$ORIGIN test.example.com. 
test.example.com.               IN              SOA  (      
ns.test.example.com.    
abuse.test.example.com.  
                                2022041201 
                                10800 
                                1200 
                                604800 
                                3600   ) 
@                               IN              NS              ns.test.example.com. 
@                               IN              NS              ns2.test.example.com.
@                               IN              A                172.16.101.3 
ns                              IN               A                172.16.0.5 
ns2                             IN              A                172.16.0.6

После этого необходимо запустить проверку утилитой named-checkzone.

sudo named-checkzone test.example.com. /etc/bind/master-zones/test.example.com.loсal.zone

named.conf.local. Это ещё один файл, который включается в общий конфиг сервера. В нём мы укажем локальные зоны:

zone "test.example.com." {
                type master;
                file "/etc/bind/master-zones/test.example.com.local.zone";
};

После того, как пропишем нужные данные, проверим конфиг и перезагрузим bind9 (флаг -z проверяет файлы зон):

sudo named-checkconf
sudo named-checkconf -z
sudo service bind9 restart
sudo service bind9 status

Настройка представлений

Настройка представлений позволяет гибко управлять разрешением имён из разных подсетей. В файле /etc/bind/named.conf укажем:

include "/etc/bind/named.conf.options";
acl "local" { 172.16.0.0/16; };
view "local" {
                include "/etc/bind/named.conf.local";
                match-clients { local; };
};

В этом же файле можно прописать директивы для указания тех узлов и адресов сетей, от которых нужно принимать или отклонять запросы.

Затем нужно заново перезагрузить bind9:

sudo service bind9 restart

После перезагрузки сервера с другого компьютера локальной сети можно запросить наличие у сервера 172.16.0.5 SOA-записи: 

dig @172.16.0.5 -t SOA test.example.com

На этом этапе настройка основного DNS-сервера завершена. Далее в статье — вторичный сервер, настройка почтового сервера и обратная зона. 

Вторичный сервер

Первые шаги абсолютно такие же, что и в случае с первичным сервером — установка bind9 и сетевых утилит.

sudo apt update && sudo apt upgrade -y
sudo apt install bind9
sudo apt install dnsutils
sudo service bind9 start

Далее для того, чтобы хранить файлы зон, создадим каталог /etc/bind/slave и снабдим его необходимыми правами:

sudo mkdir slave
sudo chmod g+w slave

Приступаем к настройке зоны на вторичном сервере. В файл /etc/bind/named.conf.local добавляем зону

zone "test.example.com." {
        type slave;
        file "/etc/bind/slave/test.example.com.local.zone";
        masters { 172.16.0.5; };
};

… и в основном конфигурационном файле named.conf настраиваем представления 

include "/etc/bind/named.conf.options";
acl "local" { 172.16.0.0/16; };
view "local" {
        match-clients { local; };
        include "/etc/bind/named.conf.local";
};

После добавления настроек нужно проверить синтаксис, а затем перезагрузить bind9:

sudo named-checkconf
sudo named-checkconf -z
sudo service bind9 restart

Если нет ошибок, нужно выполнить трансфер зоны:

sudo rndc retransfer test.example.com

Команда rndc retransfer позволяет выполнить трансфер зоны без проверки серийных номеров. Вкратце, первичный (ns1) и вторичный (ns2) DNS-серверы работают следующим образом. ns2 «смотрит» только на серийный номер зоны, игнорируя содержание всего файла. 

Если номер уменьшился, то трансфер этой зоны будет прекращён. Поэтому каждый раз при редактировании зоны критически важно увеличивать серийный номер. В качестве номера рекомендуем использовать текущую дату и некий инкремент. 

Как только настроили сервер и выполнили трансфер зоны, в конфиге named.conf на первичном сервере нужно ограничить передачу адресом вторичного сервера. Для этого в named.conf нужно добавить директиву allow-transfer с указанием IP-адреса вторичного DNS-сервера.

И перезагружаем сервер:

sudo service bind9 restart

Далее все операции будем проводить на первичном сервере. 

Добавление MX-записи

В этом примере мы используем mx в качестве имени хоста, поскольку это общепринятое обозначение. Тогда FQDN — mx.test.example.com. 

В файл зоны /etc/bind/master-zones/test.example.com.loсal.zone добавляем ресурсные записи почты и обновляем серийный номер.

Проверим синтаксис и перезапустим bind9:

sudo named-checkzone test.example.com. /etc/bind/master-zones/test.example.com.local.zone
sudo service bind9 reload

Обратная зона

Обратная зона DNS — это особая доменная зона, которая предназначена для того, чтобы определять имя узла по его IP адресу. Например, адрес узла 192.168.1.10 в обратной нотации превращается в 10.1.168.192.in-addr.arpa. Благодаря тому, что используется иерархическая модель, можно делегировать управление зоной владельцу диапазона IP-адресов. 

По своей сути, PTR-запись определяет домен по адресу, а значит это практически то же самое, что и A-запись. Она используется в основном для проверки почтовых серверов.

Для настройки зоны обратного просмотра создадим новый файл зоны:

sudo nano /etc/bind/master-zones/16.172/in-addr.arpa.zone

и поместим в него следующее содержимое:

$TTL    3600 
16.172.in-addr.arpa.            IN      SOA  ( 
ns.test.example.com. 
admin.test.example.com. 
                                2022041202 
                                10800 
                                1200 
                                604800 
                                3600  )
                                IN      NS            ns.test.example.com. 
                                IN      NS           ns2.test.example.com. 
3.101.16.172.in-addr.arpa.      IN      PTR              test.example.com. 
5.0.16.172.in-addr.arpa.        IN      PTR           ns.test.example.com. 
6.0.16.172.in-addr.arpa.        IN      PTR          ns2.test.example.com. 
2.101.16.172.in-addr.arpa.      IN      PTR         mail.test.example.com.

Проверим зону и убедимся в корректности конфигурации:

sudo named-checkzone 16.172.in-addr.arpa /etc/bind/master-zones/16.172.in-addr.arpa.zone

Теперь эту зону нужно добавить в конфигурационный файл named.conf:

sudo nano /etc/bind/named.conf.local

zone "16.172.in-addr.arpa." {
                type master;
                file "/etc/bind/master-zones/16.172.in-addr.arpa.zone";
                allow-transfer { 172.16.0.6; };
        };

После этого проверяем синтаксис и перезагружаем bind9.

Можно приступать к аналогичной настройке на вторичном сервере. В named.conf.local добавьте следующую конфигурацию:

zone "16.172.in-addr.arpa." { 
        type slave; 
        file "/etc/bind/slave/16.172.in-addr.arpa.zone"; 
        masters { 172.16.0.5; }; 
};

На этом этапе мы завершили работу с локальными доменными зонами. Можно приступать к конфигурации внешней доменной зоны. 

Внешняя доменная зона

Во-первых, для того, чтобы запросы из внешней сети обрабатывались нашим сервером нужно в файле конфигурации named.conf.options добавить внешний адрес в директиву listen-on:

...
listen-on {
    aaa.bbb.ccc.ddd/32; # наш внешний IP
    172.16.0.0;
    127.0.0.0/8
}
…

Далее создадим файл зоны (не забудьте изменить серийный номер!) и добавим в него внешние IP-адреса. 

sudo nano /etc/bind/master-zones/test.example.com.zone

$ttl 3600
$ORIGIN test.example.com.
test.example.com.               IN              SOA  (     
ns.test.example.com.
admin.test.example.com.
                                2022041205
                                10800
                                1200
                                604800
                                3600   )
@                               IN              NS              ns.test.example.com.
@                               IN              NS              ns2.test.example.com.
@                               IN              A               aaa.bbb.ccc.ddd # первый внешний адрес
ns                              IN              A               aaa.bbb.ccc.ddd
ns2                             IN              A               eee.fff.ggg.hhh # второй внешний адрес

Затем создадим для зон внешнего просмотра отдельный файл, чтобы раздавать разные доменные зоны клиентам из разных подсетей. 

sudo nano /etc/bind/named.conf.external

И добавим в него следующее содержимое:

zone "test.example.com." { 
                type master; 
                file "/etc/bind/master-zones/test.example.com.zone";
                allow-transfer { 172.16.0.6; };
};

После этого подключим файл в named.conf, добавив такой блок:

acl "external-view" { aaa.bbb.ccc.ddd; };
view "external-view" {
                       recursion no;
                       match-clients { external-view; };
                       include "/etc/bind/named.conf.external";
};

Осталось проверить эту зону и перезагрузить bind9:

sudo named-checkconf -z
sudo named-checkzone test.example.com. /etc/bind/master-zones/test.example.com.zone
sudo service bind9 restart
sudo service bind9 status

На вторичном DNS-сервере в named.conf.options нам нужно указать внешний адрес сервера:

sudo nano /etc/bind/named.conf.options

options {
        dnssec-validation auto;
        auth-nxdomain no;
        recursion no;
        directory "/var/cache/bind";
        listen-on {
                        eee.fff.ggg.hhh/24;
                        172.16.0.0/16;
                        127.0.0.0/8;
        };
};

И точно так же, как на первой машине, создаём новый файл named.conf.external:

sudo nano /etc/bind/named.conf.external

Со следующим содержимым:

zone "test.example.com." {
        type slave;
        file "/etc/bind/slave/test.example.com.zone"; 
        masters { 172.16.0.5; };
};

Далее в named.conf добавляем следующий блок:

acl "external-view" { eee.fff.ggg.hhh; }; 
view "external-view" { 
        recursion no; 
        match-clients { external-view; }; 
        include "/etc/bind/named.conf.external"; 
};

И выполняем трансфер:

sudo rndc retransfer test.example.com IN external-view

Отладка

При настройке DNS-сервера очень важно внимательно отнестись к журналированию запросов. Это поможет при отладке на начальных стадиях, а во время полноценной работы сервера вы сможете в полной мере контролировать работу служб.

Bind9 позволяет полноценно настраивать правила журналирования — писать в один файл, разные категории помещать в разные журнал и так далее. 

Для того, чтобы записать отладочную информацию в один файл, нужно создать правила журналирования и подключить их в основной конфиг. Для этого создадим файл log.conf:

sudo nano /etc/bind/log.conf

И поместим в него содержимое:

logging {
    channel bind.log {
        file "/var/lib/bind/bind.log" versions 10 size 20m;
        severity debug;
        print-category yes;
        print-severity yes;
        print-time yes;
    };
        category queries { bind.log; };
        category default { bind.log; };
        category config { bind.log; };
};

После этого подключим файл в основной конфиг:

include "/etc/bind/log.conf"

И перезагрузим bind9:

sudo service bind9 restart

Можно создать несколько таких файлов с разными настройками и подключать их  в зависимости от стадии разработки или нагрузки на сервер. 

Заключение

Теперь вы сможете самостоятельно сконфигурировать систему так, чтобы обращаться к реусрсам по имени, а не по IP-адресу. Для этого в качестве примера мы настроили на сервере с OS Ubuntu dns с помощью пакета bind9.

Однако теперь вы должны внимательно следить за основным и вторичным серверами, поскольку они обрабатывают DNS-запросы внутри системы. 

Translation(s): English — French

Introduction

Putting a DNS server on a network allows for the replacement of IP addresses of individual machines by a name. As a result, it’s even possible to associate multiple names to the same machine to update the different available services. For example, www.example.com and pop.example.com, could both point to the primary server where the mail server and the business intranet reside, and the domain could be example.com. It’s easy to remember that these two services are running on the same machine whose IP address is 192.168.0.1.

Now imagine that our network administrator decides for some reason or another to move the mail server to the machine 192.168.0.11. The only thing that has to be changed is the DNS server configuration file. You could always go and modify the host configuration for all the users, but that would be time consuming and inconvenient.

Definitions

• DNS : Domain Name System or Domain Name Server

• Primary Server :

• Secondary server :

• Server cache :

Network Layout

We get internet access through an xxxbox (192.168.1.1), two DNS servers provided by our ISP (80.10.249.2, 80.10.246.129). In fact, these two latter servers will ever be referred to in the configuration because the xxxbox will be in charge of resolving names if the packet destination isn’t known. Consequently, I consider the xxxbox like a primary server outside of our domain. The “sid” server (192.168.1.10) is connected to the xxxbox via its primary network card. It’s also connected to the LAN (192.168.0.0/24) by its secondary network interface(192.168.0.1). It’s on this that we are going to install the primary DNS server for our domain example.com (rfc2606) All the computers on the LAN are automatically assigned a single address by the DHCP service. The DHCP also provides the primary DNS server’s address for our domain, and updates the host names for the zone example.com so they can be associated with an ip address.

Server Management

Installation

The package bind9 will be used for installation.

# apt-get install bind9 

and then if you want to also install the documentation (very useful):

# apt-get install bind9-doc

Configuration

After installation, you might want to get familiar with some of the configuration files. They are in the directory /etc/bind/

TSIG Signature

The purpose of this signature is to authenticate transactions with BIND. Thus, the DHCP server cannot update the example.com domain if it loses this key. Copy and paste an existing key

# cd /etc/bind/
# cat rndc.key
key "rndc-key" {
        algorithm hmac-md5;
        secret "QJc08cnP1xkoF4a/eSZZbw==";
};

# cp rndc.key ns-example-com_rndc-key

You can generate a new key with the following options:

• algorithm HMAC-MD5 — identifies 157 (required for a TSIG signature and only algorithm supported by BIND)

• length of 512 octets (multiple of 64 with a maximum length of 512 for the above algorithm)

• name : ns-example-com_rndc-key

dnssec-keygen -a HMAC-MD5 -b 512 -n USER ns-example-com_rndc-key
Kns-example-com_rndc-key.+157+53334

The footprint associated with the key is 53334. We get two files, one with an extension key and the other with a private extension. This substitutes the key in the file ns-example-com_rndc-key with the one in one of these two files.

# cat Kns-example-com_rndc-key.+157+53334.private
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: LZ5m+L/HAmtc9rs9OU2RGstsg+Ud0TMXOT+C4rK7+YNUo3vNxKx/197o2Z80t6gA34AEaAf3F+hEodV4K+SWvA==
Bits: AAA=

# cat ns-example-com_rndc-key
key "ns-example-com_rndc-key" {
        algorithm hmac-md5;
        secret "LZ5m+L/HAmtc9rs9OU2RGstsg+Ud0TMXOT+C4rK7+YNUo3vNxKx/197o2Z80t6gA34AEaAf3F+hEodV4K+SWvA==";
};

The file ns-example-com_rndc-key should not be made world readable for security reasons. This should be inserted into the bind configuration by an include because the bind configuration itself is world-readable. Also, it’s a good idea to delete the key and private files generated before.

File /etc/bind/named.conf

This file is the main configuration file for the DNS file.

// Managing acls
acl internals { 127.0.0.0/8; 192.168.0.0/24; };

// Load options
include "/etc/bind/named.conf.options";

// TSIG key used for the dynamic update
include "/etc/bind/ns-example-com_rndc-key";

// Configure the communication channel for Administrative BIND9 with rndc
// By default, they key is in the rndc.key file and is used by rndc and bind9 
// on the localhost
controls {
        inet 127.0.0.1 port 953 allow { 127.0.0.1; };
};

// prime the server with knowledge of the root servers
zone "." {
        type hint;
        file "/etc/bind/db.root";
};

include "/etc/bind/named.conf.default-zones";
include "/etc/bind/named.conf.local";

Note : with Debian Jessie the ‘zone «.» {…}’ part is inside the file «named.conf.default-zones». You don’t need to add it in the file «named.conf».

File /etc/bind/named.conf.default-zones

Note: as of Debian 7 «Wheezy» bind9 ships with a file containing default forward, reverse, and broadcast zones.

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
        type master;
        file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
        type master;
        file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
        type master;
        file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
        type master;
        file "/etc/bind/db.255";
};

File /etc/bind/named.conf.options

This file contains all the configuration options for the DNS server

options {
        directory "/var/cache/bind";

        // Exchange port between DNS servers
        query-source address * port *;

        // Transmit requests to 192.168.1.1 if
        // this server doesn't know how to resolve them
        forward only;
        forwarders { 192.168.1.1; };

        auth-nxdomain no;    # conform to RFC1035

        // From 9.9.5 ARM, disables interfaces scanning to prevent unwanted stop listening
        interface-interval 0;
        // Listen on local interfaces only(IPV4)
        listen-on-v6 { none; };
        listen-on { 127.0.0.1; 192.168.0.1; };

        // Do not transfer the zone information to the secondary DNS
        allow-transfer { none; };

        // Accept requests for internal network only
        allow-query { internals; };

        // Allow recursive queries to the local hosts
        allow-recursion { internals; };

        // Do not make public version of BIND
        version none;
};

The port associated with the query-source option must not in any case be frozen because it jeopardizes the DNS transactions in the case of a resolver.

• Vulnerability Note VU#800113

• Bind9 DNS Cache Poisoning

M. Rash wrote an interesting article about this and how to force the source port randomly via the iptables: Mitigating DNS Cache Poisoning Attacks with iptables

To reduce the delay timeout for UDP connections, and thus highlight the randomization, which by default is 30s by tuple, simply update the parameter net.netfilter.nf_conntrack_udp_timeout

# sysctl -w net.netfilter.nf_conntrack_udp_timeout=10

to get timeout of 10s.

File /etc/bind/named.conf.local

This file contains the local DNS server configuration, and this is where you declare the zones associated with this server’s domain(s).

// Manage the file logs
include "/etc/bind/named.conf.log";

// Domain Management example.com
// ------------------------------
//  - The server is defined as the master on the domain.
//  - There are no forwarders for this domain.
//  - Entries in the domain can be added dynamically 
//    with the key ns-example-com_rndc-key
zone "example.com" {
        type master;
        file "/var/lib/bind/db.example.com";
        //forwarders {};
        // If we do not comment the ''forwarders'' "empty" clients of the local subnet in my case don't have access to the upstream DNS ?
        //allow-update { key ns-example-com_rndc-key; };
        allow-update { key rndc-key; };
        //confusion between the file name to import (ns-example-com_rndc-key) and the key label (rndc-key) ?
};
zone "0.168.192.in-addr.arpa" {
        type master;
        file "/var/lib/bind/db.example.com.inv";
        //see comment below (zone "example.com")
        //forwarders {};
        //allow-update { key ns-example-com_rndc-key; };
        allow-update { key rndc-key; };
};

// Consider adding the 1918 zones here, if they are not used in your
// organization
include "/etc/bind/zones.rfc1918";

NOTE: if you create a local non-FQDN and call it .local it clashes with some other packages (which?). Edit /etc/nsswitch.conf and move dns right after the files on the host line makes .local domains work.

File /etc/bind/named.conf.log

With Debian Jessie, you need to create this file in /etc/bind

logging {
        channel update_debug {
                file "/var/log/update_debug.log" versions 3 size 100k;
                severity debug;
                print-severity  yes;
                print-time      yes;
        };
        channel security_info {
                file "/var/log/security_info.log" versions 1 size 100k;
                severity info;
                print-severity  yes;
                print-time      yes;
        };
        channel bind_log {
                file "/var/log/bind.log" versions 3 size 1m;
                severity info;
                print-category  yes;
                print-severity  yes;
                print-time      yes;
        };

        category default { bind_log; };
        category lame-servers { null; };
        category update { update_debug; };
        category update-security { update_debug; };
        category security { security_info; };
};

Here we define different log methods for the different categories. The first category is, as its name indicates the default category that is usually assigned to syslog. All categories not mentioned, are similar to the default category. For a list of the different categories, see the bind9 administrator reference manual. In terms of blade-servers, it ignores all the logs associated with them. It may be necessary to create /var/log in the chroot later.

Resource Records (RR)

DNS is made up of several registrations, RR or Resource Records, defining the various domain information. The first is dedicated to name resolution, in our case, it is the file db.example.com. The second will be used for reverse name resolution, it is the file db.example.com.inv.

Files in /var/lib/bind/

• RR for name resolution (db.example.com file)

$TTL    3600
@       IN      SOA     sid.example.com. root.example.com. (
                   2007010401           ; Serial
                         3600           ; Refresh [1h]
                          600           ; Retry   [10m]
                        86400           ; Expire  [1d]
                          600 )         ; Negative Cache TTL [1h]
;
@       IN      NS      sid.example.com.
@       IN      MX      10 sid.example.com.

sid     IN      A       192.168.0.1
etch    IN      A       192.168.0.2

pop     IN      CNAME   sid
www     IN      CNAME   sid
mail    IN      CNAME   sid

• RR for inverse name resolution (db.example.com.inv file)

@       IN      SOA     sid.example.com. root.example.com. (
                   2007010401           ; Serial
                         3600           ; Refresh [1h]
                          600           ; Retry   [10m]
                        86400           ; Expire  [1d]
                          600 )         ; Negative Cache TTL [1h]
;
@       IN      NS      sid.example.com.

1       IN      PTR     sid.example.com.
2       IN      PTR     etch.example.com.

Some Explanations :

$TTL : (Time To Live) expresses the duration (in seconds) validity, by default, of the information contained in the RRs. Once this time expires, it is necessary to recheck the data. Types :

• SOA : Show romanization

to define information about the area. In this case the name of the primary DNS server «sid.example.com.» and the email address of technical contact (root.example.com.; the @ is replaced by a dot). It is composed of several fields:

• 1. Serial : is the whole non-signed 32 bits. This is the serial number to increment with each change of file. It allows the secondary server to reload the information they have. The general purpose is to format it this way YYYYMMDDXX, either for the first amendment 01/04/2007 -> 2007040101, for the second 2007040102.

• 2. Refresh : defines the data refresh period.

• 3. Retry : if an error occurs during the last refresh, it will be repeated at the end of time Retry.

• 4. Expires‘: the server is considered unavailable after the time expires.

• 5. Negative cache TTL‘: set the lifetime of a NXDOMAIN response from us.

• ‘NS: information on behalf of nameservers for the domain.

• ‘X.: information on the mail server. Many can be defined. Thus, it is possible to give them a priority, assigning a number. The lower the number, the higher the priority.

• ‘A: associates a host name to an IPv4 address (32 bits)

• ‘YYYY: associates a host name to an IPv6 address (128 bits)

• ‘CNAME: identifies the canonical name of an alias (a name that points to another name)

• ‘PTR: This is simply the inverse resolution (the opposite of type A).

The classes in the association determines the Internet class. Other classes are available (CH and HS). For more information please consult the rfc1035

/etc/resolv.conf File

search example.com

It’s no more complicated than that !

Bind Chroot

Debian Wheezy and earlier

The named daemon is started using the bind user by default.

This option is found in the bind service config file /etc/default/bind9

OPTIONS="-u bind"

The bind start script /etc/init.d/bind9 reads this config file when the service is started.

Starting bind as a non root user is good practice but to run the daemon in a chroot environment we also need specify the chroot directory. This is done using the same OPTIONS variable in /etc/default/bind9.

To begin, start by stopping the bind service:

/etc/init.d/bind9 stop

Then edit /etc/default/bind9:

OPTIONS="-u bind -t /var/bind9/chroot"

If bind refuses to start with error messages like «network unreachable resolving: » followed by a host and an IPv6 address, then you might add argument «-4» to force bind to always use IPv4 instead of IPv6:

OPTIONS="-u bind -4 -t /var/bind9/chroot"

Now create the chroot directory structure:

mkdir -p /var/bind9/chroot/{etc,dev,var/cache/bind,var/run/named}

Create the required device special files and set the correct permissions:

mknod /var/bind9/chroot/dev/null c 1 3
mknod /var/bind9/chroot/dev/random c 1 8
mknod /var/bind9/chroot/dev/urandom c 1 9
chmod 660 /var/bind9/chroot/dev/{null,random,urandom}

Move the current config directory into the new chroot directory:

mv /etc/bind /var/bind9/chroot/etc

Now create a symbolic link in /etc for compatibility:

ln -s /var/bind9/chroot/etc/bind /etc/bind 

If you want to use the local timezone in the chroot (e.g. for syslog):

cp /etc/localtime /var/bind9/chroot/etc/

Change the ownership on the files you’ve just moved over and the rest of the newly created chroot directory structure:

chown bind:bind /var/bind9/chroot/etc/bind/rndc.key
chmod 775 /var/bind9/chroot/var/{cache/bind,run/named}
chgrp bind /var/bind9/chroot/var/{cache/bind,run/named}

Edit the PIDFILE variable in /etc/init.d/bind9 to the correct path:

PIDFILE=/var/bind9/chroot/var/run/named/named.pid

Finally tell rsyslog to listen to the bind logs in the correct place:

echo "$AddUnixListenSocket /var/bind9/chroot/dev/log" > /etc/rsyslog.d/bind-chroot.conf

Restart rsyslog and start bind:

/etc/init.d/rsyslog restart; /etc/init.d/bind9 start

Debian Jessie and later

The named daemon is started using the bind user by default.

Create the file /etc/systemd/system/bind9.service with options «-t /var/bind9/chroot»:

[Unit]
Description=BIND Domain Name Server
Documentation=man:named(8)
After=network.target

[Service]
ExecStart=/usr/sbin/named -f -u bind -t /var/bind9/chroot
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop

[Install]
WantedBy=multi-user.target

However, at least by Debian 9 stretch, one could use the package maintainer’s version of the systemd unit file, and add the chroot overrides in: /etc/systemd/system/bind9.service.d/bind9.conf (or setting one’s chroot dir accordingly), e.g.:

[Service]
UMask=027
ExecStart=
ExecStart=/usr/sbin/named -f -u bind -t /var/bind9/chroot

However, at least as of Debian 10 buster, it’s probably better to remove such a /etc/systemd/system/bind9.service.d/bind9.conf file (as the manner in which systemd now starts bind9’s named, has changed, and will typically conflict with override done as the above), and now is best to have the overrides in /etc/default/bind9, e.g.:

OPTIONS="-u bind -t /var/bind9/chroot"

and systemd will now incorporate the OPTIONS from /etc/default/bind9 and use those (as will at least also sysvinit).

Update the symlink to the unit file with:-

systemctl reenable bind9

Also advised to run:

systemctl daemon-reload

for systemd (default) systems, to pick up any changes to systemd configuration files.

Now create the chroot directory structure:

mkdir -p /var/bind9/chroot/{etc,dev,run/named,var/cache/bind}

Create the required device special files and set the correct permissions:

mknod /var/bind9/chroot/dev/null c 1 3
mknod /var/bind9/chroot/dev/random c 1 8
mknod /var/bind9/chroot/dev/urandom c 1 9
chmod 666 /var/bind9/chroot/dev/{null,random,urandom}

Move the current config directory into the new chroot directory:

mv /etc/bind /var/bind9/chroot/etc

Now create a symbolic link in /etc for compatibility:

ln -s /var/bind9/chroot/etc/bind /etc/bind 

If you want to use the local timezone in the chroot (e.g. for syslog):

cp /etc/localtime /var/bind9/chroot/etc/

Change the ownership on the files you’ve just moved over and the rest of the newly created chroot directory structure:

chown bind:bind /var/bind9/chroot/etc/bind/rndc.key
chown bind:bind /var/bind9/chroot/run/named
chmod 775 /var/bind9/chroot/{var/cache/bind,run/named}
chgrp bind /var/bind9/chroot/{var/cache/bind,run/named}

Starting with Buster, AppArmor is enabled by default on Debian, which requires to add the following 4 lines to /etc/apparmor.d/local/usr.sbin.named:

/var/bind9/chroot/etc/bind/** r,
/var/bind9/chroot/var/** rw,
/var/bind9/chroot/dev/** rw,
/var/bind9/chroot/run/** rw,
/var/bind9/chroot/usr/** r,

Without that change, bind would terminate immediately on startup with error message «open: /etc/bind/named.conf: permission denied». To make these AppArmor changes effective:

systemctl reload apparmor

Also, additionally for Debian 10 Buster, /usr/share/dns is also needed under the chroot.

Finally tell rsyslog to listen to the bind logs in the correct place:

echo "$AddUnixListenSocket /var/bind9/chroot/dev/log" > /etc/rsyslog.d/bind-chroot.conf

Restart rsyslog and start bind:

systemctl restart rsyslog
systemctl restart bind9

Also, alternative chroot approach to copying many files, etc., and more compatible for interacting utilities, etc. outside of chroot. One can relocate some directory(/ies), create some directories/files as/where needed, and use bind mounts, e.g.: included in /etc/fstab:

/dev/null /var/lib/named/dev/null none bind 0 0
/dev/random /var/lib/named/dev/random none bind 0 0
/run/named /var/lib/named/run/named none bind 0 0
/usr/share/dns /var/lib/named/usr/share/dns none bind 0 0

and we then also have:

$ ls -ld /etc/bind
lrwxrwxrwx 1 root root 25 Mar 15  2014 /etc/bind -> ../var/lib/named/etc/bind
$

in fact it’s possible to set up a configuration that not only works within chroot, but also works without using chroot — only changing how bind9/named is invoked, and nothing else, and between symbolic links and bind mounts, utilities outside the chroot will also interact with bind fine, «as if» it were outside the chroot — as they find the needed bind components logically in the same place, even though most are physically within the chroot stucture (and some, via bind mounts, are outside of the chroot and equally accessible inside and outside the chroot).

Client Manage

As I mentioned at the beginning, the assignment of IP addresses on the LAN is performed by the DHCP server. Thus, to set our DNS server to different clients, it is necessary to add the DHCP configuration file the following two lines:

option domain-name «example.com»

option domain-name-server sid.example.com

It must be added to the file (I think) the areas for which DHCP should automatically perform updates.

Syntax (everything after «=>» is my comments) :

zone [name.of.the.zone.] {

• primary 127.0.0.1; => the primary DNS server is on the same machine as the DHCP

  key rndc-key; => it’s necessary to provide the security key (via an include) in the beginning of the DHCP server configuration file,

  • this must be the same key that secures the allow-update for the zone in the named.conf.local of Bind9.

}

Examples de [name.of.the.zone.] (with the «.» at the end) :

— example.com. : for the direct zone of this article,

— 0.168.192.in-addr.arpa. : for the inverse zone of this article.

For more information on the implementation of dynamic update of DNS records through DHCP is here

• Dig Command : this can directly search the DNS server of your choice and get a lot of information in addition to name resolution and contrast resolution.

  $ dig nomade-frjo.stones.lan
  ; <<>> DiG 9.4.2 <<>> nomade-frjo.stones.lan
  ;; global options:  printcmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15760
  ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
  
  ;; QUESTION SECTION:
  ;nomade-frjo.stones.lan.                IN      A
  
  ;; ANSWER SECTION:
  nomade-frjo.stones.lan. 900     IN      A       192.168.0.242
  
  ;; AUTHORITY SECTION:
  stones.lan.             604800  IN      NS      emerald.stones.lan.
  stones.lan.             604800  IN      NS      diamond.stones.lan.
  
  ;; ADDITIONAL SECTION:
  diamond.stones.lan.     604800  IN      A       192.168.0.1
  emerald.stones.lan.     604800  IN      A       192.168.0.2
  
  ;; Query time: 20 msec
  ;; SERVER: 127.0.0.1#53(127.0.0.1)
  ;; WHEN: Fri Mar 28 20:53:09 2008
  ;; MSG SIZE  rcvd: 131
  
  $ dig -x 192.168.0.242
  ; <<>> DiG 9.4.2 <<>> -x 192.168.0.242
  ;; global options:  printcmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37702
  ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
  
  ;; QUESTION SECTION:
  ;242.0.168.192.in-addr.arpa.    IN      PTR
  
  ;; ANSWER SECTION:
  242.0.168.192.in-addr.arpa. 900 IN      PTR     nomade-frjo.stones.lan.
  
  ;; AUTHORITY SECTION:
  0.168.192.in-addr.arpa. 604800  IN      NS      diamond.stones.lan.
  0.168.192.in-addr.arpa. 604800  IN      NS      emerald.stones.lan.
  
  ;; ADDITIONAL SECTION:
  diamond.stones.lan.     604800  IN      A       192.168.0.1
  emerald.stones.lan.     604800  IN      A       192.168.0.2
  
  ;; Query time: 19 msec
  ;; SERVER: 127.0.0.1#53(127.0.0.1)
  ;; WHEN: Fri Mar 28 20:53:31 2008
  ;; MSG SIZE  rcvd: 155

• nslookup : Kind of slow but still useful.

  $ nslookup etch
  Server:         192.168.0.1
  Address:        192.168.0.1#53
  Name:   etch.example.com
  Address: 192.168.0.2
  
  $ nslookup 192.168.0.2
  Server:         192.168.0.1
  Address:        192.168.0.1#53
  2.0.168.192.in-addr.arpa        name = etch.example.com.

• named-checkconf : Verifies the syntax of the configuration files for Bind9.

  # named-checkconf -z
  zone localhost/IN: loaded serial 1
  zone 127.in-addr.arpa/IN: loaded serial 1
  zone 0.in-addr.arpa/IN: loaded serial 1
  zone 255.in-addr.arpa/IN: loaded serial 1
  zone estar.lan/IN: loaded serial 20080315
  zone 0.168.192.in-addr.arpa/IN: loaded serial 20080315
  zone 10.in-addr.arpa/IN: loaded serial 1
  zone 16.172.in-addr.arpa/IN: loaded serial 1
  zone 17.172.in-addr.arpa/IN: loaded serial 1
  zone 18.172.in-addr.arpa/IN: loaded serial 1
  zone 19.172.in-addr.arpa/IN: loaded serial 1
  zone 20.172.in-addr.arpa/IN: loaded serial 1
  zone 21.172.in-addr.arpa/IN: loaded serial 1
  zone 22.172.in-addr.arpa/IN: loaded serial 1
  zone 23.172.in-addr.arpa/IN: loaded serial 1
  zone 24.172.in-addr.arpa/IN: loaded serial 1
  zone 25.172.in-addr.arpa/IN: loaded serial 1
  zone 26.172.in-addr.arpa/IN: loaded serial 1
  zone 27.172.in-addr.arpa/IN: loaded serial 1
  zone 28.172.in-addr.arpa/IN: loaded serial 1
  zone 29.172.in-addr.arpa/IN: loaded serial 1
  zone 30.172.in-addr.arpa/IN: loaded serial 1
  zone 31.172.in-addr.arpa/IN: loaded serial 1
  zone 168.192.in-addr.arpa/IN: loaded serial 1

• named-checkzone : Verifies the validity of zone files before resetting the configuration.

  # named-checkzone example.com /var/lib/bind/db.example.com
  zone example.com/IN: loaded serial 20080315
  OK

  # named-checkzone 0.168.192.in-addr.arpa /var/lib/bind/db.example.com.inv
  zone 0.168.192.in-addr.arpa/IN: loaded serial 20080315
  OK

Links and Resources

• rfc1035 — Implementation and specifications

• rfc1591 — Domain Name System Structure and Delegation

• rfc2606 — Reserved Top Level DNS Names

• Services Whois :

  • Gandhi

  • AFNIC

BIND 9 Documentation

BIND9 documentation:
If one has the bind9-doc package installed:
/usr/share/doc/bind9-doc/arm/
/usr/share/doc/bind9-doc/arm/Bv9ARM.html
or from ISC.org (upstream):
An Overview of BIND 9 Documentation (be sure to use corresponding version, and realize there may be some Debian differences).

DNSSEC

see: DNSSEC Howto for BIND 9.9+

CategorySoftware CategoryNetwork