--- id: "dnssec" kind: "glossary-term" title: "DNSSEC" language: "ru" category: "DNS и технические основы" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/ru/glossariy/dnssec/" translations: en: "https://tldlog.com/glossary/dnssec/" es: "https://tldlog.com/es/glosario/dnssec/" de: "https://tldlog.com/de/glossar/dnssec/" fr: "https://tldlog.com/fr/glossaire/dnssec/" it: "https://tldlog.com/it/glossario/dnssec/" pt-BR: "https://tldlog.com/pt/glossario/dnssec/" zh-Hans: "https://tldlog.com/zh/cihui/dnssec/" --- # DNSSEC расширения безопасности DNS Расширения DNS, которые добавляют к ответам DNS цифровые подписи. Подписи позволяют резолверу (серверу, который ищет имена для пользователей) проверить, что ответ подлинный и не был изменен по пути. Владельцы включают DNSSEC через своего DNS-провайдера и регистратора. DNSSEC добавляет цифровые подписи к ответам системы доменных имен (DNS), чтобы компьютер мог проверить, что ответ исходит от владельца домена и не был изменен по пути. DNSSEC ничего не скрывает и защищает не от всех атак. Чтобы включить его, должны совместно действовать DNS-провайдер, регистратор и регистратура. ## От чего защищает DNSSEC, простыми словами Когда кто-то открывает example.com, резолвер ищет его адрес. Без DNSSEC злоумышленник, подсунувший резолверу поддельный ответ, может отправить посетителей на чужой сервер. С DNSSEC проверяющий резолвер сверяет подпись и отклоняет подделку. RFC 4033 (март 2005 года) определяет, что дает DNSSEC: подтверждение происхождения и целостности данных DNS. Конфиденциальности он не обеспечивает, поэтому ответы остаются читаемыми, и не защищает от атак типа «отказ в обслуживании». Он охватывает только ответы DNS, но не фишинг и не захват аккаунта у регистратора. RFC 9364 (февраль 2023 года) называет DNSSEC лучшей текущей практикой проверки подлинности данных DNS; использовать ли его для домена, решает владелец. ## Как работает цепочка доверия от корня до домена Проверяющий резолвер начинает с одного ключа, которому он уже доверяет: якоря доверия, то есть ключа подписи ключей (Key Signing Key) корневой зоны, который публикует IANA. Дальше он идет по цепочке: 1. В корневой зоне есть подписанная запись DS для .com. 2. Эта запись DS соответствует ключу в зоне .com, что позволяет резолверу проверить записи .com, включая запись DS для example.com. 3. Эта запись DS соответствует ключу example.com, который подтверждает собственные записи домена. Подписанная зона, для которой в родительской зоне нет записи DS, называется «островом безопасности»: ее нельзя проверить, начиная от корня. Ответ считается безопасным (secure), если проходят проверку все подписи; небезопасным (insecure), если подписанное доказательство показывает, что в родительской зоне нет записи DS для этой зоны; и поддельным (bogus), если ожидаемые подписи отсутствуют, истекли или непригодны (RFC 4033). На поддельный ответ резолвер обычно возвращает ошибку SERVFAIL (RFC 4035). ## Ключи и записи: KSK, ZSK, DNSKEY, DS и RRSIG - Записи **DNSKEY** публикуют открытые ключи зоны. - Записи **RRSIG** содержат подписи, каждая из которых действительна только между датой начала и датой истечения. - Записи **DS** находятся в родительской зоне и содержат тег ключа, номер алгоритма и хеш ключа дочерней зоны. - **KSK** подписывает только набор ключей зоны, и на него указывает запись DS в родительской зоне. **ZSK** подписывает все остальное. RFC 6781 (декабрь 2012 года) отмечает, что проверяющие резолверы обращаются с обоими видами ключей одинаково: разделение носит эксплуатационный характер, и в некоторых зонах один ключ выполняет обе роли. Для доказательства того, что имя не существует, нужны отдельные записи. NSEC называет следующее существующее имя, что позволяет любому получить список всей зоны («обход зоны», zone walking). NSEC3 (RFC 5155) сначала хеширует имена, хотя все равно раскрывает некоторые сведения, например размер зоны. ## Как включить DNSSEC: что делают регистратор, регистратура и DNS-провайдер 1. DNS-провайдер подписывает зону и публикует записи DNSKEY и RRSIG. 2. Данные DS или данные ключа передаются регистратору. 3. Регистратор отправляет их в регистратуру по EPP с расширением secDNS (RFC 5910, май 2010 года) либо как данные DS, либо как данные ключа, по которым регистратура формирует запись DS. 4. Регистратура публикует запись DS в зоне TLD. Если регистратор одновременно является DNS-провайдером, шаги с 1 по 3 часто сводятся к одной настройке. Для gTLD Соглашение об аккредитации регистраторов 2013 года обязывает регистраторов передавать запросы на добавление, удаление или изменение ключевых данных регистратурам, поддерживающим DNSSEC, с использованием RFC 5910. Базовое Соглашение об администрировании реестра (утверждено 21 января 2024 года, действует по состоянию на октябрь 2026 года) обязывает регистратуры gTLD подписывать свои зоны и принимать ключевые данные от дочерних доменов. Правила ccTLD различаются: их стоит уточнить у регистратора или регистратуры. Есть и автоматический путь: DNS-провайдер публикует записи CDS и CDNSKEY, в которых указано, какой должна быть запись DS, а некоторые регистратуры и регистраторы их отслеживают. RFC 8078 (март 2017 года) добавил сигнал для отключения DNSSEC; RFC 9615 (июль 2024 года) позволяет родительской зоне криптографически проверить эти записи, прежде чем включить DNSSEC. ## Что может пойти не так: истекшие подписи, смена ключей и смена DNS-провайдера - **Истекшие подписи.** Если записи RRSIG не обновить вовремя, ответы становятся поддельными (bogus). - **Запись DS без соответствующего ключа.** RFC 6781 называет это «security lameness»: домен перестает работать для всех проверяющих резолверов, а исправление распространяется не сразу. Поэтому при смене KSK новая запись DS должна появиться в родительской зоне до удаления старого ключа. - **Смена DNS-провайдера.** Ключами распоряжается прежний оператор. Лучший способ – согласованная смена ключей. Если прежний оператор не сотрудничает, запись DS удаляют, меняют DNS-серверы, а когда это изменение распространится, добавляют новую запись DS. В промежутке домен остается неподписанным, и RFC 8078 предпочитает такой вариант сбоям проверки. Помогают короткие TTL. Сбои проявляются как SERVFAIL для пользователей проверяющих резолверов, тогда как у всех остальных домен может продолжать работать. На уровне корня, по состоянию на 9 октября 2026 года, ICANN планирует заменить корневой KSK 11 октября 2026 года: KSK-2024 (тег ключа 38696) сменяет KSK-2017 (тег ключа 20326), который должен быть отозван 11 января 2027 года и удален 22 марта 2027 года. Это касается операторов проверяющих резолверов, которым нужен новый якорь доверия, а не регистрантов. ## DNSSEC и зашифрованный DNS: в чем разница DNSSEC подписывает данные, чтобы любой резолвер мог их проверить, но все остается читаемым. DNS over TLS (DoT) и DNS over HTTPS (DoH) шифруют соединение между устройством пользователя и резолвером, что защищает конфиденциальность, но не доказывают, что данные исходят от владельца зоны. Эти технологии дополняют друг друга. ## Источники - [RFC 4033: DNS Security Introduction and Requirements](https://www.rfc-editor.org/rfc/rfc4033.txt) - [RFC 6781: DNSSEC Operational Practices, Version 2](https://www.rfc-editor.org/rfc/rfc6781.txt) - [RFC 5910: Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)](https://www.rfc-editor.org/rfc/rfc5910.txt) - [DNSSEC Trust Anchors and Rollovers](https://www.iana.org/dnssec/files) - [ICANN Announces Next Major Internet Security Update](https://www.icann.org/resources/press-material/release-2026-05-20-en) ## связанные термины - [запись DS](https://tldlog.com/ru/glossariy/zapis-ds/) - [запись DNSKEY](https://tldlog.com/ru/glossariy/zapis-dnskey/) - [резолвер](https://tldlog.com/ru/glossariy/rezolver/) - [DNS](https://tldlog.com/ru/glossariy/dns/)