Тест DNS и делегирование в ISPConfig

Кратко: проверьте корректность зон и записей через dig на оба DNS‑сервера (master и slave). После создания записей убедитесь, что оба сервера возвращают одинаковые результаты, затем укажите ваши серверы как авторитетные в панели регистратора. Ниже — пошаговые команды, разбор выводов, отладочные сценарии и чеклисты.

Важные термины (1 строка каждое):

DNS zone — конфигурация домена на DNS‑сервере со всеми записями.
SOA serial — номер версии зоны, при изменениях увеличивается.
TTL — время жизни записи в кэше в секундах.

Тестирование (6 Testing)

Цель этой секции — убедиться, что зона и записи созданы на server1.example.com и server2.example.com и что оба сервера корректно их обслуживают. Для этого используется утилита dig. Команды можно запускать с любого сервера (server1.example.com, server2.example.com или любого другого хоста).

Команда для запроса всех записей у сервера server1.example.com:

dig @server1.example.com any mydomain.com

Ниже приведён пример вывода, который должен выглядеть примерно так:

root@server1:~#\tdig\t@server1.example.com\tany\tmydomain.com  
  
;\t<<>>\tDiG\t9.7.3\t<<>>\t@server1.example.com\tany\tmydomain.com  
;\t(1\tserver\tfound)  
;;\tglobal\toptions:\t+cmd  
;;\tGot\tanswer:  
;;\t->>HEADER<<-\topcode:\tQUERY,\tstatus:\tNOERROR,\tid:\t45584  
;;\tflags:\tqr\taa\trd\tra;\tQUERY:\t1,\tANSWER:\t5,\tAUTHORITY:\t0,\tADDITIONAL:\t1  
  
;;\tQUESTION\tSECTION:  
;mydomain.com.\t\t\t\t\t\tIN\t\t\tANY  
  
;;\tANSWER\tSECTION:  
mydomain.com.\t\t\t86400\t\tIN\t\t\tA\t\t78.46.230.214  
mydomain.com.\t\t\t86400\t\tIN\t\t\tMX\t\t10\tmail.mydomain.com.  
mydomain.com.\t\t\t86400\t\tIN\t\t\tNS\t\tserver1.example.com.  
mydomain.com.\t\t\t86400\t\tIN\t\t\tNS\t\tserver2.example.com.  
mydomain.com.\t\t\t86400\t\tIN\t\t\tSOA\t\tserver1.example.com.\tzonemaster.example.com.\t2011071901\t28800\t7200\t604800\t86400  
  
;;\tADDITIONAL\tSECTION:  
mail.mydomain.com.\t\t86400\t\tIN\t\t\tA\t\t78.46.230.214  
  
;;\tQuery\ttime:\t0\tmsec  
;;\tSERVER:\t1.2.3.4#53(1.2.3.4)  
;;\tWHEN:\tTue\tJul\t19\t14:09:38\t2011  
;;\tMSG\tSIZE\t\trcvd:\t182  
  
root@server1:~#

Аналогично проверяем server2.example.com:

dig @server2.example.com any mydomain.com

Ожидаемый пример вывода (server2):

root@server1:~#\tdig\t@server2.example.com\tany\tmydomain.com  
  
;\t<<>>\tDiG\t9.7.3\t<<>>\t@server2.example.com\tany\tmydomain.com  
;\t(1\tserver\tfound)  
;;\tglobal\toptions:\t+cmd  
;;\tGot\tanswer:  
;;\t->>HEADER<<-\topcode:\tQUERY,\tstatus:\tNOERROR,\tid:\t5183  
;;\tflags:\tqr\taa\trd\tra;\tQUERY:\t1,\tANSWER:\t5,\tAUTHORITY:\t0,\tADDITIONAL:\t1  
  
;;\tQUESTION\tSECTION:  
;mydomain.com.\t\t\t\t\t\tIN\t\t\tANY  
  
;;\tANSWER\tSECTION:  
mydomain.com.\t\t\t86400\t\tIN\t\t\tA\t\t78.46.230.214  
mydomain.com.\t\t\t86400\t\tIN\t\t\tMX\t\t10\tmail.mydomain.com.  
mydomain.com.\t\t\t86400\t\tIN\t\t\tNS\t\tserver2.example.com.  
mydomain.com.\t\t\t86400\t\tIN\t\t\tNS\t\tserver1.example.com.  
mydomain.com.\t\t\t86400\t\tIN\t\t\tSOA\t\tserver1.example.com.\tzonemaster.example.com.\t2011071901\t28800\t7200\t604800\t86400  
  
;;\tADDITIONAL\tSECTION:  
mail.mydomain.com.\t\t86400\t\tIN\t\t\tA\t\t78.46.230.214  
  
;;\tQuery\ttime:\t0\tmsec  
;;\tSERVER:\t1.2.3.5#53(1.2.3.5)  
;;\tWHEN:\tTue\tJul\t19\t14:10:07\t2011  
;;\tMSG\tSIZE\t\trcvd:\t182  
  
root@server1:~#

Вы также можете проверять любые поддомены, например www и mail, выполнив:

dig @server1.example.com any www.mydomain.com

dig @server2.example.com any www.mydomain.com

dig @server1.example.com any mail.mydomain.com

dig @server2.example.com any mail.mydomain.com

Если оба сервера возвращают ожидаемые записи — настройка primary/secondary DNS работает.

Разбор вывода dig — что важно смотреть

HEADER: статус запроса (NOERROR — всё ок).
flags: qr (ответ), aa (authoritative answer), rd/ra — рекурсивные опции. Наличие aa полезно — означает, что сервер выдал авторитетный ответ по зоне.
ANSWER SECTION: в ней основные записи (A, MX, NS, SOA, TXT).
ADDITIONAL SECTION: дополнительные записи, например A для mail.
SOA: содержит поля: MNAME (primary), RNAME (администратор), serial (серийный номер зоны), refresh, retry, expire, minimum/TTL. Серийный номер должен увеличиваться при изменениях зоны.

Создание дополнительных записей (7 Creating Further Records)

Покажем создание SPF‑записи (она хранится как TXT). В ISPConfig в разделе Records нажмите TXT и заполните поля:

Hostname: имя записи (FQDN с точкой на конце или просто hostname без точки). Пример: mydomain.com. (если забыть точку — получится mydomain.com.mydomain.com.).
Text: содержимое TXT/SPF, например v=spf1 a mx ptr -all — можно сгенерировать через SPF‑визард.
TTL: время жизни в секундах.
Active: активна запись или нет.

Форма добавления TXT-записи в интерфейсе ISPConfig (поля Hostname, Text, TTL, Active)

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

dig @server1.example.com any mydomain.com

Пример вывода с TXT‑записью (обратите внимание на строку с TXT):

root@server1:~#\tdig\t@server1.example.com\tany\tmydomain.com  
  
;\t<<>>\tDiG\t9.7.3\t<<>>\t@server1.example.com\tany\tmydomain.com  
;\t(1\tserver\tfound)  
;;\tglobal\toptions:\t+cmd  
;;\tGot\tanswer:  
;;\t->>HEADER<<-\topcode:\tQUERY,\tstatus:\tNOERROR,\tid:\t23141  
;;\tflags:\tqr\taa\trd\tra;\tQUERY:\t1,\tANSWER:\t6,\tAUTHORITY:\t0,\tADDITIONAL:\t1  
  
;;\tQUESTION\tSECTION:  
;mydomain.com.\t\t\t\t\t\tIN\t\t\tANY  
  
;;\tANSWER\tSECTION:  
mydomain.com.\t\t\t86400\t\tIN\t\t\tA\t\t78.46.230.214  
mydomain.com.\t\t\t86400\t\tIN\t\t\tMX\t\t10\tmail.mydomain.com.  
mydomain.com.\t\t\t86400\t\tIN\t\t\tNS\t\tserver2.example.com.  
mydomain.com.\t\t\t86400\t\tIN\t\t\tNS\t\tserver1.example.com.  
mydomain.com.\t\t\t86400\t\tIN\t\t\tTXT\t\t"v=spf1\ta\tmx\tptr\t-all"  
mydomain.com.\t\t\t86400\t\tIN\t\t\tSOA\t\tserver1.example.com.\tzonemaster.example.com.\t2011071903\t28800\t7200\t604800\t86400  
  
;;\tADDITIONAL\tSECTION:  
mail.mydomain.com.\t\t86400\t\tIN\t\t\tA\t\t78.46.230.214  
  
;;\tQuery\ttime:\t0\tmsec  
;;\tSERVER:\t1.2.3.4#53(1.2.3.4)  
;;\tWHEN:\tTue\tJul\t19\t14:23:19\t2011  
;;\tMSG\tSIZE\t\trcvd:\t215  
  
root@server1:~#

И проверка на server2.example.com:

dig @server2.example.com any mydomain.com

Пример вывода с тем же TXT:

root@server1:~#\tdig\t@server2.example.com\tany\tmydomain.com  
  
;\t<<>>\tDiG\t9.7.3\t<<>>\t@server2.example.com\tany\tmydomain.com  
;\t(1\tserver\tfound)  
;;\tglobal\toptions:\t+cmd  
;;\tGot\tanswer:  
;;\t->>HEADER<<-\topcode:\tQUERY,\tstatus:\tNOERROR,\tid:\t13876  
;;\tflags:\tqr\taa\trd\tra;\tQUERY:\t1,\tANSWER:\t6,\tAUTHORITY:\t0,\tADDITIONAL:\t1  
  
;;\tQUESTION\tSECTION:  
;mydomain.com.\t\t\t\t\t\tIN\t\t\tANY  
  
;;\tANSWER\tSECTION:  
mydomain.com.\t\t\t86400\t\tIN\t\t\tA\t\t78.46.230.214  
mydomain.com.\t\t\t86400\t\tIN\t\t\tMX\t\t10\tmail.mydomain.com.  
mydomain.com.\t\t\t86400\t\tIN\t\t\tNS\t\tserver1.example.com.  
mydomain.com.\t\t\t86400\t\tIN\t\t\tNS\t\tserver2.example.com.  
mydomain.com.\t\t\t86400\t\tIN\t\t\tTXT\t\t"v=spf1\ta\tmx\tptr\t-all"  
mydomain.com.\t\t\t86400\t\tIN\t\t\tSOA\t\tserver1.example.com.\tzonemaster.example.com.\t2011071903\t28800\t7200\t604800\t86400  
  
;;\tADDITIONAL\tSECTION:  
mail.mydomain.com.\t\t86400\t\tIN\t\t\tA\t\t78.46.230.214  
  
;;\tQuery\ttime:\t1\tmsec  
;;\tSERVER:\t1.2.3.5#53(1.2.3.5)  
;;\tWHEN:\tTue\tJul\t19\t14:23:36\t2011  
;;\tMSG\tSIZE\t\trcvd:\t215  
  
root@server1:~#

Более подробные инструкции по созданию зон и записей есть в главах 4.8 и 5.12 руководства ISPConfig 3.

Делегирование: назначение server1.example.com и server2.example.com авторитетными (8 Setting server1…)

Когда всё работает локально, нужно сделать server1.example.com и server2.example.com официальными (authoritative) NS для вашего домена у регистратора. Без этого внешние резолверы будут обращаться к DNS серверам регистратора, а не к вашим ISPConfig-серверам.

Шаги:

Убедитесь, что на ISPConfig серверах созданы все нужные записи и зоны. Некоторые регистраторы проверяют наличие записей на указываемых NS.
В панели регистратора найдите управление DNS/Name Servers для домена.
Установите server1.example.com и server2.example.com как первичный и вторичный NS.

Пример интерфейса регистратора (ResellerClub):

Пример панели регистратора: указание авторитетных серверов имён (ResellerClub)

Совет: если вы регистрируете новый домен и хотите с самого начала использовать свои ISPConfig‑серверы, сначала создайте зону на ISPConfig, затем при регистрации укажите ваши NS. Так вы избежите периода, когда регистратор направляет на сервера, где ещё нет записей.

Примечание важности сериалов (SOA serial)

При каждом изменении зоны увеличивайте SOA serial (ISPConfig делает это автоматически). Slave‑серверы по протоколу зоны узнают о смене serial и запросят новую версию. Если serial не увеличивается, slave не обновит зону.

Отладка и распространённые проблемы

Чеклист при проблемах с появлением записей:

Зона действительно существует на master.
Master нотифицирует slave (notify) или slave делает периодический AXFR.
Нет сетевых блокировок (firewall/iptables) для TCP/53 и UDP/53 между серверами.
named/named‑service запущен и слушает на нужных интерфейсах (проверьте netstat/ss).
Нет ошибок в логах (/var/log/syslog, /var/log/messages, журнал bind9).
SOA serial увеличен после внесения изменений.
TTL и кэширование: иногда нужны минуты/часы, чтобы изменения дошли до всех резолверов.

Команды для отладки (примеры):

Проверить слушающие сокеты:

ss -ltnup | grep :53

Проверить доступность TCP/53 с другой машины:

nc -zv server2.example.com 53

Перезагрузить/перечитать зону (BIND):

rndc reload mydomain.com
named-checkzone mydomain.com /etc/bind/zones/db.mydomain.com

Посмотреть логи (пример):

tail -n 200 /var/log/syslog | grep named

Трассировка резолвинга через корневые сервера:

dig +trace mydomain.com

Проверка запроса от публичного резолвера Google:

dig @8.8.8.8 mydomain.com A

Типичные ошибки и их причины

Запись не появляется на slave: master не отправляет notify или firewall блокирует соединение.
Несоответствие записей у master и slave: проблема синхронизации/AXFR отказан.
TXT/SPF не виден у внешних резолверов: возможно регистратор всё ещё указывает другие NS (нужно дождаться делегирования).
Некорректный Hostname в форме ISPConfig (забытая точка в FQDN) — приводит к созданию неправильно именованной записи.

Мини‑плейбук: быстрые действия при проблеме «запись не видна»

Проверить локально на master:
- dig @localhost any mydomain.com
Проверить на slave:
- dig @server2.example.com any mydomain.com
Если slave не видит изменения: проверить сетевой доступ и логи, запустить rndc reload на master.
Проверить у регистратора, что NS у домена настроены верно.
Если проблема в кэше резолвера, принудительно проверить у публичных резолверов (8.8.8.8, 1.1.1.1).

Решение о том, когда считать задачу завершённой — критерии приёмки

Критерии приёмки для правильного развёртывания DNS:

Оба сервера (master и slave) отвечают на запросы и помечают ответ как authoritative (флаг aa).
ANSWER SECTION содержит все ожидаемые записи (A, MX, NS, TXT, CNAME и т. д.).
SOA serial актуален и увеличился после последнего изменения.
Записи доступны через публичные рекурсивные резолверы (например, 8.8.8.8).
Регистратор домена указывает ваши server1.example.com и server2.example.com как авторитетные NS (при необходимости).

Дополнительные проверки безопасности и приватности

Не храните в DNS чувствительные данные (пароли, внутренние IP в публичной зоне).
Если у вас есть внутренние зоны — держите их отдельно и не делегируйте в публичный DNS.
Убедитесь, что доступ к панели ISPConfig защищён HTTPS и ограничен по IP, если это возможно.

Быстрый мониторинг и SLA‑навыки (кратко)

Настройте мониторинг доступности DNS (TCP/UDP 53) и alerting при недоступности.
Для критичных служб добавьте третий удалённый slave в другую подсеть/дата‑центр.

Полезные альтернативы и инструменты

Онлайн‑проверки: MXToolbox, DNSViz, IntoDNS — дают анализ делегирования и потенциальных проблем.
Локальные утилиты: dig, nslookup, host, rndc, named‑checkzone.

Decision flowchart (Mermaid) — быстрая логика при отладке

flowchart TD
  A[Запись не видна извне] --> B{Появляется ли запись на master?}
  B -- Да --> C{Появляется ли запись на slave?}
  B -- Нет --> D[Проверьте ISPConfig: создана ли зона и запись]
  C -- Да --> E[Проверьте регистратор: указаны ли ваши NS]
  C -- Нет --> F[Проверьте сетевой доступ, notify/AXFR и логи]
  D --> G[Исправьте запись на master и увеличьте serial]
  F --> H[Разрешите TCP/UDP 53, перезапустите named, проверьте rndc]
  E --> I[Если NS указаны — проверьте у публичных резолверов]

Ролевые чеклисты

Администратор DNS:
- Проверил присутствие зоны и записей на master.
- Убедился, что master отправляет notify/slave может тянуть AXFR.
- Проверил логи и сетевые правила.
Оператор регистратора / DevOps:
- Указал server1 и server2 как NS в панели регистратора.
- Проверил, что регистратор принял NS и не выдаёт ошибок.
Разработчик / владелец сервиса:
- Убедился, что A/MX/CNAME/TXT записи соответствуют ожиданиям сервиса.
- Протестировал доставку почты (если затронут MX/SPF).

Заключение — краткое резюме

Если оба сервера возвращают одинаковые записи и помечают ответ как авторитетный, а регистратор домена указывает ваши NS — система настроена корректно. Регулярно проверяйте SOA serial, логи и сетевые правила. При проблемах используйте приведённый чеклист и flowchart для пошаговой отладки.