---
id: "dns-record"
kind: "glossary-term"
title: "запись DNS"
language: "ru"
category: "DNS и технические основы"
updated: "2026-10-10T23:12:43Z"
canonical: "https://tldlog.com/ru/glossariy/zapis-dns/"
translations:
  en: "https://tldlog.com/glossary/dns-record/"
  es: "https://tldlog.com/es/glosario/registro-dns/"
  de: "https://tldlog.com/de/glossar/dns-record/"
  fr: "https://tldlog.com/fr/glossaire/enregistrement-dns/"
  it: "https://tldlog.com/it/glossario/record-dns/"
  pt-BR: "https://tldlog.com/pt/glossario/registro-dns/"
  zh-Hans: "https://tldlog.com/zh/cihui/dns-jilu/"
---

# запись DNS

Отдельная запись в зоне DNS. У нее есть имя, тип, например A, MX или TXT, TTL и сами данные, например IP-адрес. Все записи с одинаковым именем и типом образуют набор, который всегда передается в ответе и подписывается целиком.

Запись DNS – это один элемент DNS-зоны домена. Каждая запись отвечает на один вопрос об имени, например какой сервер обслуживает сайт или куда доставлять почту. Владельцы доменов обычно редактируют несколько записей у своего DNS-провайдера, и одна неверная запись может нарушить работу сайта или почты.

## Что такое запись DNS: имя, тип, TTL и данные

У каждой записи одни и те же части: имя, к которому она относится (например, `www.example.com`), тип (A, MX, TXT и так далее), TTL и сами данные, например IP-адрес.

TTL – это число секунд, в течение которых резолвер может хранить ответ, прежде чем запросить его снова. Это максимум, а не гарантия. После изменения часть пользователей продолжает видеть старое значение, пока не истечет старый TTL; именно это неформально называют распространением DNS.

Записи с одинаковыми именем и типом образуют набор ресурсных записей (RRset). Запрос всегда возвращает весь набор, у всех его записей должен быть одинаковый TTL, а DNSSEC подписывает набор целиком.

## Записи, которые нужны большинству владельцев: A, AAAA, CNAME, MX и TXT

- **A** направляет имя на адрес в протоколе IP версии 4 (IPv4). Несколько адресов означают несколько записей A.
- **AAAA** делает то же самое для более новой и длинной версии 6 (IPv6).
- **CNAME** делает имя псевдонимом ровно одного другого имени, и поиск начинается заново уже с него. Рядом с псевдонимом не может быть других данных, кроме записей DNSSEC.
- **MX** указывает почтовые серверы домена, каждый с числом приоритета; сначала пробуют серверы с меньшим числом. Целью должно быть настоящее имя хоста, а не псевдоним. Если записей MX нет совсем, отправляющие серверы используют записи A или AAAA домена. Домен, который не принимает почту, может опубликовать «нулевую MX» (null MX): приоритет 0 и одна точка в качестве цели.
- **TXT** содержит текст, смысл которого зависит от того, где он опубликован. Сервисы часто просят разместить значение TXT, чтобы подтвердить контроль над доменом. SPF должна публиковаться как TXT, причем только одна запись SPF на имя. Политика DMARC – это запись TXT по адресу `_dmarc.example.com`.

## Записи, которые обеспечивают работу зоны: NS и SOA

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

В каждой зоне ровно одна запись SOA (start of authority, начало полномочий), в ее вершине. Она содержит основной сервер, почтовый ящик ответственного лица, серийный номер и таймеры в секундах. Вторичные серверы загружают новые данные только при увеличении серийного номера. Ее поле MINIMUM вместе с собственным TTL записи SOA сейчас определяет, сколько кэшируются ответы «не существует». Обычно запись SOA для клиентов ведут DNS-провайдеры.

## Специальные записи: SRV, PTR, CAA, HTTPS и подстановочные записи

- **SRV** указывает сервер и порт для службы под именем вида `_service._protocol.example.com`. Клиенты сначала пробуют наименьший приоритет и распределяют нагрузку по весу. Целью не может быть псевдоним.
- **PTR** сопоставляет адресу имя. Обратные записи находятся в зонах in-addr.arpa (IPv4) и ip6.arpa (IPv6), которые повторяют структуру IP-адресов, а не доменных имен, поэтому их не задают в собственной зоне домена. Эксплуатационные рекомендации советуют, чтобы записи PTR и A совпадали.
- **CAA** (Certification Authority Authorization, авторизация удостоверяющих центров) перечисляет удостоверяющие центры, которые могут выпускать сертификаты для имени. Центры, соблюдающие стандарт, обязаны проверять ее перед выпуском, при необходимости поднимаясь к родительским именам, поэтому CAA, заданная для example.com, распространяется и на `www.example.com`, если у www собственной нет. Браузеры не должны использовать ее для проверки сертификатов.
- **SVCB и HTTPS** сообщают клиентам до подключения, какие серверы, протоколы и порты использовать. HTTPS – это вариант для веба; название обозначает тип записи, а не протокол.
- **Подстановочные записи** (wildcards) начинаются с метки `*`, например `*.example.com`. Они отвечают только для имен, которых вообще не существует, только теми типами, которые в них есть, и не для имен ниже себя. По состоянию на октябрь 2026 года базовое Соглашение об администрировании реестра ICANN, утвержденное 21 января 2024 года, запрещает регистратурам gTLD использовать подстановочные записи или любой другой способ отвечать за незарегистрированные имена: на такие запросы должен возвращаться NXDOMAIN.

## Почему CNAME нельзя разместить на корне домена и как это обходят с помощью ALIAS

Корень домена (вершина зоны) должен содержать записи SOA и NS, а CNAME не может иметь общее имя с другими данными. CNAME в этом месте вступает с ними в конфликт: некоторые серверы тогда игнорируют записи NS, и домен перестает работать.

Стандартное решение – записи A и AAAA на корне домена. Запись HTTPS в режиме «AliasMode» тоже может направить корень домена на другое имя, но клиенты, которые ее не поддерживают, ее игнорируют, поэтому записи A и AAAA должны оставаться.

Многие DNS-провайдеры предлагают собственную функцию, которая называется ALIAS, ANAME или CNAME flattening: провайдер сам ищет целевое имя и отвечает его адресами. По состоянию на октябрь 2026 года эти функции являются собственными разработками провайдеров. Проект стандарта ANAME утратил силу, а в реестре типов записей IANA нет типов ALIAS и ANAME. Поведение различается, поэтому сменить провайдера или использовать нескольких сложнее.

## Частые ошибки при редактировании записей и как их проверить

- Пропущенная завершающая точка в полном имени в файле зоны, из-за чего к нему добавляется имя зоны: `mail.example.com.example.com`.
- CNAME рядом с другими записями или на корне домена.
- Запись MX, NS или SRV, указывающая на CNAME.
- Две записи SPF на одном имени.
- Серийный номер SOA не увеличен при ручном редактировании файла зоны.
- CNAME, которые по-прежнему указывают на удаленный хост, или CNAME, указывающие на другие CNAME.
- TTL снижен только после изменения: кэши могут хранить старый ответ в течение старого TTL.

После каждого изменения стоит запросить запись с помощью инструмента поиска, например `dig`. Прямой запрос к авторитативному серверу показывает новое значение независимо от кэшей. Если неясно, какие записи нужны сервису, лучше уточнить у DNS-провайдера.

## Источники

- [Domain names - implementation and specification (RFC 1035)](https://www.rfc-editor.org/rfc/rfc1035.txt)
- [Clarifications to the DNS Specification (RFC 2181)](https://www.rfc-editor.org/rfc/rfc2181.txt)
- [Common DNS Operational and Configuration Errors (RFC 1912)](https://www.rfc-editor.org/rfc/rfc1912.txt)
- [Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) (RFC 9460)](https://www.rfc-editor.org/rfc/rfc9460.txt)
- [Address-specific DNS aliases (ANAME), draft-ietf-dnsop-aname-04](https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/)

## связанные термины

- [файл зоны](https://tldlog.com/ru/glossariy/fayl-zony/)
- [TTL](https://tldlog.com/ru/glossariy/ttl/)
- [A-запись](https://tldlog.com/ru/glossariy/a-zapis/)
- [запись SOA](https://tldlog.com/ru/glossariy/zapis-soa/)
- [RRSIG](https://tldlog.com/ru/glossariy/rrsig/)
