DNS-записи — A, AAAA, CNAME, MX, TXT, NS, SOA, SRV, PTR

DNS — это не просто «имя -> IP». Это более общая база данных, где разные типы записей решают разные задачи. Когда ты конфигурируешь домен у DNS-провайдера, ты редактируешь именно типы записей (record types или RR types).

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

1. Настраивать DNS для своего домена осознанно.
2. Понимать вывод dig и читать DNS-зоны.
3. Дебажить почтовые / SSL / verification-проблемы.

Анатомия DNS-записи

DNS-запись в зоне выглядит так:

NAME           TTL   CLASS  TYPE  RDATA
www.github.com. 300  IN     A     140.82.114.4

Поля:

• NAME — полное имя (FQDN), включая trailing dot. Опускается @ для самой зоны.
• TTL — Time-To-Live, сколько секунд resolvers могут кэшировать. Например 300 = 5 минут.
• CLASS — почти всегда IN (Internet). Существуют CH (Chaos, для DNS-сервер debug), HS (Hesiod) — почти не используются.
• TYPE — тип записи. A, AAAA, CNAME, MX, и т.д.
• RDATA — данные записи. Содержимое зависит от типа.

# Посмотреть запись в полном формате:
dig www.github.com A +noall +answer
# Output:
# www.github.com.   60   IN   A   140.82.121.4
# (NAME, TTL, CLASS, TYPE, RDATA)

A — IPv4-адрес

Самая базовая запись. A означает «Address» (исторически IPv4). RDATA — это IPv4-адрес (4 байта в dotted decimal).

www.github.com.  60  IN  A  140.82.121.4

Что значит: «когда кто-то спросит про www.github.com, отдай IP 140.82.121.4».

Может быть несколько A-записей с одним именем — это round-robin DNS, простая форма балансировки нагрузки:

api.example.com.  60  IN  A  1.2.3.4
api.example.com.  60  IN  A  1.2.3.5
api.example.com.  60  IN  A  1.2.3.6

Клиенты получают список адресов, и каждый клиент выбирает случайный (или первый). Распределение нагрузки между серверами.

# Посмотреть A-записи для популярных сайтов:
dig +short github.com A
# Может быть несколько IP -- это round-robin

dig +short google.com A
# Google использует разные IP, иногда сотни вариантов

AAAA — IPv6-адрес

«Quad A» — потому что IPv6-адрес в 4 раза больше IPv4 (128 бит vs 32 бита). Иначе всё то же самое:

www.github.com.  60  IN  AAAA  2606:50c0:8000::153

С ростом IPv6-внедрения AAAA-записи становятся обязательными. Современные приложения часто пробуют сначала AAAA, потом A (или параллельно — Happy Eyeballs алгоритм).

# Посмотри AAAA-запись:
dig +short google.com AAAA
# 2a00:1450:4010:c02::65 -- IPv6 для Google

# Сравни с A:
dig +short google.com A
# 142.250.74.142 -- IPv4 для Google

# Если у домена нет AAAA -- он только в IPv4

CNAME — canonical name (псевдоним)

CNAME — это «алиас»: «когда спросишь про X, на самом деле смотри Y». Например:

www.example.com.  300  IN  CNAME  example.com.
example.com.      300  IN  A      1.2.3.4

Здесь www.example.com — это псевдоним example.com. Resolver, получив CNAME, делает второй запрос — на example.com — и получает A-запись.

CNAME часто используется для:

• Делегирования на сторонний сервис. Пример: shop.mysite.com -> mysite.shopify.com. Shopify меняет свои IP-адреса как хочет, тебе не нужно следить.
• CDN-интеграции. static.mysite.com -> mysite.cdn.cloudfront.net. CDN балансирует трафик через сотни регионов.
• Алиасов на основной домен. www, app, api все указывают на одно и то же.

Ограничения CNAME (важно знать):

1. Нельзя на zone apex. Apex — это сам корень зоны (example.com). По RFC нельзя сделать example.com CNAME something.else. Только конкретные subdomain’ы. Многие DNS-провайдеры обходят это через «ALIAS» или «ANAME» records (см. ниже).

2. Не сочетается с другими записями того же имени. Нельзя одновременно mail.example.com CNAME ... и mail.example.com MX .... CNAME заменяет всё.

# Посмотри CNAME-цепочку:
dig www.github.com
# Может быть несколько CNAME, потом конечная A

# Полная цепочка резолва:
dig +trace www.github.com | tail -20

ALIAS / ANAME — workaround для apex

Поскольку CNAME нельзя на zone apex, многие DNS-провайдеры (Cloudflare, AWS Route 53, Namecheap) добавляют ALIAS или ANAME записи. Технически это не standard DNS-тип, а внутренняя магия провайдера: ALIAS-запись на example.com вычисляется провайдером на лету в A-запись текущего IP.

Пример: ты хочешь, чтобы example.com указывал на CloudFront CDN. Стандартный CNAME запрещён на apex. ALIAS позволяет: example.com ALIAS d12345.cloudfront.net. Провайдер каждый раз резолвит CloudFront и отдаёт текущий IP как A-запись.

MX — mail exchanger (почтовые серверы)

MX-записи указывают, какие серверы принимают почту для домена. Формат:

example.com.  3600  IN  MX  10  mail1.example.com.
example.com.  3600  IN  MX  20  mail2.example.com.
example.com.  3600  IN  MX  30  backup-mail.example.com.

Число перед именем — это priority (preference). Меньше = выше приоритет. Когда какой-то сервер хочет отправить почту на [email protected], он:

1. Делает DNS-запрос: MX для example.com.
2. Получает список с приоритетами.
3. Сначала пробует наименьший приоритет (mail1).
4. Если не ответил — следующий (mail2).
5. И так далее.

Это даёт резервирование почты: если основной mail-сервер упал, остальные принимают почту.

# Посмотри MX-записи:
dig +short github.com MX
# 1 aspmx.l.google.com.
# 5 alt1.aspmx.l.google.com.
# 5 alt2.aspmx.l.google.com.
# 10 alt3.aspmx.l.google.com.
# (github использует Google Workspace для почты)

dig +short gmail.com MX
# 5 gmail-smtp-in.l.google.com.
# ...

# А для домена без почты:
dig +short doesntexist.example MX
# Пусто -- почты нет

TXT — произвольный текст

TXT-записи содержат произвольный текст. Изначально для комментариев, но в современном интернете используются для верификации и антиспама.

SPF (Sender Policy Framework) — антиспам

SPF говорит, с каких IP можно отправлять почту от имени этого домена:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com -all"

Когда mail-сервер получает письмо «от» [email protected], он проверяет SPF: разрешён ли IP отправителя в SPF этого домена? Если нет — письмо вероятно фейк/спам.

DKIM (DomainKeys Identified Mail) — подписи

DKIM — публичный ключ для проверки подписи в исходящих письмах:

default._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqG..."

Mail-серверы используют этот ключ для верификации DKIM-подписи в письме.

DMARC — policy для SPF + DKIM

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

Указывает, что делать с письмами, которые не прошли SPF/DKIM: пропускать, помещать в спам, или reject.

Domain Verification

Когда ты регистрируешься в Google Workspace, Microsoft 365, или верифицируешь домен в SaaS-сервисах, тебя обычно просят добавить TXT-запись типа:

example.com.  TXT  "google-site-verification=abc123xyz..."

Сервис проверяет наличие этой записи — значит, ты владеешь доменом.

# Посмотри TXT-записи популярного домена:
dig +short github.com TXT
# Увидишь SPF, DKIM, и кучу verification-токенов

dig +short _dmarc.github.com TXT
# DMARC-policy

NS — name server (делегирование)

NS-записи указывают authoritative-серверы зоны. Уже обсуждали в прошлом уроке:

github.com.  86400  IN  NS  dns1.p08.nsone.net.
github.com.  86400  IN  NS  dns2.p08.nsone.net.
github.com.  86400  IN  NS  ns-421.awsdns-52.com.
github.com.  86400  IN  NS  ns-1707.awsdns-21.co.uk.

NS-записи на уровне родительской зоны (например, .com) делегируют управление зоной владельцу. NS-записи внутри самой зоны (на authoritative-сервере) подтверждают это — должны совпадать.

NS-записи также используются для делегирования субдомена: ты можешь делегировать subdomain.example.com другим серверам:

subdomain.example.com.  NS  ns.subdomain.com.

Полезно, например, когда команда разработки хочет автономно управлять dev.example.com.

SOA — Start of Authority (метаданные зоны)

Каждая зона имеет одну SOA-запись с метаданными:

github.com.  3600  IN  SOA  ns1.p08.nsone.net. hostmaster.nsone.net. (
  1659977573  ; serial
  43200       ; refresh
  7200        ; retry
  1209600     ; expire
  3600        ; minimum TTL
)

Поля:

• Primary NS — главный authoritative-сервер.
• Email админа (с . вместо @).
• Serial — версия зоны. Растёт с каждым изменением. Secondary серверы знают, что нужно sync’ить, когда serial новый.
• Refresh — как часто secondary опрашивает primary.
• Retry — повтор при ошибке.
• Expire — после скольки часов без sync secondary прекратит отвечать.
• Minimum TTL — TTL для negative caching (NXDOMAIN).

# Посмотри SOA домена:
dig +short github.com SOA

# В detail-формате:
dig github.com SOA +noall +answer

SRV — служебные записи

SRV-записи описывают, какой сервер обслуживает конкретный сервис. Формат:

_service._protocol.domain.  TTL  IN  SRV  priority weight port target

Пример: SIP (телефония) на example.com:

_sip._tcp.example.com.  3600  IN  SRV  10 60 5060 sip-server.example.com.

Это говорит: «для SIP по TCP на example.com сервер sip-server.example.com:5060, priority 10, weight 60».

Используется в:

• SIP, XMPP — телефония и messaging.
• LDAP, Active Directory — auto-discovery.
• Minecraft — клиенты ищут сервер через _minecraft._tcp.example.com.

Не очень распространено для веба (HTTP по дефолту просто использует имя), но для специализированных протоколов незаменимо.

PTR — reverse DNS

PTR-записи решают обратную задачу: «по IP найти имя». Используются в зонах in-addr.arpa (IPv4) и ip6.arpa (IPv6).

Например, для IP 140.82.121.4:

4.121.82.140.in-addr.arpa.  IN  PTR  lb-140-82-121-4-iad.github.com.

(октеты в reverse порядке + домен .in-addr.arpa)

PTR-записи нужны для:

1. Логирования. Сервер пишет в лог не только IP, но и имя.
2. Email-проверок. Многие mail-серверы отказывают почте от IP, у которого нет валидной PTR-записи.
3. Diagnostic tools. nslookup <IP> показывает имя.

PTR управляется не владельцем домена, а владельцем IP-блока (обычно провайдер). Поэтому если ты арендуешь VPS, попроси провайдера настроить PTR — иначе можешь иметь проблемы с email-deliverability.

# Посмотри PTR для IP:
dig -x 140.82.121.4 +short
# Или:
host 140.82.121.4

# Reverse для IPv6:
dig -x 2606:50c0:8000::153

Другие, реже встречающиеся

• CAA (Certificate Authority Authorization). Кто может выпускать SSL-сертификаты для домена. example.com CAA 0 issue "letsencrypt.org".
• DNSKEY, DS, RRSIG, NSEC, NSEC3. Для DNSSEC (cryptographic signing).
• HTTPS (RFC 9460). Современная альтернатива CNAME для apex + SVCB-параметры.
• SVCB. Generic service binding, основа HTTPS RR.
• TLSA. DANE — привязка сертификата к DNS.
• NAPTR. Naming Authority Pointer для service discovery (SIP, ENUM).

Для большинства задач (90%+) достаточно знать A, AAAA, CNAME, MX, TXT, NS, SOA.

Чтение полного dig ответа

Когда ты делаешь dig example.com, ты получаешь несколько секций:

;; ANSWER SECTION:
example.com.   3600  IN  A  1.2.3.4

;; AUTHORITY SECTION:
example.com.   3600  IN  NS  ns1.example.com.
example.com.   3600  IN  NS  ns2.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.  3600  IN  A  5.6.7.8
ns2.example.com.  3600  IN  A  9.10.11.12

• ANSWER — что ты спрашивал.
• AUTHORITY — какие NS-серверы authoritative для этой зоны.
• ADDITIONAL — дополнительные «полезные» записи (например, IP-адреса самих NS-серверов, чтобы не нужно было делать второй запрос).

dig показывает это для образовательных целей. Большинство приложений видят только ANSWER.

Попробуй сам

# 1. Посмотри полный набор записей какого-нибудь домена:
dig github.com ANY +noall +answer
# (Многие resolvers сейчас блокируют ANY из-за DDoS-amplification)

# Альтернатива -- последовательно:
for type in A AAAA MX TXT NS SOA CAA; do
  echo "=== $type ==="
  dig +short github.com $type
done

# 2. Найди verification-записи:
dig +short github.com TXT | grep -i 'verif\|spf\|dkim'

# 3. Резолв CNAME-цепочки:
dig www.github.com
# Видишь CNAME перед A?

# 4. Reverse DNS для какого-нибудь сайта:
dig +short github.com A
# Возьми один из IP:
dig -x <IP> +short
# Иногда возвращает имя 'lb-N-M-K-L-iad.github.com'

# 5. Посмотри MX и реально подключись:
dig +short google.com MX | head -1 | awk '{print $2}'
# Возьми первый mx-сервер и попробуй подключиться:
nc -v $(dig +short google.com MX | sort -n | head -1 | awk '{print $2}' | sed 's/.$//') 25
# Получишь SMTP-greeting

# 6. Проверь свой собственный домен (если есть):
dig +short YOURDOMAIN.com A AAAA MX TXT NS

# 7. Дебаг SPF:
dig +short example.com TXT | grep spf
# Если v=spf1 ... -all -- strict SPF. Если ~all -- soft fail.