Как написать dns сервер

Время на прочтение
4 мин

Количество просмотров 14K

Если вы впервые столкнулись с необходимостью поднять DNS-сервер для локальной сети под Linux, то эта статья – для вас. Преимущество предлагаемого способа – простота: сервер можно настроить буквально за несколько минут. Но этот способ, скорее всего, не подойдёт для продакшн серверов.

Автор статьи провёл несколько часов в борьбе с ошибками, багами и непонятным поведением системы прежде чем получил стабильный результат.

Далее будем считать, что имеется локальная сеть, состоящая из нескольких хостов. Локальная сеть настроена, сетевой доступ между хостами имеется. На хостах установлен Ubuntu 18.04.4 LTS (для других версий не проверялось).

Шаг 1. Установка необходимых пакетов

Следующие шаги выполняются на хосте, на котором будет устанавливаться DNS-сервер.

1. Установите Dnsmasq:

   sudo apt-get install dnsmasq

   При установке выведутся следующие ошибки:

   failed to create listening socket for port 53: Address already in use
   FAILED to start up
   Failed to start dnsmasq — A lightweight DHCP and caching DNS server.

   Это нормально! Мы ещё не настроили сервер – ошибка происходит из-за этого.

2. Установите resolvconf:

   sudo apt-get install resolvconf

   При установке ошибки о невозможности запуска Dnsmasq отобразятся ещё раз. Это нормально.

   Пакет resolvconf устанавливается для того, чтобы в файл /etc/resolv.conf при перезапуске компьютера автоматически записывалась строчка nameserver 127.0.0.1 . Эта строчка показывает, по какому адресу необходимо выполнить DNS-запросы для определения IP адресов доменов.

   Почему просто не прописать нужный адрес вручную

   При рестарте системы файл /etc/resolv.conf автоматически пересоздаётся. Поэтому если прописать в него нужный адрес вручную, то изменения окажутся стёртыми после перезапуска.

   По умолчанию после перезапуска в этот файл прописывается адрес 127.0.0.53, который используется сервисом systemd-resolve. Этот сервис осуществляет определение IP-адресов доменов для приложений, работающих на том же хосте, на котором запущен сервис. Но мы планируем перестать использовать этот сервис и начать использовать dnsmasq.

3. Необязательный шаг. Установите net-tools:

   sudo apt-get install net-tools

   Эта команда устанавливает набор инструментов, которые пригодятся при тестировании.

Шаг 2. Настройка пакетов

1. Отредактируйте файл /etc/dnsmasq.conf:

   sudo nano /etc/dnsmasq.conf

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

   1. no-resolv

      Эта настройка выключает загрузку настроек из /etc/resolv.conf. Все настройки будут браться из редактируемого файла /etc/dnsmasq.conf . Это сильно упрощает конфигурацию Dnsmasq’а, поскольку файл /etc/resolv.conf автоматически пересоздаётся при рестарте системы.

   2. server=8.8.8.8 

      8.8.8.8 — это адрес DNS-сервера Гугл. Этот адрес можно заменить на любой другой адрес публичного DNS-сервера. Например, на адрес DNS-сервера вашего провайдера или ранее используемого DNS-сервера.

      Запросы, которые не сможет обработать Dnsmasq будут направлены на этот сервер.

   3. listen-address=0.0.0.0

      Эта настройка позволит осуществлять запросы к Dnsmasq’у с других хостов.

   4. bind-interfaces

      Задаёт режим, при котором Dnsmasq не осуществляет привязку к интерфейсам, по которым не должна осуществляться обработка запросов. Без этой настройки в предлагаемом варианте конфигурации сервер не работает.

2. Добавьте в файл /etc/hosts необходимые домены и их IP адреса.

   sudo nano /etc/hosts

   Например:

   1.2.3.4 myserver.tst

   Обратите внимание, что доменные имена, состоящие из одного имени без точки (например, myserver), по умолчанию не передаются в DNS-сервер. Запросы по таким именам по умолчанию обрабатываются только через локальный файл /etc/hosts . Поэтому если в файле /etc/hosts на хосте с сервисом Dnsmasq прописать следующую строку: 2.3.4.5 myserver, то IP-адрес домена myserver будет определяться только на хосте с сервисом Dnsmasq. На других хостах IP-адрес данного домена определяться не будет, поскольку запросы на хост с Dnsmasq’ом отправляться не будут.

3. Опциональный шаг. Если вы не хотите, чтобы systemd-resolve слушал адрес 127.0.0.53:53, то выполните команду:

   sudo nano /etc/systemd/resolved.conf

   В открывшемся файле пропишите строчку:

   DNSStubListener=no

   Адрес 127.0.0.53:53 в предлагаемом варианте конфигурации не используется и его можно выключить.

4. Перезапустите машину:

   shutdown -r now

Шаг 3. Настройка используемых DNS-серверов

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

Проще всего настроить используемые DNS-сервера в графическом интерфейсе. Укажите адрес хоста, на котором установлен Dnsmasq, первым в списке:

Шаг 4. Локальное тестирование DNS-сервера

Проверку настроек можно и не делать. Но если вам интересно узнать, всё ли работает правильно, то выполните следующие команды на хосте с сервисом Dnsmasq.

1. Проверьте, что в файле /etc/resolve.conf прописан адрес 127.0.0.1:

   cat /etc/resolve.conf

2. Выполните команду:

   sudo netstat -tulpen

   Вы должны увидеть, что адрес 0.0.0.0:53 занят Dnsmasq’ом, а адрес 127.0.0.53:53 не фигурирует в списке.

3. Выполните команду:

   dig ya.ru

   Вы должны получить вывод, в котором присутствует примерно такая строчка. В начале строки не должно быть символов ;.

   ya.ru. 220 IN A 87.250.250.242

4. Выполните команду:

   dig myserver.tst

   Вы должны получить вывод, в котором присутствует примерно такая строчка:

   myserver.tst. 0 IN A 1.2.3.4

Шаг 5. Тестирование DNS-сервера с других хостов

Теперь можно проверить работу DNS-сервера с других хостов.

Выполните пункты 3 и 4 из предыдущего раздела. Вывод в консоль должен быть аналогичен результатам, указанным в предыдущем разделе.

Дополнительная информация

Открыть, если что-то пошло не так

Заключение

В этой статье мы рассмотрели, как можно сравнительно быстро настроить DNS-сервер для локальной сети под Linux. Если вы знаете какие-то другие фишки по настройке DNS-сервера, напишите об этом в комментариях.

How to create a dns server using bind on linux.

tl;dr,

# ON DNS SERVER
tail -f /var/log/dns.jeffs-query.log
# ON EACH MACHINE / CLIENT
cat /etc/resolv.conf
systemd-resolve --status
# The ultimate goal is to have,
#     search jeffnet.lan
#     nameserver 192.168.20.110
#     nameserver 8.8.8.8
#     nameserver 8.8.4.4
# ADD HOST TO LOOKUP TABLE
sudo nano /etc/bind/jeffnet.lan.db
sudo nano /etc/bind/reverse.20.168.192.in-addr.arpa.db
# BIND
service bind9 status
sudo service bind9 restart
# SOME CHECKS
ping stimpy
ping facebook.com
dig stimpy.jeffnet.lan
dig facebook.com
ssh jeff@stimpy
nslookup stimpy
nslookup facebook.com

Table of Contents,

• WHY DO WE NEED A LOCAL DNS SERVER
• WHAT DNS IS YOUR MACHINE USING
• INSTAL BIND (DNS SERVER)
• CONFIGURE PRIMARY DNS SERVER
  • CONFIGURE named.conf
  • CONFIGURE named.conf.options
  • CONFIGURE named.conf.local
  • CONFIGURE named.conf.default.zones
• CONFIGURE SECONDARY DNS SERVER
• VERIFY & START BIND
• CONFIGURE YOUR CLIENTS FOR DNS
  • UBUNTU
  • RASPBIAN
  • macOS
  • DEBIAN 8
  • WINDOWS
• TEST

I want to credit Dani from
domoticproject.com
for a lot of this information.

View my entire list of cheat sheets on
my GitHub Webpage.

WHY DO WE NEED A LOCAL DNS SERVER

Most likely your home router is acting as a DNS forwarder;
You ask your router and your router send its up to the next router.
The ISP router has it set to asks its own ISP DNS server.
You could overide this and set your router to ask google DNS, or
set this request for each machine.
So the bottom line, the request gets passed upstream till someone figures it out.

So how do you reach your raspberry pi from another device? You muse the IP address.
You can’t use the hostname. You must use,

But if you had a home dns server, you could use your hostname,

This illustration may help,

From the above illustration, the benefits are apparent,

• You can now use hostname of your local machines.
• You don’t have to set static IPs on your routers (Pain).
• Your local DNS can cache certain website so now you do not always have to ask
  your ISP DNS or google DNS server. This is faster.
• Security, your local requests won’t go outside your home network.

WHAT DNS IS YOUR MACHINE USING

First let find what dns you are currently using on your clients.

For Linux,

sudo apt-get install network-manager
nmcli device show enp1s0
nmcli device show eth0

For macOS,

scutil --dns | grep 'nameserver[[0-9]*]'

INSTAL BIND (DNS SERVER)

BIND (Berkley Internet Naming Daemon) is the most common program
used for maintaining a name server on Linux.

First make sure you Raspi is not configured with a static IP,

sudo nano /etc/network/interfaces

Now install BIND,

sudo apt-get install bind9 bind9-doc dnsutils bind9utils

Check status,

service bind9 status
dpkg --list | grep bind

Put bind 9 in ipv4 mode,

sudo nano /etc/default/bind9

with,

CONFIGURE PRIMARY DNS SERVER

All DNS configurations for BIND are located under /etc/bind.

• named.conf — Primary configuration
• named.conf.options — Port to listen, the forwarders to use, etc…
• named.conf.local — This file has the local DNS server configuration
• named.conf.default.zones — It contains the default zones of the server

CONFIGURE named.conf

Configure,

sudo nano /etc/bind/named.conf

with,

// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

# Access Control List that includes the loopback interface and the local network
acl "jeffs-trusted" {
127.0.0.0/8;            # Trust localhost, not sure if this is needed
192.168.20.0/24;        # Trust all IPs in the subnet
};

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

CONFIGURE named.conf.options

Configure,

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

with,

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

        recursion yes;              # enables recursive queries
        allow-recursion {           # allows recursive queries from "trusted" clients
                jeffs-trusted;
        };
        listen-on {                 # ns1 private IP address
            192.168.20.110;
        };
        allow-transfer {            # disable zone transfers by default
            none;
        };
        allow-query {
            jeffs-trusted;
        };

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        forwarders {
            8.8.8.8; # Google DNS
            9.9.9.9; # IMB Quad9 DNS
        };

        //========================================================================
        // If BIND logs error messages about the root key being expired,
        // you will need to update your keys.  See https://www.isc.org/bind-keys
        //========================================================================
        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

logging {
        channel bind.jeffs-query.log {
            file "/var/log/dns.jeffs-query.log";
            print-time yes;
            severity debug 3;
        };
        category queries { bind.jeffs-query.log; };
};

And also create your log file,

sudo touch /var/log/dns.jeffs-query.log
sudo chown bind:bind /var/log/dns.jeffs-query.log

CONFIGURE named.conf.local

Now set up two zones,

• Forward lookup — Where the domain’s IP address is searched
• Reverse lookup — For the inverse query

Configure,

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

with,

//
// Do any local configuration here
//

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

zone "jeffnet.lan" IN {
        type master;
        file "/etc/bind/jeffnet.lan.db";
        # allow-transfer { 92.168.20.XXX; };          # ns2 private IP address - secondary

};

zone "20.168.192.in-addr.arpa" {                    # 192.168.20.0/24 subnet
        type master;
        file "/etc/bind/reverse.20.168.192.in-addr.arpa.db";
        # allow-transfer { 192.168.20.XXX; };         # ns2 private IP address - secondary

};

Create forward lookup zone db,

sudo nano /etc/bind/jeffnet.lan.db

;
; BIND DATA FOR LOCAL LOOPBACK
$TTL    604800
@                                   IN      SOA     Jeffs-Raspi-3B.jeffnet.lan. admin.jeffnet.lan. (
                  3     ; Serial
             604800     ; Refresh
              86400     ; Retry
            2419200     ; Expire
             604800     ; Negative Cache TTL
)

;
; NAMESERVERS - NS RECORDS
                                    IN      NS      Jeffs-Raspi-3B.jeffnet.lan.     ; NS1
;                                    IN      NS      ns2-hostname.jeffnet.lan.      ; NS2

;
; NAMESERVERS - A RECORDS
Jeffs-Raspi-3B.jeffnet.lan.         IN      A       192.168.20.110                  ; NS1
;ns2-hostname.jeffnet.lan.           IN      A       192.168.20.xxx                 ; NS2

;
; 192.168.20.0/24 - A RECORDS
stimpy.jeffnet.lan.                 IN      A       192.168.20.102
Jeffs-MBP.jeffnet.lan.              IN      A       192.168.20.103
Jeffs-Raspi-1Bplus.jeffnet.lan.     IN      A       192.168.20.111
Jeffs-HBpro-i4X4.jeffnet.lan.       IN      A       192.168.20.120

Create reverse lookup zone db,

sudo nano /etc/bind/reverse.20.168.192.in-addr.arpa.db

;
; BIND REVERSE DATA FOR LOCAL LOOPBACK
$TTL    604800
@                                   IN      SOA     jeffnet.lan. admin.jeffnet.lan. (
                  3     ; Serial
             604800     ; Refresh
              86400     ; Retry
            2419200     ; Expire
             604800     ; Negative Cache TTL
)

;
; NAMESERVERS - NS RECORDS
                                    IN      NS      Jeffs-Raspi-3B.jeffnet.lan.     ; NS1
;                                    IN      NS      ns2-hostname.jeffnet.lan.      ; NS2

;
; PTR RECORDS
110                                 IN      PTR     Jeffs-Raspi-3B.jeffnet.lan.     ; NS1
; XXX                                IN      NS      ns2-hostname.jeffnet.lan.      ; NS2
102                                 IN      PTR     stimpy.jeffnet.lan.
103                                 IN      PTR     Jeffs-MBP.jeffnet.jeffnet.lan.
111                                 IN      PTR     Jeffs-Raspi-1Bplus.jeffnet.lan.
120                                 IN      PTR     Jeffs-HBpro-i4X4.jeffnet.lan.

CONFIGURE named.conf.default.zones

tbd.

CONFIGURE SECONDARY DNS SERVER

Not part of cheat sheet yet.

VERIFY & START BIND

Verify no error with your configuration files. Should return nothing,

named-checkconf
named-checkzone jeffnet.lan /etc/bind/jeffnet.lan.db
named-checkzone 20.168.192.in-addr.arpa /etc/bind/reverse.20.168.192.in-addr.arpa.db

Start BIND,

service bind9 status
sudo service bind9 restart
sudo service bind9 stop
sudo service bind9 start

CONFIGURE YOUR CLIENTS FOR DNS

There are two ways your machines can find a nameserver,

• Set on your router
• Configure each host

We will do the latter.

Most of the time, you can check your machine that it got the
static ip and the nameserver ip,

We want,

To have,

search jeffnet.lan
nameserver 192.168.20.110
nameserver 8.8.8.8
nameserver 8.8.4.4

You can also do,

UBUNTU

These DNS configurations work most of the time.

UBUNTU 18.04

Ubuntu 18.04 uses netplan. A YAML based configuration system,
which simplifies the configuration process.

If you have a gui, bring up the manager by

nm-connection-editor
sudo systemctl restart NetworkManager
sudo systemd-resolve --status

Remember to turn automatic DNS off in the normal network settings.
Yeah, this was a pain to figure out.

If you are not using the gui, then edit this file,

sudo nano /etc/netplan/01-network-manager-all.yaml

Find you ethernet name with,

This is only for ns1, if you had ns2 you will have to add two addresses.

network:
  version: 2
  renderer: NetworkManger
  ethernets:
    enp1s0:
      dhcp4: yes
      nameservers:
        addresses:
        - 192.168.20.110
        - 8.8.8.8
        - 8.8.4.4
        search:
        - jeffnet.lan

Now enable and check,

sudo netplan try
sudo netplan --debug apply
sudo netplan --debug generate
sudo systemd-resolve --status

UBUNTU 20.04

Ubuntu 20.04 also uses netplan for network management by default.
See above.

RASPBIAN

sudo nano /etc/dhcpcd.conf

add,

static domain_name_servers=192.168.20.110 8.8.8.8 8.8.4.4
static domain_search=jeffnet.lan

Restart,

sudo service dhcpcd restart

macOS

Configure your nameserver in
System Preferences - > Network -> Advanced - > DNS.

DEBIAN 8

Edit,

sudo nano /etc/network/interfaces

And add,

# The loopback network interface
auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet dhcp
#    dns-nameservers 192.168.20.110 8.8.8.8 8.8.4.4
#    dns-search jeffnet.lan

allow-hotplug wlan0
iface wlan0 inet dhcp
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

So I forced it in,

sudo nano /etc/dhcp/dhclient.conf

Added,

supersede domain-name-servers 192.168.20.110, 8.8.8.8, 8.8.4.4;
supersede domain-search "jeffnet.lan";

More info,

restart,

sudo /etc/init.d/networking restart

WINDOWS

You goto each adapter settings and edit the properties of IPV4.
Click the advanced options to add jeffnet.lan under Append these DNS suffixes.

Under bash for windows you should see your changes after a reboot in /etc/resolv.conf.

Now you need to change the port to 2222. Port 22 does not wor
because Windows comes with a built in SSH server.

Edit,

sudo nano /etc/ssh/sshd_config

with

Then restart,

sudo service ssh --full-restart

TEST

On your nameserver you can always check the log,

tail -f /var/log/dns.jeffs-query.log

From any other device on the network you should be able to,

ping stimpy
ping Jeffs-MBP
ping Jeffs-Raspi-3B
ping Jeffs-Raspi-1Bplus
ping Jeffs-HBpro-i4X4
ping facebook.com

dig stimpy.jeffnet.lan
dig Jeffs-MBP.jeffnet.lan
dig Jeffs-Raspi-3B.jeffnet.lan
dig Jeffs-Raspi-1Bplus.jeffnet.lan
dig Jeffs-HBpro-i4X4.jeffnet.lan
dig facebook.com

ssh jeff@stimpy
ssh jeffdecola@Jeffs-MBP
ssh jeff@Jeffs-Raspi-3B
ssh jeff@Jeffs-Raspi-1Bplus
ssh jeff@Jeffs-HBpro-i4X4

nslookup stimpy
nslookup Jeffs-MBP
nslookup Jeffs-Raspi-3B
nslookup Jeffs-Raspi-1Bplus
nslookup Jeffs-HBpro-i4X4
nslookup facebook.com

5 апреля 2021 г. 11:01 | обновлен 9 августа 2021 г. 13:55

К созданию собственных DNS-серверов приходят не сразу, а когда появляется в этом необходимость, например, невозможность или нежелание платить за DNS-хостинг, который имеется у некоторых Регистраторов Доменных имен на платной основе, а также, чтобы контролировать процесс самостоятельно, добавлять любое количество доменных зон и записей к ним. Также, будет полезно, если решите узнать что-то новое для себя.

1. Первым делом заходим в личный кабинет нашего регистратора доменных имен и устанавливаем свои NS-сервера (которые мы далее создадим) для текущего домена:

2. Итак, приступим к настройке Первого NS-сервера. Первым делом нам необходимо установить NSD на нашу машину с Linux/Debian:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install nsd

3. Далее идем по пути /etc/nsd/ и создаем файл nsd.conf и заполняем следующим образом (оригинальную пасту и информацию смотреть тут):

server:
            server-count: 1 # use this number of cpu cores
            database: ""  # or use "/var/db/nsd/nsd.db"
            zonelistfile: "/var/db/nsd/zone.list"
            username: nsd
            logfile: "/var/log/nsd.log"
            pidfile: "/var/run/nsd.pid"
            xfrdfile: "/var/db/nsd/xfrd.state"

4. Следующим шагом создаем доменную зону для тестового домена, в данном случае это будет доменное имя artspace.one, по его субдомену и будут находится адреса NS серверов (оригинальную пасту и информацию смотреть тут). Создаем в том же каталоге файл: artspace.one.zone :

$ORIGIN artspace.one.
@                      3600 SOA   ns1.artspace.one. (
                              ns1.artspace.one.     ; address of responsible party
                              2016072701                 ; serial number
                              3600                       ; refresh period
                              600                        ; retry period
                              604800                     ; expire time
                              1800                     ) ; minimum ttl
mail                  14400 A     204.13.248.106 # IP-адрес для суб-домена mail.artspace.one
www                  14400 A     185.255.132.54	 # IP-адрес для суб-домена www.artspace.one			  
ns1                  14400 A     45.141.76.240	 # IP-адрес для первого NS сервера (текущий)		  
ns2                  14400 A     167.71.63.71	 # IP-адрес для второго NS сервера

5. Возвращаемся в файл-конфигурации nsd.conf и добавляем дополнительные записи для нового доменной зоны artspace.one с упоминанием второго NS-сервера и получаем такое содержимое:

server:
            server-count: 1 # use this number of cpu cores
            database: ""  # or use "/var/db/nsd/nsd.db"
            zonelistfile: "/var/db/nsd/zone.list"
            username: nsd
            logfile: "/var/log/nsd.log"
            pidfile: "/var/run/nsd.pid"
            xfrdfile: "/var/db/nsd/xfrd.state"

       zone:
            name: artspace.one
            zonefile: /etc/nsd/artspace.one.zone
            notify: 167.71.63.71 NOKEY          # Тут указываем IP-адрес второго NS-сервера
            provide-xfr: 167.71.63.71 NOKEY     # Тут указываем IP-адрес второго NS-сервера

6. Далее следует запустить наш NSD-сервис:

nsd-control reload
systemctl restart nsd

Проверить, запустился ли сервис можно следующей командой:

systemctl status nsd

Loaded: loaded (/lib/systemd/system/nsd.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2021-04-05 08:43:52 UTC; 9min ago
...

Main PID: 32083 (nsd)
    Tasks: 3
   Memory: 52.0M
      CPU: 110ms
   CGroup: /system.slice/nsd.service
           ├─32083 /usr/sbin/nsd -d -c /etc/nsd/nsd.conf
           ├─32088 /usr/sbin/nsd -d -c /etc/nsd/nsd.conf
           └─32089 /usr/sbin/nsd -d -c /etc/nsd/nsd.conf

Apr 05 08:43:52 Disturbing systemd[1]: Starting Name Server Daemon...
Apr 05 08:43:52 Disturbing systemd[1]: Started Name Server Daemon.

Также, корректность настройки доменных зон:

root@username:~# nsd-control zonestatus

zone:   artspace.one
        state: master

Для более детального изучения событий имеется файл с логами, который можно посмотреть так:

cat /var/log/nsd.log

7. Для проверки работоспособности нашей конфигурации следует запустить следующую команду, которая получит IP-адрес для A-записи www.artspace.one :

dig www.artspace.one @127.0.0.1 +short

Если все настроено правильно, то мы получим такой краткий ответ:

root@username:~# dig www.artspace.one @127.0.0.1 +short
185.255.132.54

Также, можно проверить с другой машины/linux vps:

root@byfe:~# dig www.artspace.one +short
185.255.132.54

Как видим, ответы совпадают, значит первый DNS-сервер настроен корректно.

8. Перейдем к настройке Второго NS-сервера. Повторяем шаги 2-4, но заменяя ns1.artspace.one на ns2.artspace.one

Далее заходим в файл nsd.conf на втором NS-сервере, копируем данные из первого и заменяем Notify на первый NS-сервер и также перезапускаем сервис и проверяем работоспособность:

server:
            server-count: 1 # use this number of cpu cores
            database: ""  # or use "/var/db/nsd/nsd.db"
            zonelistfile: "/var/db/nsd/zone.list"
            username: nsd
            logfile: "/var/log/nsd.log"
            pidfile: "/var/run/nsd.pid"
            xfrdfile: "/var/db/nsd/xfrd.state"

       zone:
            name: artspace.one
            zonefile: /etc/nsd/artspace.one.zone
            notify: 45.141.76.240 NOKEY          # Тут указываем IP-адрес первого NS-сервера
            provide-xfr: 45.141.76.240 NOKEY     # Тут указываем IP-адрес первого NS-сервера

На этом настройку обеих NS-серверов можно считать завершенной. NSD, также, с легкостью переваривает Punny-code сайты, например в момент написания статьи Punny-code: xn--v77hga63i.ml (🇷🇺🍰.ml) с А-записью www. обращается к IP-адресу 46.17.105.86:

dig www.xn--v77hga63i.ml

; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> www.xn--v77hga63i.ml
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15735
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.xn--v77hga63i.ml.          IN      A

;; ANSWER SECTION:
www.xn--v77hga63i.ml.   14399   IN      A       46.17.105.86

;; Query time: 1056 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Apr 05 12:14:55 MSK 2021
;; MSG SIZE  rcvd: 65

Таким образом, если перейти по адресу www.🇷🇺🍰.ml , то попадем на веб-интерфейс моего CHR.

Похожие записи:

Каждый сайт в интернете физически расположен на сервере, который по сути является компьютером и имеет свой IP-адрес. Пользователю неудобно запоминать набор цифр, чтобы попасть на нужный сайт. Поэтому придумали доменные имена, например, такие как google.com, которые проще запоминать. Теперь не нужно знать набор цифр, который указывает на тот или иной сайт. Для того, чтобы перевести строку символов, которые пользователь набирает в строке браузера, в IP-адрес, существуют DNS. Рассмотрим, что такое DNS-сервер, принцип его работы и настройку.

Определение

DNS сервер нужен для сопоставления имен интернет-доменов, вводимых пользователем (например, mail.ru или rambler.ru), с их реальными IP-адресами. Это база данных, в которой содержатся IP-адреса и соответствующие им доменные имена, и используется для преобразования доменного имени в IP-адрес.

Принцип работы и применение

Работа DNS похожа на работу со списком контактов смартфона. Вы находите требуемый контакт по имени, нажимаете на значок «позвонить», телефон набирает нужный номер и соединяет с соответствующим абонентом.

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

Рассмотрим подробнее, как работает dns сервер:

• Пользователь в адресной строке браузера вводит доменное имя сайта, на который хочет перейти.
• Браузер ищет нужный IP-адрес на локальном компьютере, в файле hosts. Если нужной информации там не находит, то отправляет свой запрос на сервер более высокого уровня. Например, это может быть локальный сервер провайдера.
• Если и на этом сервере нет данных об IP-адресе сайта, то запрос переправляется на сервис более высокого уровня. Такая переадресация будет длиться, пока нужный адрес не будет найден или корневой DNS-сервер не ответит, что сайта с таким именем не существует.
• После этого начнётся обратное движение запроса, от высшего уровня до низшего, пока данные не придут на компьютер пользователя.

С помощью DNS можно не только найти адрес сайта по IP-адресу, но и выполнить обратную операцию: зная адрес, узнать его доменное имя.

Где находятся

Самые важные DNS-серверы — корневые, которые содержат информацию о нахождении других серверов, более низкого уровня. Впервые они появились в Северной Америке, но потом их стали разворачивать и в других странах. Сейчас корневых серверов всего 13. Однако для увеличения надёжности работы интернет были созданы их копии, и их общее количество возросло до 123.

Наибольшее из количество расположено в Северной Америке, где их 40, что составляет 32,5% от общей численности. На втором месте по числу серверов находится Европа — 35 серверов (28,5%). 6 (4,9%) серверов имеется в Южной Америке и 3 (2,4%) в Африке. Также есть свои DNS-серверы есть в Австралии, Китае и даже Исландии. Общая закономерность расположения серверов такая: чем интенсивнее используется интернет, тем больше серверов.

В России есть несколько корневых серверов:

• F.root – расположен в Москве;
• I.root – находиться в Санкт-Петербурге;
• J.root – распределённый, расположен в Москве, Санкт-Петербурге;
• K.root – еще один распределённый, находится в трёх городах: Москва, Санкт-Петербург и Новосибирск;
• L.root – присутствует сразу в трёх городах: Москва, Ростов-на-Дону и Екатеринбург.

Преимущества публичных DNS

Иногда лучше использовать не те ДНС серверы, которые по умолчанию предоставляет провайдер, а воспользоваться публичными. Для этого существуют следующие причины:

• использование быстрых публичных DNS увеличит скорость работы интернета;
• иногда используемые по умолчанию серверы работают нестабильно, в этом случае использование публичных серверов повысит надёжность;
• некоторые публичные DNS включают дополнительные функции по фильтрации данных, которые увеличивают безопасность компьютера;
• публичные DNS помогут обойти ограничения по расположению, например, можно будет смотреть видео в ютубе, на котором раньше было написано: «Это видео недоступно в вашей стране».

Топ 10 публичных DNS

Теперь вы знаете, чем могут быть полезны публичные DNS-серверы. Рассмотрим список из 10 наиболее популярных.

Google

Публичный DNS от компании Google является одним из самых быстрых и безопасных. Чтобы его настроить, нужно ввести IP-адрес «8.8.8.8» в качестве первичного DNS, а «8.8.4.4» в качестве дополнительного.

OpenDNS

OpenDNS предлагает один из лучших облачных серверов, который защитит ваш компьютер. Он имеет два бесплатных решения: OpenDNS Home и OpenDNS Family Shield.

OpenDNS Home идёт вместе с защитой от фишинга. Для его настройки нужно ввести два адреса DNS: предпочитаемый 208.67.222.222 и альтернативный 208.67.222.220.

В решении OpenDNS Shield имеется блокировка контента только для взрослых. Чтобы воспользоваться, введите следующие DNS адреса: основной 208.67.222.123, дополнительный 208.67.220.123.

Norton ConnectSafe

Компания Norton разрабатывает не только антивирусные программы, но и предлагает воспользоваться их сервером доменных имен. Данный облачный сервис защищает ПК от фишинговых сайтов. Он поставляется в трёх версиях, с разными предварительно настроенными фильтрами:

1. безопасность;
2. безопасность и порнография;
3. безопасность, порнография и другое.

Comodo Secure DNS

Благодаря тому, что Comodo Secure DNS рассылает ваш запрос на большое количество глобальных серверов, она способна обеспечить высокую скорость работы в интернете. Чтобы воспользоваться этим сервисом, введите основной адрес «8.26.56.26» и дополнительный «8.20.247.20».

Level3

Level3 – это ещё один бесплатный качественный сервис. Он работает на следующих IP-адресах: предпочитаемый 209.244.0.3, альтернативный 208.244.0.4.

DNS Advantage

DNS Advantage – это очень быстрый сервер, который поможет работать в интернете быстрее и безопаснее. Его основной адрес: «156.154.70.1», а дополнительный «156.154.71.1».

Dyn

Бесплатный сервис Dyn в основном предназначен для защиты вашего ПК от фишинговых атак. Для того, чтобы начать работать с этим сервисом, настройте следующие параметры: адрес основного DNS-сервера «216.146.53.35», альтернативного «216.146.36.36».

SafeDNS

Служба SafeDNS основана на облачной технологии, что помогает защитит ПК. Для работы с ней нужно задать следующие адреса: предпочитаемый «195.46.39.39», дополнительный «195.46.39.40».

DNS.Watch

DNS.Watch – это бесплатный, быстрый и незаметно работающий сервис DNS. Для его настройки введите на своём компьютере следующие IP-адреса: предпочитаемый DNS-сервер «84.200.69.80», альтернативный «84.200.70.40».

Настройка в Windows

Чтобы настроить DNS-сервер в операционной системе Windows любой из версий, начиная с ХР и заканчивая 10, нужно:

DNS-сервер относится к наиболее критичным элементам сетевой инфраструктуры, так как именно на него возлагается задача разрешения доменных имен, без которой трудно представить работу любой сети. Поэтому важно не допускать перебоев в обслуживании клиентов, а справиться с этой задачей нам поможет отказоустойчивая конфигурация из нескольких DNS-серверов. В данной статье мы рассмотрим, как создать собственную инфраструктуру DNS при помощи полнофункционального и открытого DNS-сервера BIND 9.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

BIND 9 — это полнофункциональный открытый DNS-сервер, имеющий широкое распространение, 10 из 13 корневых DNS-серверов работают именно на BIND. В данной статье мы будем рассматривать установку BIND в среде Debian или Ubuntu, все действия, если не указано иного, выполняются с правами суперпользователя (root). Также предполагается, что читатель имеет представление о назначении DNS-сервера и основных типах DNS-записей.

Установка и настройка BIND 9 на первичном сервере

Установка BIND и всех необходимых пакетов производится одной командой:

apt install bind9

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

Затем откроем файл /etc/bind/named.conf.options и после строки:

directory "/var/cache/bind";

Добавим следующие настройки:

listen-on port 53 { 127.0.0.1; 192.168.72.8; };
 allow-query { 127.0.0.0/8; 192.168.72.0/24; };
 allow-recursion { 127.0.0.0/8; 192.168.72.0/24; };
 allow-transfer { none; };
 forwarders { 8.8.8.8; 8.8.4.4; };

Разберем их подробнее:

• listen-on port 53 — адреса на которых сервер будет принимать запросы, где 192.168.72.8 — адрес самого сервера
• allow-query — адреса сетей из которых принимаем запросы, указываем подсеть localhost и диапазон локальной сети
• allow-recursion — разрешаем рекурсивные запросы для localhost и локальной сети
• allow-transfer — кому можно предавать данные DNS-зон, по умолчанию никому
• forwarders — сервера пересылки, которым мы будем передавать запросы, которые не сможем разрешить самостоятельно, указываем любые внешние DNS

После чего приведем к следующему виду еще две опции:

dnssec-validation no;
 listen-on-v6 { none; };

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

zone "interface31.lab" {
     type master;
     file "/var/lib/bind/db.interface31.lab"; 
     allow-transfer { 192.168.72.9; };
};

Назначение параметров:

• zone — наименование зоны, которую будет обслуживать сервер, задается в виде доменного имени, в нашем случае interface31.lab
• type — тип зоны, в нашем случае — master — первичная
• file — файл с данными зоны, вы можете выбрать произвольное наименование, но в Debian принято соглашение называть эти файлы как db.имя_зоны, а хранить их в /var/lib/bind.
• allow-transfer — узел, которому разрешается передавать данные зоны, указываем адрес нашего вторичного DNS-сервера

Затем добавим туда же описание обратной зоны:

zone "72.168.192.in-addr.arpa" {
     type master;
     file "/var/lib/bind/db.192.168.72";
     allow-transfer { 192.168.72.9; };
};

Название обратной зоны записывается как адрес сети без последнего октета (для сетей /24) наоборот и дополняется in-addr.arpa. Остальные параметры те же.

Настройка прямой зоны

Прямая зона отвечает за сопоставление доменных имен IP-адресам, при запросе к прямой зоне мы указываем доменное имя и получаем в ответ связанный с ним IP-адрес.

Создадим указанный нами в описании зоны файл:

touch /var/lib/bind/db.interface31.lab

И начнем его заполнять, прежде всего внесем начальная запись зоны — SOA:

$TTL 86400 ;
@ IN SOA dns-1.interface31.lab. root.interface31.lab. (
         2022103006 ; Serial
         600 ; Refresh
         3600 ; Retry
         1w ; Expire
         360 ) ; Negative Cache TTL

Что означают эти записи?

TTL — время жизни DNS-записи, в нашем случае сутки, именно на это время клиент может поместить ее в собственный кеш, по истечении TTL клиент обязан запросить запись заново

@ IN SOA — основная запись домена, указывает его корневой DNS-сервер — dns-1.interface31.lab. и адрес ее администратора root.interface31.lab. (который следует понимать, как root@interface31.lab). Символ @ в начале строки указывает на текущий домен

Обратите внимание, что доменные имена внутри файлов зоны должны указываться в абсолютной форме записи, т.е. с точкой на конце. В противном случае окончание домена будет дополнено значением текущего. Т.е. вместо dns-1.interface31.lab вы получите dns-1.interface31.lab.interface31.lab

Ниже идут записи отвечающие за синхронизацию зоны со вторичными серверами:

• Serial — серийный номер зоны, при каждом изменении данных мы должны увеличивать серийный номер, по его изменению вторичные сервера понимают, что произошли изменения и начинают синхронизацию. Широко применяется следующий алгоритм формирования серийного номера: ГГГГ-ММ-ДД плюс две цифры указывающие на номер итерации, если в одну и ту же дату вносится несколько изменений.
• Refresh — период обновления данных вторичными серверами, по истечении данного времени они повторно запрашивают у основного сервера SOA-запись и анализируют серийный номер.
• Retry — периодичность повторного обращения к основному серверу, если предыдущая попытка завершилась неудачей
• Expire — максимальное время жизни зоны на вторичных серверах при отсутствии синхронизации с основным, по истечении этого времени вторичный сервер перестает обслуживать запросы
• Negative Cache TTL — время жизни негативного кеша или минимальное время жизни записи. Применяется для кеширования неудачного результата запроса со стороны клиента, например, обращение к несуществующему доменному имени.

Какие значения выбирать для этих параметров? Исходите из реальной нагрузки и здравого смысла. Указанные нами значения должны устроить администраторов большинства небольших и средних сетей.

Ниже будут располагаться сами записи зоны, начнем с NS-записей, которые указывают на сервера имен, обслуживающие зону, перечислим здесь оба наших DNS-сервера, в качестве значений используем доменные имена:

@ IN NS dns-1.interface31.lab.
@ IN NS dns-2.interface31.lab.

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

@       IN A 192.168.72.1
chr72   IN A 192.168.72.1
dns-1   IN A 192.168.72.8
dns-2   IN A 192.168.72.9
pve7    IN A 192.168.72.7
proxmox IN CNAME pve7

Внимательный читатель заметит, что у нас есть две записи, указывающие на один и тот же адрес. Первая из них, содержащая вместо имени узла символ @ относится к текущему домену, т.е. определяет какой адрес вернет сервер если будет запрошено имя домена, т.е. просто interface31.lab, вторая запись уже относится к реальному узлу — роутеру.

Кроме A — записей зона может содержать и другие, все зависит от текущих потребностей. Например, мы добавили запись псевдонима — CNAME, которая указывает на то, что при запросе proxmox.interface31.lab нужно вернуть результат для имени pve7.interface31.lab. Чем это удобно? Тем что мы можем присвоить сетевым службам красивые имена, которые не будут привязаны к определенным узлам. Скажем переместили службу с srv-1 на srv-2 — просто поменяли CNAME.

Заканчиваться файл зоны должен пустой строкой.

Настройка обратной зоны

Обратная зона предназначена для обратного преобразования, с ее помощью мы можем по IP-адресу узнать доменное имя узла. Для повседневной работы обратная зона обычно не требуется, и многие администраторы ее не создают, но при ее отсутствии могут возникнуть проблемы у многих сетевых сервисов, чаще всего неявные и неочевидные для начинающих, поэтому мы рекомендуем всегда сразу создавать обратную зону.

Точно также создадим файл зоны:

touch /var/lib/bind/db.192.168.72

И начнем его заполнять, первой записью у нас должна быть SOA, которая ничем не отличается от аналогичной записи прямой зоны и записи, указывающие на сервера имен, обслуживающие зону.

$TTL 86400 ;
@ IN SOA dns-1.interface31.lab. root.interface31.lab. (
         2022103005 ; Serial
         600 ; Refresh
         3600 ; Retry
         1w ; Expire
         360 ) ; Negative Cache TTL
@ IN NS dns-1.interface31.lab.
@ IN NS dns-2.interface31.lab.

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

8 IN PTR dns-1.interface31.lab.
9 IN PTR dns-2.interface31.lab.
7 IN PTR pve7.interface31.lab.
1 IN PTR chr72.interface31.lab.

Что обозначают эти записи? Начнем с того, что если имя узла указано без точки, то оно дополняется именем текущего домена, поэтому для указанной нами в записи цифры 8 это будет 8.72.168.192.in-addr.arpa, т.е. обратная запись для узла с адресом 192.168.72.8. Также обратите внимание, что доменные имена узлов следует указывать полностью, с точкой на конце.

Проверка работы первичного DNS-сервера

После того, как вы выполнили все настройки, а также создали и настроили файлы зон можно проверить функционирование нашего сервера. Сначала проверим конфигурацию на ошибки:

named-checkconf

Затем проверим зоны, для этого указываем их наименования и пути к файлам данных:

named-checkzone interface31.lab /var/lib/bind/db.interface31.lab
named-checkzone 72.168.192.in-addr.arpa /var/lib/bind/db.192.168.72

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

systemctl restart named
systemctl status named

Теперь можно попробовать направить запрос, начнем с прямого:

nslookup pve7.interface31.lab 192.168.72.8

Затем проверим обратный

nslookup 192.168.72.7 192.168.72.8

Чтобы запрос был направлен именно нашему серверу мы явно указываем его адрес вторым параметром команды.

В обоих случаях вы должны получить правильные ответы, после чего можно переходить к настройке вторичного DNS-сервера.

Установка и настройка BIND 9 на вторичном сервере

Точно также установим пакет на второй сервер:

apt install bind9 

И сразу перейдем к /etc/bind/named.conf.options, настройки которого полностью аналогичны первичному серверу, за исключением строки:

listen-on port 53 { 127.0.0.1; 192.168.72.9; };

В которой следует указать IP-адрес второго сервера, у нас это 192.168.72.9.

Теперь откроем /etc/bind/named.conf.local и пропишем зоны:

zone "interface31.lab" {
     type slave;
     file "db.interface31.lab"; 
     masters { 192.168.72.8; };
};zone "72.168.192.in-addr.arpa" {
     type slave;
     file "db.192.168.72"; 
     masters { 192.168.72.8; };
};

Назначение параметров:

• type — тип зоны, в нашем случае вторичная — slave
• file — имя файла зоны, указываем без путей, файлы вторичных зон хранятся в /var/cache/bind
• masters — адрес нашего первичного сервера с которого вторичный будет забирать изменения

После чего проверяем правильность конфигурации:

named-checkconf

И перезапускаем сервер:

systemctl restart named

На этом настройка вторичного сервера закончена, можем проверить его работу аналогично тому, как мы это делали для первичного сервера.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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-запросы внутри системы.