BIND — DNS-сервер.

[root]

Оглавление

---

Темы
 Настройка DNS-сервера 
 Обновление списка корневых DNS-серверов 
 Ошибки 
 Однажды у BIND отвалилась рекурсия 
 Практические рекомендации и типичные ошибки 
Дополнительные материалы
Dnsmasq — DNS-, DHCP- и TFTP-сервер
DIG — Диагностика DNS-серверов
ISC DHCP — DHCP-сервер
Wake on Lan: Удалённое включение компьютера
Синхронизация времени
OpenVPN: Открытая виртуальная частная сеть
WireGuard - VPN нового поколения
ISCSI — Транспортный протокол для SCSI
QUAGGA — Протоколы динамической маршрутизации
Dnscrypt — Проксирование dns-трафика

---

 Настройка DNS-сервера 
На сервере поддерживаются несколько зон (для внешней и внутренней сети), а так же для внутренней сети есть зона дубликат с кириллическими именами. Сам сервер разрешает имена во всех зонах, а внутренним и внешним клиентам доступны только соответствующие зоны. Смысл решения подобной задачи чтобы разложить требуемые наборы зон по контейнерам view. Клиент может просматривать только одну view. Все зоны должны принадлежать какому-либо view.
Файл конфигурации named.conf

Код: выделить все

# Список доверенных серверов для передачи зон
acl "trusted-dns" { 195.0.1.1; 195.0.1.8; };
acl "def-client" { 127.0.0.0/8; localhost; };
acl "int-client" { 192.168.1/24; 10/8; };

options {
        listen-on port 53 { 127.0.0.1; 195.0.1.15; 192.168.1.254; };
        listen-on-v6 port 53 { none; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query     { localhost; 127/8; 195.0.1/24; 192.168.1/24; 10/8; };

        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside auto;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";
        pid-file "/run/named/named.pid";
        version "Bind DNS Server";
        session-keyfile "/run/named/session.key";
        forwarders { 212.1.224.6; 212.1.244.6; };
};
logging { channel default_debug { file "data/named.run"; severity dynamic; }; };
include "/etc/named.root.key";

# вид для localhost. Просмотр всех зон
view "default" {
# 127/8; localhost; - Для разрешения имён этим хостом
match-clients { def-client; };
match-destinations { 127.0.0.1; };
# Наш сервер может обрабатывать рекурсивные запросы для localhost
allow-recursion { def-client; };
include "/etc/named.rfc1912.zones";
zone "buch.ru" IN { type master; file "master/buch.ru.zone"; };
zone "1.168.192.IN-ADDR.ARPA" IN  { type master; file "master/1.168.192.zone"; };
zone "free-adm.ru" IN { type master; file "master/free-adm.ru.zone"; };
zone "1.0.195.IN-ADDR.ARPA" IN  { type master; file "master/1.0.195.zone"; };
zone "xn--90a0bg.xn--p1ag" IN { type master; file "master/бух.ру.zone"; };
};

# вид для внутренних зон
view "internal" {
match-clients { int-client; };
     # 127/8; localhost; - Для разрешения имён этим хостом
     # match-destinations - параметр, который является IP-адресом данного view
     # и используется в качестве адреса для этого сервера имен.
match-destinations { 192.168.1.254; };
     #Наш сервер может обрабатывать рекурсивные запросы для внутренних клиентов
allow-recursion { int-client; };

zone "." IN { type hint; file "named.ca"; };
zone "buch.ru" IN { type master; file "master/buch.ru.zone"; };
zone "1.168.192.IN-ADDR.ARPA" IN  { type master; file "master/1.168.192.zone"; };
zone "xn--90a0bg.xn--p1ag" IN { type master; file "master/бух.ру.zone"; };
};

# Вид для внешних зон
view "external" {
match-clients { 195.0.1.0/24; };
match-destinations { 195.0.1.15; };

zone "free-adm.ru" IN { type master;
          file "master/free-adm.ru.zone";
          allow-transfer { trusted-dns; };
          notify yes; };

zone "1.0.195.IN-ADDR.ARPA" IN  { type master;
          file "master/1.0.195.zone";
          allow-transfer { trusted-dns; };
          notify yes; };
};

key "rndc-key" { algorithm hmac-md5;
          secret "u7z0Etzw4tAJGLi9mt75jQ=="; };

#controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; };
controls { inet * allow {  any; } keys { "rndc-key"; }; };

Зона free-adm.ru.zone

Код: выделить все

$TTL 900
$ORIGIN free-adm.ru.
@ SOA cent.free-adm.ru. root (
                      2015042302
                      900                     ; 15 Minutes slave refresh interval
                      600                     ; 10 Minutes slave retry interval
                      2592000              ; 1 month slave copy expire time
                      900                     ; 15 Minutes NXDOMAIN cache time
                )

        NS  cent.free-adm.ru.
        ;; add Slave server
        ;; IN  NS      ns.example.host.
        MX 10 cent.free-adm.ru.

@               A 195.0.1.15

cent            A 195.0.1.15
gate            A 195.0.1.2
sergey          A 195.0.1.3
print           A 195.0.1.5

Зона buch.ru.zone

Код: выделить все

$TTL 900
$ORIGIN buch.ru.
@ SOA ns.buch.ru. root (
                  2015060400
                  900                     ; 15 Minutes slave refresh interval
                  600                     ; 10 Minutes slave retry interval
                  2592000              ; 1 month slave copy expire time
                  900                     ; 15 Minutes NXDOMAIN cache time
                )
                NS  ns.buch.ru.
                MX 10 srv.buch.ru.

@               A 192.168.1.254
ns              A 192.168.1.254
srv             A 192.168.1.254
test            A 192.168.1.254

comp1           A 192.168.1.1
comp2           A 192.168.1.2

Кириллическая зона бух.ру.zone

Код: выделить все

$TTL 900
$ORIGIN xn--90a0bg.xn--p1ag.
@ SOA xn--m1ai.xn--90a0bg.xn--p1ag. root (
                  2015070700
                  900                     ; 15 Minutes slave refresh interval
                  600                     ; 10 Minutes slave retry interval
                  2592000         ; 1 month slave copy expire time
                  900                     ; 15 Minutes NXDOMAIN cache time
                )
                NS  xn--m1ai.xn--90a0bg.xn--p1ag.
                MX 10 xn--b1a1ac.xn--90a0bg.xn--p1ag.

@               A 192.168.1.254
xn--m1ai        A 192.168.1.254
xn--b1a1ac      A 192.168.1.254
test            A 192.168.1.254

xn--80afxl5e    A 192.168.1.1
xn--80a0a4c     A 192.168.1.2

Обратная зона 1.168.192.zone

Код: выделить все

$TTL 900
$ORIGIN 1.168.192.IN-ADDR.ARPA.

@ SOA ns.buch.ru. root (
                2015050300
                900                     ; 15 Minutes slave refresh interval
                600                     ; 10 Minutes slave retry interval
                2592000              ; 1 month slave copy expire time
                900                     ; 15 Minutes NXDOMAIN cache time
           )

         NS ns.buch.ru.

254   PTR buch.ru.
254   PTR ns.buch.ru.
254   PTR srv.buch.ru.

1     PTR comp1.buch.ru.
2     PTR comp2.buch.ru.

Обратная зона 1.0.195.zone

Код: выделить все

$TTL 900
$ORIGIN 1.0.195.in-addr.arpa.
@ SOA cent.free-adm.ru. root (
                        2015042800
                        900                     ; 15 Minutes slave refresh interval
                        600                     ; 10 Minutes slave retry interval
                        2592000         ; 1 month slave copy expire time
                        900                     ; 15 Minutes NXDOMAIN cache time
                      )

      NS cent.free-adm.ru.

15              PTR cent.free-adm.ru.

2               PTR gate.free-adm.ru.
3               PTR sergey.free-adm.ru.
5               PTR print.free-adm.ru.

Создание заготовки файла зоны

Код: выделить все

echo -e "\$TTL 30m\n\$ORIGIN yandex.ru.ru." > yandex.ru.zone
dig yandex.ru -t SOA >> yandex.ru.zone
dig yandex.ru -t ns  >> yandex.ru.zone
dig yandex.ru -t MX  >> yandex.ru.zone

---

Преобразование кириллических имён

Код: выделить все

echo "бух.ру" | idn
xn--90a0bg.xn--p1ag

---

Преобразование адреса в формат обратной зоны
Для преобразования адреса в формат обратной зоны можно воспользоваться утилитой ipcalc с опцией --reverse-dns

Код: выделить все

ipcalc 185.253.217.208 --reverse-dns
REVERSEDNS=208.217.253.185.in-addr.arpa.

Если вместо IPv4 адреса поставить IPv6, то преобразование будет выполнено для адреса IPv6.

Код: выделить все

ipcalc 2000:2cc0:13b1:3333::3 --reverse-dns
REVERSEDNS=3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.3.3.3.1.b.3.1.0.c.c.2.0.0.0.2.ip6.arpa.

Затем нужно отделить хостовую часть адреса от сетевой, полученный результат будет именем обратной зоны

---

Логирование событий

Код: выделить все

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

        channel general { file "/var/log/named/general.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel database { file "/var/log/named/database.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel security { file "/var/log/named/security.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel config { file "/var/log/named/config.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel resolver { file "/var/log/named/resolver.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel xfer-in { file "/var/log/named/xfer-in.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel xfer-out { file "/var/log/named/xfer-out.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel notify { file "/var/log/named/notify.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel client { file "/var/log/named/client.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel unmatched { file "/var/log/named/unmatched.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel network { file "/var/log/named/network.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel update { file "/var/log/named/update.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel update-security { file "/var/log/named/update-security.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel queries { file "/var/log/named/queries.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel query-errors { file "/var/log/named/query-errors.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel dispatch { file "/var/log/named/dispatch.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel dnssec { file "/var/log/named/dnssec.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel lame-servers { file "/var/log/named/lame-servers.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel delegation-only { file "/var/log/named/delegation-only.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel edns-disabled { file "/var/log/named/edns-disabled.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel rpz { file "/var/log/named/rpz.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel rate-limit { file "/var/log/named/rate-limit.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        channel cname { file "/var/log/named/cname.log" versions 3 size 5m;
                severity dynamic;
                print-time yes;
        };

        category default { default; };
        category general { general; };
        category database { database; };
        category security { security; };
        category config { config; };
        category resolver { resolver; };
        category xfer-in { xfer-in; };
        category xfer-out { xfer-out; };
        category notify { notify; };
        category client { client; };
        category unmatched { unmatched; };
        category network { network; };
        category update { update; };
        category update-security { update-security; };
        category queries { queries; };
        category query-errors { query-errors; };
        category dispatch { dispatch; };
        category dnssec { dnssec; };
        category lame-servers { lame-servers; };
        category delegation-only { delegation-only; };
        category edns-disabled { edns-disabled; };
        category rpz { rpz; };
        category rate-limit { rate-limit; };
        category cname { cname; };
};

Если требуется запретить использование IPv6 для DNS-сервера, то необходимо внести строку следующего содержания в конец файла /etc/sysconfig/named

Код: выделить все

OPTIONS="-4"

[root]

---

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

Код: выделить все

dig -r +bufsize=1200 +norec @a.root-servers.net NS . @a.root-servers.net > /var/named/named.ca

-r — Игнорирование пользовательских настроек которые находятся в файле .digrc в домашнем каталоге пользователя
Данной командой получаем список серверов корневой зоны "."

[root]

---

 Ошибки 
Недостаток прав доступа проявляется так

Код: выделить все

error writing NTA file for view 'default': permission denied
error writing NTA file for view 'external': permission denied
error writing NTA file for view '_bind': permission denied

Решение:
добавляем право записи для группы и меняем владельца на named:named для всей структуры файлов и каталогов ниже /var/named

Код: выделить все

chmod g+w /var/named
chown -R named:named /var/named

В log падают сообщения типа:

Код: выделить все

none:103: 'max-cache-size 90%' - setting to 14418MB (out of 16021MB)

Решение:
Добавляем в секцию options конфигурационного файла /etc/named.conf параметр max-cache-size.
Максимальный объем памяти для кэша сервера в байтах. Когда количество данных в кэше достигнет этого предела, сервер заставит записи истекать преждевременно на основе стратегии на основе LRU, чтобы предел не превышался. Ключевое слово unlimited, или значение 0, не будет ограничивать размер кэша; записи будут удалены из кэша только после истечения срока их TTL. Любые положительные значения менее 2 МБ будут проигнорированы и сброшены на 2 МБ. На сервере с несколькими представлениями предел применяется отдельно к кешу каждого представления. Значение по умолчанию не ограничено.

Код: выделить все

max-cache-size 10m;

[root]

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

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

• файлов зон и ресурсных записей;
• роли вершины домена (apex);
• разграничения авторитетного DNS и рекурсивного резолвера;
• взаимодействия BIND и dnscrypt-proxy;
• особенностей AXFR, логирования и контроля доступа;
• вопросов безопасности (IP-based ACL, TSIG).

Этот текст — не учебник и не «best practices» в вакууме. Это хронологический и технический разбор реального пути, борьбы с ошибками, сомнениями, проверками и неожиданными выводами.

---

Этап 1. Проверка и выверка файлов зон
Прямая и обратная зона основного домена локальной сети реально создавалась на пару хостов, чтобы обеспечить разрешение имён для шлюза и самого хоста с eve-ng. Система с eve-ng установлена параллельно с основной, так что описывать все хосты и без того маленькой сети не имело никакого смысла.
Работа началась с самого базового — проверки файлов зон. Были рассмотрены прямые и обратные зоны IPv4 и IPv6. Файлы зон малы, а некоторые крайне малы. Это обусловлено тем что DNS сервер обслуживает тестовый стенд
Пример обратной IPv4-зоны

Код: выделить все

$TTL 900
$ORIGIN 1.0.195.in-addr.arpa.
@   900 IN SOA eve-ng.free-adm.ru. root.free-adm.ru. (
        2025012200 ; serial
        600        ; refresh
        300        ; retry
        2592000    ; expire
        900        ; minimum
)

    NS  eve-ng.free-adm.ru.

3   PTR eve-ng.free-adm.ru.
254 PTR gate.free-adm.ru.

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

Код: выделить все

$TTL 900
$ORIGIN b.6.1.0.1.2.f.1.0.7.4.0.1.0.0.2.ip6.arpa.
@ IN SOA eve-ng.free-adm.ru. root.free-adm.ru. (
    2025012201
    900
    600
    1209600
    60
)

    NS eve-ng.free-adm.ru.

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR gate.free-adm.ru.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR eve-ng.free-adm.ru.
5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR ros.free-adm.ru.

На этом этапе проверялись:

• корректность $ORIGIN;
• соответствие PTR-записей адресному плану;
• согласованность имён с прямой зоной.

Здесь отдельно обсуждалась читаемость и сопровождаемость IPv6-зон, а также то, почему ошибки в nibble-нотации практически не диагностируются «на глаз».

---

Этап 2. Вершина домена и A/AAAA-записи
Отдельным и принципиальным моментом стала вершина домена (zone apex).
Прямая зона free-adm.ru

Код: выделить все

$TTL 900
$ORIGIN free-adm.ru.
@ 900 IN SOA eve-ng.free-adm.ru. root.free-adm.ru. (
    2025122600
    600
    300
    2592000
    900
)

    NS eve-ng.free-adm.ru.

@       A    195.0.1.3
        AAAA 2000:2cc0:13b1:3333::3

eve-ng  A    195.0.1.3
        AAAA 2000:2cc0:13b1:3333::3

gate    A    195.0.1.254
        AAAA 2000:2cc0:13b1:3333::1

forum   A    231.42.188.5

Здесь был сделан принципиальный акцент:

• вершина домена обязана иметь A/AAAA, если она используется как точка входа;
• отсутствие A/AAAA у вершины домена "@" приводит к неочевидным эффектам при резолвинге;
• NS указывают на имя, но это имя должно быть резолвируемым без рекурсии.

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

---

Этап 3. Обнаружение проблемы с рекурсией
После очередного обновления программного обеспечения выяснилось:

• авторитетные зоны работают;
• локальные зоны отвечают корректно;
• рекурсия не работает вообще.

Именно это стало переломным моментом. Было принято архитектурное решение:
разделить роли: BIND — строго авторитетный сервер, рекурсия — вынесена отдельно.

---

Этап 4. Введение dnscrypt-proxy
Для разрешения имён Интернета был выбран dnscrypt-proxy.
Его роль:

• принимать DNS-запросы от системы и клиентов;
• шифровать и отправлять внешние запросы upstream-провайдерам;
• перенаправлять локальные зоны на BIND.

Пример перенаправления локальных зон

Код: выделить все

free-adm.ru                             127.0.0.1:53
free-adm.ru                             [::1]:53
1.0.195.in-addr.arpa                    127.0.0.1:53
1.0.195.in-addr.arpa                    [::1]:53
b.6.1.0.1.2.f.1.0.7.4.0.1.0.0.2.ip6.arpa 127.0.0.1:53
b.6.1.0.1.2.f.1.0.7.4.0.1.0.0.2.ip6.arpa [::1]:53

test.ru                                127.0.0.1:53
test.ru                                [::1]:53

Прокси перенаправляет локальные зоны на 127.0.0.1:53 (или [::1]:53). В результате все AXFR-запросы шли с localhost.
Интересный момент: запрос с IPv6 не использовался для AXFR, хотя соответствующая зона была задана.
Также проверка показала, что dnscrypt-proxy умеет передавать AXFR через TCP, хотя официально протокол не предусматривает управления передачей зон через прокси.
Таким образом:

• BIND не занимается рекурсией вообще;
• dnscrypt-proxy — единственная точка входа для рекурсивных запросов;
• локальные зоны обслуживаются BIND.

---

Этап 5. Неожиданный AXFR
Следующий сюрприз: AXFR начал работать через dnscrypt-proxy. Разбор работы AXFR показал, что для лабораторной среды достаточно ограничений по IP, но в боевых условиях потребуется дополнительная защита, например TSIG-подписи, чтобы предотвратить несанкционированное получение полной зоны.
Также выяснилось, что при использовании прокси и перенаправлении локальных зон на 127.0.0.1 ограничения по IP становятся условными — все запросы фактически идут с одного адреса. Это открывает «ящик Пандоры» с точки зрения безопасности, и любые публичные зоны потребуют внимательной настройки.

Код: выделить все

dig free-adm.ru AXFR

Результат — полноценная передача зоны. Это привело к важному уточнению:

• dnscrypt-proxy не является стороной AXFR-протокола;
• но он проксирует TCP-соединение, не ломая семантику;
• с точки зрения BIND клиентом оказывается 127.0.0.1.

---

Этап 6. Логирование и идентификация клиента
Для понимания источников запросов к серверу включил детальное логирование. В логе BIND каждая попытка передачи зоны отображалась с указанием IP-клиента и порта TCP. Это позволяло отслеживать, какие запросы инициировались локальными прокси и где происходили потенциальные конфликты или ошибки доступа.
Особенно интересен был момент, когда запросы AXFR приходили с IPv4-адреса локального интерфейса, а не с IPv6, что требовало точной настройки allow-transfer.
Включение логов BIND показало:

Код: выделить все

named[1021214]: client @0x7f8d14005068 127.0.0.1#44650 (free-adm.ru): transfer of 'free-adm.ru/IN': AXFR started

Разбор строки:

• @0x7f8d14005068 — внутренний указатель на структуру клиента в памяти BIND;
• 127.0.0.1#44650 — реальный source IP и порт TCP-соединения;
• запрос пришёл не по IPv6, несмотря на наличие AAAA.

Это стало ключевым моментом в понимании:
для BIND все AXFR-запросы через dnscrypt-proxy выглядят как локальные.

---

Этап 7. allow-transfer и «ящик Пандоры»

Для работы AXFR пришлось временно открыть:

Код: выделить все

allow-transfer { 195.0.1.0/24; 195.1.1.0/24; 127.0.0.1; };

Позже выяснилось, что достаточно одного `127.0.0.1`.
Отсюда следствие:

• IP-based ACL теряет смысл;
• любой клиент, дошедший до dnscrypt-proxy, потенциально может инициировать AXFR;
• безопасность смещается на firewall и криптографическую аутентификацию.

---

Этап 8. TSIG как единственное корректное решение
Для TSIG используется tsig-keygen.
tsig-keygen генерирует симметричный HMAC-ключ для TSIG (AXFR, NOTIFY, dynamic update)
dnssec-keygen генерирует асимметричные ключи (KSK/ZSK) DNSSEC (подпись зон)

`dnssec-keygen` не предназначен для TSIG и порождает ключи совершенно другого класса. Иногда его ошибочно используют «потому что тоже ключ», что приводит к путанице и некорректным конфигам.

Корректный пример генерации TSIG

Код: выделить все

tsig-keygen -a hmac-sha256 axfr-key

Вывод будет вида:

Код: выделить все

key "axfr-key" {
    algorithm hmac-sha256;
    secret "n8Zk0WJZk7u7K3m9p5vYxQ==";
};

Использование в BIND (master)

Код: выделить все

key "axfr-key" {
    algorithm hmac-sha256;
    secret "n8Zk0WJZk7u7K3m9p5vYxQ==";
};

zone "free-adm.ru" {
    type master;
    file "/etc/bind/free-adm.ru.zone";
    allow-transfer { key axfr-key; };
    notify yes;
};

Использование в slave (или dig)

Код: выделить все

key "axfr-key" {
    algorithm hmac-sha256;
    secret "n8Zk0WJZk7u7K3m9p5vYxQ==";
};

Проверка AXFR с TSIG через `dig`

dig TSIG поддерживает:

Код: выделить все

dig @127.0.0.1 free-adm.ru AXFR -y axfr-key:n8Zk0WJZk7u7K3m9p5vYxQ==

или через файл:

Код: выделить все

dig @127.0.0.1 free-adm.ru AXFR -k axfr-key.key

В архитектуре:

Код: выделить все

клиенты → dnscrypt-proxy → 127.0.0.1 → BIND

• source IP всегда 127.0.0.1
• IP-ACL (`allow-transfer { 127.0.0.1; };`) **бессмысленен**
• AXFR «прилетает» от кого угодно, но выглядит локальным

TSIG — единственный корректный механизм контроля AXFR
(без выноса BIND на отдельный интерфейс / неймспейс / firewall zone).

Итог

• dnscrypt-proxy не умеет лимитировать AXFR
• TSIG — не “дополнение”, а обязательное условие для такой схемы.
• Для TSIG используйте `tsig-keygen`. DNSSEC-ключи здесь неприменимы.
• TSIG — обязательный механизм для AXFR;
• dig поддерживает TSIG (-y keyname:secret);
• allow-transfer без TSIG — допустим только в лабораторной среде.

---

Заключение
Эта история — пример того, как одна «мелкая» проблема (отвалившаяся рекурсия) приводит к:

• пересмотру архитектуры DNS;
• строгому разделению ролей;
• глубокому пониманию AXFR, TCP, source IP и проксирования;
• осознанию границ IP-based безопасности.

Вот к таким пляскам с бубном привела ошибка разработчиков BIND. Благодоря этому факту удалось разобраться в процессах как BIND так и dnscrypt-proxy.
Годы администрирования действительно не проходят даром, но DNS всё равно находит, чем удивить.

[root]

 Практические рекомендации и типичные ошибки 

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

В статье собраны практические рекомендации, которые полезно соблюдать независимо от используемого DNS-сервера — Bind, PowerDNS, Knot DNS, NSD или облачных DNS-провайдеров.

Для примеров используется домен:

Код: выделить все

example.com

Основной сервер:

Код: выделить все

srv1.example.com
192.0.2.10

---

1. Hostname должен совпадать с основной A-записью

Имя хоста желательно делать каноническим.
Например:

Код: выделить все

srv1.example.com. IN A 192.0.2.10

Если на сервере размещаются несколько сайтов или сервисов, не нужно плодить дополнительные A-записи на один и тот же IP.

Лучше использовать CNAME:

Код: выделить все

http://www.example.com.    IN CNAME srv1.example.com.
cloud.example.com.  IN CNAME srv1.example.com.
git.example.com.    IN CNAME srv1.example.com.

Это упрощает сопровождение: при смене IP необходимо изменить только одну запись.

---

2. Золотое правило SOA

Запись SOA определяет поведение зоны для вторичных серверов и кэширующих резолверов.
Разумные значения:

Код: выделить все

Refresh: 3600
Retry: 900
Expire: 1209600
Negative TTL: 3600

Не рекомендуется:

• слишком маленький `Refresh`;
• большой `Negative TTL`;
• указание фиктивного master-сервера.

Пример:

Код: выделить все

example.com. IN SOA ns1.example.com. hostmaster.example.com. (
    2026071501
    3600
    900
    1209600
    3600
)

---

3. Правило «Glue Records»

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

Плохой пример

Код: выделить все

example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.

Получается ситуация «курицы и яйца»:
Чтобы узнать IP `ns1.example.com`, необходимо спросить у `ns1.example.com`.

Правильно

Код: выделить все

example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.

ns1.example.com. IN A 192.0.2.53
ns2.example.com. IN A 192.0.2.54

Именно эти записи называются Glue Records.

---

4. Правило «CNAME и другие записи»

Согласно RFC, имя, имеющее CNAME, не может содержать другие типы записей.
Неправильно

Код: выделить все

example.com. IN CNAME my-hosting-provider.com.
example.com. IN MX 10 mail.example.com.

Bind и большинство других DNS-серверов просто откажутся загружать такую зону.
Правильно

Код: выделить все

example.com. IN A 192.0.2.10
example.com. IN MX 10 mail.example.com.

или использовать специальные механизмы DNS-провайдера:

Код: выделить все

example.com. IN ALIAS my-hosting-provider.com.

---

5. MX-записи должны указывать на A или AAAA

MX не должен ссылаться на CNAME.

Неправильно

Код: выделить все

mx.example.com. IN CNAME mail.example.com.
example.com.    IN MX 10 mx.example.com.

Правильно

Код: выделить все

mail.example.com. IN A 192.0.2.25
example.com.      IN MX 10 mail.example.com.

Резервный MX должен реально существовать и принимать почту.

Например:

Код: выделить все

example.com. IN MX 10 mail1.example.com.
example.com. IN MX 100 mail2.example.com.

---

6. PTR и принцип Forward-Confirm Reverse

Для почтовых серверов крайне желательно соблюдать правило:

Код: выделить все

IP → PTR → A → тот же IP

Правильно

Код: выделить все

25.113.0.203.in-addr.arpa. IN PTR mail.example.com.
mail.example.com.          IN A 203.0.113.25

Несоблюдение этого принципа часто приводит к попаданию писем в спам.

---

7. TTL — кэширование с умом

Для стабильных сервисов:

Код: выделить все

TTL 86400

Для планируемой миграции:

За сутки до переноса:

Код: выделить все

TTL 300

или

Код: выделить все

TTL 60

После завершения работ TTL можно снова увеличить.

Не рекомендуется использовать:

Код: выделить все

TTL 0

без крайней необходимости.

---

8. Соглашение об именах служебных записей

DKIM

Код: выделить все

selector._domainkey.example.com.

DMARC

Код: выделить все

_dmarc.example.com.

SRV

Формат строго определён:

Код: выделить все

_service._proto.name.

Например:

Код: выделить все

_xmpp._tcp.example.com.
_sip._tcp.example.com.
_ldap._tcp.example.com.

---

9. Wildcard-записи

Распространённое заблуждение:

Код: выделить все

*.example.com. IN A 192.0.2.10

не покрывает:

Код: выделить все

example.com

Wildcard работает только для отсутствующих поддоменов.
Поэтому необходимо:

Код: выделить все

example.com.   IN A 192.0.2.10
*.example.com. IN A 192.0.2.10

---

10. CAA

Если используются TLS-сертификаты, рекомендуется ограничить список доверенных центров сертификации.

Например:

Код: выделить все

example.com. IN CAA 0 issue "letsencrypt.org"

Это предотвращает выпуск сертификатов сторонними CA.

---

11. DNSSEC

При использовании DNSSEC необходимо:

• * контролировать сроки жизни ключей;
• своевременно выполнять ротацию KSK и ZSK;
• проверять наличие цепочки доверия.

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

---

12. Round-Robin DNS

Несколько A-записей:

Код: выделить все

http://www.example.com. IN A 192.0.2.10
http://www.example.com. IN A 192.0.2.11
http://www.example.com. IN A 192.0.2.12

работают как примитивный балансировщик.

Однако DNS не контролирует состояние серверов. Если один из адресов перестанет отвечать, часть клиентов будет продолжать получать его из кэша до истечения TTL.

---

13. Никаких «висящих» записей

При удалении сервера необходимо проверять:

• CNAME;
• MX;
• SRV;
• PTR;
• TXT.

Записи, указывающие на несуществующие имена, являются частой причиной трудноуловимых ошибок и таймаутов приложений.

---

Краткий свод правил

1. Один хост — одна каноническая A/AAAA-запись.
2. Дополнительные имена — через CNAME.
3. Не смешивать CNAME с другими типами записей.
4. MX должен ссылаться только на A/AAAA.
5. Соблюдать правило PTR → A → тот же IP.
6. Использовать разумные TTL.
7. Не забывать про Glue Records.
8. Соблюдать синтаксис SRV, DKIM и DMARC.
9. Осторожно использовать Wildcard.
10. Использовать CAA и DNSSEC там, где это оправдано.
11. Регулярно проводить аудит зоны и удалять устаревшие записи.

Получилась не просто памятка, а практически готовая глава для раздела форума по DNS и Bind.