JavaNotes

DNS

3 min read

DNS

DNS сопоставляет доменные имена с записями разных типов. Это распределённая иерархическая система, а не один общий сервер со всеми адресами.

Разрешение имени

Когда приложению нужен api.example.com, типичный путь такой:

  1. приложение и ОС проверяют доступные локальные cache и правила разрешения, включая hosts согласно настройкам системы;
  2. stub resolver отправляет запрос recursive resolver;
  3. recursive resolver возвращает запись из cache, если TTL ещё действует;
  4. иначе resolver узнаёт у root-сервера, куда идти за зоной верхнего уровня;
  5. TLD-сервер указывает authoritative name servers домена;
  6. authoritative server возвращает запись зоны;
  7. recursive resolver кэширует результат и отвечает клиенту.
sequenceDiagram
    participant A as Application
    participant R as Recursive resolver
    participant Root as Root
    participant TLD as TLD
    participant Auth as Authoritative
    A->>R: api.example.com A?
    R->>Root: A?
    Root-->>R: referral to TLD
    R->>TLD: A?
    TLD-->>R: referral to authoritative
    R->>Auth: A?
    Auth-->>R: A record + TTL
    R-->>A: address

Клиент обычно не выполняет всю итерацию самостоятельно — это делает recursive resolver.

Основные записи

  • A — IPv4-адрес;
  • AAAA — IPv6-адрес;
  • CNAME — alias на другое имя;
  • NS — authoritative servers зоны;
  • MX — почтовые серверы;
  • TXT — текстовые данные и проверки владения;
  • SRV — сервис, порт и приоритет;
  • PTR — обратное сопоставление адреса с именем;
  • SOA — служебные параметры зоны.

У CNAME есть ограничения на совместное использование с другими данными одного имени. Балансировка несколькими A/AAAA не проверяет здоровье приложения сама по себе.

TTL и cache

TTL говорит resolver, сколько можно хранить ответ. Малый TTL ускоряет переключение, но увеличивает число запросов. Большой TTL снижает нагрузку, но старый адрес дольше остаётся у клиентов.

Ошибки отсутствия имени тоже могут кэшироваться — negative caching. Поэтому «запись уже исправили» не всегда означает мгновенное восстановление для всех resolver.

UDP, TCP и шифрование

Обычные DNS-запросы часто идут по UDP; при большом/обрезанном ответе и некоторых операциях используется TCP. DNS over TLS и DNS over HTTPS шифруют участок между клиентом и resolver, но не меняют авторитетность данных зоны.

DNSSEC позволяет проверять подпись DNS-данных. Он подтверждает целостность и происхождение записи, но не шифрует запрос.

Диагностика

dig api.example.com A
dig +trace api.example.com
dig @resolver.example api.example.com

Проверяют отдельно:

  • какой resolver ответил;
  • authoritative ли это ответ;
  • TTL и цепочку CNAME;
  • ответы A и AAAA;
  • различие между локальным cache и внешними resolver;
  • доступность полученного IP уже на уровне TCP/TLS/HTTP.

DNS-успех не гарантирует, что сервис работает.

На собеседовании

Чем recursive resolver отличается от authoritative server? Recursive ищет ответ для клиента и кэширует его; authoritative отвечает за данные конкретной зоны.

Почему после смены IP часть клиентов идёт на старый? Старый положительный или отрицательный ответ ещё живёт в cache согласно TTL и локальной политике.

Связанные заметки: Http протокол, SSL.

Graph View

Backlinks