Вторичный DNS

Резолвер, которому нужно узнать адрес сайта, выбирает любой сервер из NS-записей домена. Если сервер один, его отказ означает, что сайт, почта и всё остальное на домене перестают находиться по имени. Вторичный DNS снимает эту единую точку отказа: копия зоны лежит на другой машине, лучше — у другого провайдера и в другой сети.

Записи правят только на основном сервере, вторичный их не редактирует. Синхронизацию запускает уведомление NOTIFY от основного или таймер refresh из SOA-записи. Вторичный сервер сравнивает серийные номера и, если на основном версия новее, забирает зону целиком через AXFR или только изменения через IXFR.

Пример настройки в BIND

На вторичном сервере зону объявляют с типом secondary и указывают, откуда её брать. Передачу защищают ключом TSIG:

zone "example.ru" {
    type secondary;
    primaries { 203.0.113.10 key "transfer-key"; };
    file "secondary/example.ru.db";
};

В старых версиях BIND те же параметры назывались type slave и masters. На основном сервере нужно разрешить передачу зоны этому ключу и добавить новый сервер в NS-записи — иначе резолверы о нём не узнают.

Схема со скрытым основным сервером

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

Как понять, что синхронизация сломалась

• Серийные номера в ответах разных NS отличаются: dig @ns2.example.ru example.ru SOA +short показывает старую версию.
• Изменения видны не у всех посетителей: часть резолверов попадает на отставший сервер.
• Если вторичный сервер не может связаться с основным дольше срока expire из SOA, он перестаёт отвечать за зону совсем.