--- id: "name-server" kind: "glossary-term" title: "DNS-сервер" language: "ru" category: "DNS и технические основы" updated: "2026-10-10T23:13:06Z" canonical: "https://tldlog.com/ru/glossariy/dns-server/" translations: en: "https://tldlog.com/glossary/name-server/" es: "https://tldlog.com/es/glosario/servidor-nombres/" de: "https://tldlog.com/de/glossar/nameserver/" fr: "https://tldlog.com/fr/glossaire/serveur-noms/" it: "https://tldlog.com/it/glossario/name-server/" pt-BR: "https://tldlog.com/pt/glossario/servidor-nomes/" zh-Hans: "https://tldlog.com/zh/cihui/yuming-fuwuqi/" --- # DNS-сервер Сервер, который хранит записи DNS и отвечает на запросы о доменных именах. Чтобы домен работал, регистратор сообщает регистратуре, на каких DNS-серверах находятся его записи. Смена DNS-серверов домена меняет то, где находятся его сайт и электронная почта. DNS-сервер (сервер имен) – это компьютер, который отвечает на вопрос, где находятся сайт или почта домена. У каждого домена их должно быть не менее двух, и регистратор указывает их в регистратуре. Если их нет, они указаны неверно или выключены, домен перестает работать, хотя и остается зарегистрированным. ## Что DNS-сервер делает для домена Термины «сервер имен» и «DNS-сервер» охватывают две функции. Авторитативные серверы хранят записи DNS домена и отвечают за него; резолверы задают эти вопросы от имени пользователей. RFC 9499 (март 2024 года), документ о терминологии DNS, отмечает, что и те и другие часто называют серверами имен. Здесь термин означает авторитативные серверы. Зона уровнем выше домена, которую ведет регистратура его TLD, содержит записи NS с именами серверов домена. Это делегирование подсказывает резолверам, куда обращаться. Регистратор передает эти имена в регистратуру по протоколу EPP. Домен без DNS-серверов имеет статус inactive и не разрешается. RFC 1034 (ноябрь 1987 года) требует, чтобы каждая зона размещалась не менее чем на двух серверах и могла пережить отказ одного из них. Отчет SSAC SAC125 (9 мая 2024 года) отмечает, что регистратуры обычно требуют не менее двух серверов при регистрации и при каждом изменении. ## Регистратор, DNS-провайдер и хостинг: кто управляет DNS-серверами Задействованы три роли, которые может выполнять одна компания или три разные: - Регистратор указывает в регистратуре, какие DNS-серверы использует домен. - DNS-провайдер управляет этими серверами и зоной с записями домена. Это может быть регистратор, хостинг-провайдер или специализированная компания. - Веб- и почтовый хостинг обеспечивают работу сервисов, на которые указывают записи. Смена DNS-провайдера не меняет регистратора: заменяются только DNS-серверы, указанные для домена. ## Как сменить DNS-серверы: пошагово 1. Сначала настроить зону у нового DNS-провайдера со всеми записями, которые использует домен, включая сайт и почту, и с записями NS, соответствующими новым DNS-серверам. 2. Если домен подписан DNSSEC, запись DS, которая по-прежнему указывает на старые ключи, может привести к сбою у резолверов, проверяющих подписи. Если прежний оператор не идет навстречу, RFC 6781 описывает такой порядок: запросить удаление записи DS, сменить DNS-серверы, дождаться распространения изменения в DNS, затем добавить запись DS для заново подписанной зоны. До этого момента домен не защищен DNSSEC. 3. Убедиться, что домен не заблокирован от изменений: пока установлен статус clientUpdateProhibited или serverUpdateProhibited, регистратура отклоняет изменения. Статус clientUpdateProhibited снимает регистратор; serverUpdateProhibited (блокировку на уровне регистратуры, registry lock) может снять только регистратура, через регистратора. 4. Указать новые DNS-серверы у регистратора, который передаст их в регистратуру. Указать не менее двух, желательно в разных сетях. 5. Некоторое время не отключать старый сервис: резолверы хранят копии ответов, поэтому часть посетителей еще несколько часов или дольше попадает на старые серверы. Не удалять старую зону в тот же день. Правила, блокировки и сроки зависят от регистратуры и регистратора, поэтому перед изменением важного домена их стоит уточнить. ## Связующие записи и DNS-серверы внутри собственного домена Возьмем example.com с DNS-серверами ns1.example.com и ns2.example.com. Чтобы найти ns1.example.com, резолверу сначала пришлось бы обратиться к DNS-серверам example.com, то есть к тем самым серверам, которые он ищет. Решение дает glue-запись (glue record): регистратура публикует IP-адреса этих серверов вместе с делегированием. RFC 9471 (сентябрь 2023 года) делает такие записи обязательными в ответах-перенаправлениях; на тот момент, как отмечено в нем, адреса (записи A и AAAA) были единственным определенным видом glue-записей. В регистратуре каждый DNS-сервер представлен объектом хоста (host object). Поскольку ns1.example.com находится внутри example.com, сначала должен существовать домен; затем регистратор создает объект хоста с его IP-адресами и связывает с ним домен. Адреса требуются только тогда, когда нужна glue-запись: если бы example.com использовал ns1.example.net, регистратуре .com не потребовалась бы для него glue-запись. ## Первичные и вторичные серверы и почему важна избыточность Первичный сервер хранит копию зоны, в которую вносятся изменения. Вторичные серверы копируют ее путем передачи зоны: полная передача (AXFR) копирует всю зону, инкрементальная (IXFR) только изменения. Протокол DNS UPDATE (RFC 2136), стандартная часть динамической DNS, добавляет или удаляет записи без ручного редактирования зоны. Два сервера являются минимумом, а не рекомендацией: RFC 2182 (июль 1997 года) предупреждает, что зона только с двумя серверами после отказа одного из них фактически работает на одном, и рекомендует для большинства организаций три сервера, причем хотя бы один должен быть хорошо удален от остальных, а для более высокой надежности четыре или пять. Технические требования IANA (последняя редакция от 14 ноября 2024 года, по состоянию на октябрь 2026 года) относятся только к корневой зоне, .INT и .ARPA, но служат полезным контрольным списком: не менее двух записей NS с разными IP-адресами, серверы как минимум в двух топологически разных сетях, авторитативные ответы и отсутствие рекурсивного сервиса. ## Что идет не так: некорректное делегирование и забытые серверы Термином «lame delegation» (некорректное делегирование) обозначают несколько неисправностей: указанный сервер не отвечает, недоступен или отвечает с ошибкой либо неавторитативно. RFC 9499 рекомендует более точные формулировки. В любом случае поиск замедляется или не срабатывает. Частая причина в забытом сервере: регистрант уходит от DNS-провайдера, не изменив записи NS, и домен остается делегированным на серверы, которые за него больше не отвечают, что может открыть путь к захвату. Менее заметный риск: по данным SAC125, большинство регистратур отказываются удалять истекший домен, пока от него зависят другие домены, а RFC 5731 указывает, что его не следует удалять, пока не удалены или не переименованы его объекты хостов. Некоторые регистраторы переименовывали их в другой домен. SAC125 называет такие серверы жертвенными (sacrificial name servers); они небезопасны, если этот другой домен можно зарегистрировать: тот, кто его зарегистрирует, контролирует разрешение всех доменов, которые еще используют эти серверы. По данным отчета, по состоянию на сентябрь 2020 года это подвергло риску захвата более 500 000 доменов gTLD, а разрешение более 163 000 доменов оказалось под несанкционированным контролем; SAC125 отмечает, что масштаб проблемы в ccTLD неизвестен. Отчет рекомендует кодекс поведения для регистратур и регистраторов; по состоянию на октябрь 2026 года принятие такого кодекса не подтверждено. Продление доменов, на которых размещены DNS-серверы, снижает этот риск. ## Источники - [RFC 9499: DNS Terminology](https://www.rfc-editor.org/rfc/rfc9499.txt) - [RFC 2182: Selection and Operation of Secondary DNS Servers](https://www.rfc-editor.org/rfc/rfc2182.txt) - [RFC 6781: DNSSEC Operational Practices, Version 2](https://www.rfc-editor.org/rfc/rfc6781.txt) - [Technical requirements for authoritative name servers (IANA)](https://www.iana.org/help/nameserver-requirements) - [SAC125: SSAC Report on Registrar Nameserver Management](https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-125-09-05-2024-en.pdf) ## связанные термины - [авторитативный сервер](https://tldlog.com/ru/glossariy/avtoritativnyy-server/) - [NS-запись](https://tldlog.com/ru/glossariy/ns-zapis/) - [glue-запись](https://tldlog.com/ru/glossariy/glue-zapis/) - [DNS](https://tldlog.com/ru/glossariy/dns/)