Почему DNS по-прежнему сложно изучать?

Я много пишу о технологиях, которые показались мне сложными. Недавно моя подруга Сумана задала мне интересный вопрос – почему все эти вещи так сложно изучать? Почему они кажутся такими загадочными?

Для примера возьмём DNS. Мы пользуемся DNS с 80-х (больше 35 лет!). Он применяется на каждом веб-сайте Интернета. И он довольно стабилен – во многих смыслах он работает точно так же, как делал это тридцать лет назад.

Но мне понадобились ГОДЫ, чтобы понять, как с уверенностью отлаживать проблемы с DNS, и я видела множество программистов, тоже испытывавших трудности с отладкой DNS. Что же происходит?

Я приведу пару своих рассуждений о том, почему устранять проблемы DNS трудно.

(В этом посте я не буду глубоко объяснять DNS, подробности о его работе см. в моей статье Implement DNS in a Weekend или в других моих постах о DNS.)

Большая часть системы спрятана

Когда вы делаете DNS-запрос на своём компьютере, в целом это выглядит так:

1. Ваш компьютер делает запрос к серверу, называемому ресолвером

2. Ресолвер проверяет свой кэш и делает запросы к каким-то другим серверам, называемым полномочными серверами доменных имён

А вот, чего вы не видите:

• Кэш ресолвера. Что в нём находится?

• Какой код библиотеки на вашем компьютере делает DNS-запрос (это  getaddrinfo из libc? Если так, то это getaddrinfo из glibc, или musl, или apple? Это код DNS вашего браузера? Это другая специальная реализация DNS?). Все эти варианты ведут себя немного по-своему и имеют разную конфигурацию, методики кэширования, функции и так далее. Например, до начала 2023 DNS musl не поддерживал TCP. 

• Общение между ресолвером и полномочными серверами доменных имён. Думаю, многие проблемы с DNS было бы НАМНОГО проще понять, если бы мы волшебным образом получили трассировку того, какие полномочные серверы были опрошены вниз по потому во время вашего запроса, и информацию о том. что они сказали. (Например, что, если бы вы выполнили dig +debug google.com и получили бы кучу дополнительной отладочной информации?)

Как справляться со скрытыми системами

Пара идей о том, как работать со скрытыми системами

• Просто объяснив людям, что такое скрытые системы, вы существенно упростите задачу. Долгое время я не представляла, что на моём компьютере есть множество разных библиотек DNS, которые использовались в разных ситуациях, и меня буквально годами сбивало это с толку. Это важная часть моего подхода к обучению.

• В Mess With DNS мы попробовали методику "аквариума", демонстрирующую некоторые части системы (общение с ресолвером и полномочным сервером доменных имён), которые в обычном случае скрыты

• Мне кажется, было бы невероятно круто расширить DNS, включив в него раздел отладочной информации. (Дополнение: похоже, он уже существует! Это называется Extended DNS Errors (EDE), а в инструменты постепенно добавляется его поддержка).

Мне нравится Extended DNS Errors

Extended DNS Errors - это новый способ, которым DNS-серверы могут передавать дополнительную отладочную информацию в DNS-ответах. Вот пример того, как это выглядит:

$ dig @8.8.8.8 xjwudh.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39830
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 12 (NSEC Missing): (Invalid denial of existence of xjwudh.com/a)
;; QUESTION SECTION:
;xjwudh.com.			IN	A
;; AUTHORITY SECTION:
com.			900	IN	SOA	a.gtld-servers.net. nstld.verisign-grs.com. 1690634120 1800 900 604800 86400
;; Query time: 92 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Sat Jul 29 08:35:45 EDT 2023
;; MSG SIZE  rcvd: 161

Я запросила несуществующий домен и получила расширенную ошибку EDE: 12 (NSEC Missing): (Invalid denial of existence of xjwudh.com/a). Не совсем понимаю, что это значит (это как-то связано с DNSSEC), но здорово, что существуют такие дополнительные отладочные сообщения.

Чтобы это заработало, мне пришлось установить более новую версию dig.

Запутанные инструменты

Хотя многое из связанного с DNS спрятано, существуют разные способы разобраться в происходящем при помощи dig.

Например, можно использовать dig +norecurse, чтобы узнать, есть ли у конкретного DNS-ресолвера конкретная запись в кэше. Похоже, если ответ не кэширован, то 8.8.8.8 возвращает ответ SERVFAIL.

Вот как это выглядит для google.com

$ dig +norecurse  @8.8.8.8 google.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11653
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.			IN	A
;; ANSWER SECTION:
google.com.		21	IN	A	172.217.4.206
;; Query time: 57 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Jul 28 10:50:45 EDT 2023
;; MSG SIZE  rcvd: 55

А вот как для homestarrunner.com:

$ dig +norecurse  @8.8.8.8 homestarrunner.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55777
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;homestarrunner.com.		IN	A
;; Query time: 52 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Jul 28 10:51:01 EDT 2023
;; MSG SIZE  rcvd: 47

Здесь мы видим обычный ответ NOERROR для google.com (который находится в кэше 8.8.8.8), но SERVFAIL для homestarrunner.com (которого в кэше нет). Это не значит, что DNS-записи homestarrunner.com нет (она есть!), просто она не кэширована.

Но если вы не привыкли, то чтение такого результата сбивает с толку! Вот некоторые из его аспектов, которые кажутся мне странными:

1. Странные заголовки (есть->>HEADER<<-, flags:, OPT PSEUDOSECTION:, QUESTION SECTION:, ANSWER SECTION:)

2. Странная расстановка пробелов (почему между OPT PSEUDOSECTION и QUESTION SECTION нет символа новой строки?)

3. MSG SIZE rcvd: 47 странен (есть ли другие поля в MSG SIZE , за исключением rcvd? Какие?)

4. В ответе говорится, что в разделе ADDITIONAL есть одна запись, но нам её не показывают; мы каким-то волшебным образом должны знать, что запись "OPT PSEUDOSECTION" на самом деле находится в дополнительном разделе.

В целом результаты работы dig создают впечатление специфического скрипта, который разрастался органически, а не проектировался намеренно.

Как справляться с запутанными инструментами

Вот несколько мыслей по улучшению запутанных инструментов:

• Объясняйте вывод. Например, я написала статью о пользовании dig, где объяснила, как работает вывод dig и как настроить его, чтобы по умолчанию вывод был более кратким

• Создавайте новые, более удобные инструменты. Например, для DNS есть dog, doggo и мой инструмент поиска dns. Я считаю их очень крутыми, но сама ими не пользуюсь, потому что иногда мне нужно сделать что-то чуть более сложное (наподобие использования +norecurse), а, насколько я знаю, ни dog, ни doggo не поддерживают +norecurse. Я лучше буду использовать для всего один инструмент, поэтому остаюсь с dig. Заменить широту функций dig будет очень сложно.

• Сделайте вывод dig чуть более понятным. Если бы я лучше понимала программирование на C, то написала бы пул-реквест dig, добавляющий флаг +human , форматирующий вывод в длинном виде более структурированным и читаемым образом, например, как-то так:

$ dig +human +norecurse  @8.8.8.8 google.com
HEADER:
opcode: QUERY
status: NOERROR
id: 11653
flags: qr ra
records: QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
QUESTION SECTION:
google.com.			IN	A
ANSWER SECTION:
google.com.		21	IN	A	172.217.4.206
ADDITIONAL SECTION:
EDNS: version: 0, flags:; udp: 512
EXTRA INFO:
Time: Fri Jul 28 10:51:01 EDT 2023
Elapsed: 52 msec
Server: 8.8.8.8:53
Protocol: UDP
Response size: 47 bytes

Это делает структуру DNS-ответа более понятной – тут есть заголовок, вопрос, ответ и дополнительный раздел.

При этом объяснение не становится более глупым! Это точно та же информация, только отформатированная более структурированно. Больше всего альтернативные инструменты DNS раздражают меня тем, что ради понятности удаляют информацию. И хотя эти инструменты определённо имеют свою сферу применения, я-то хочу видеть всю информацию! Мне просто нужно, чтобы она была донесена чётко.

За последние сорок лет мы многое узнали о проектировании более удобных для пользователей инструментов командной строки, и я думаю, было бы здорово применить эти знания к старым инструментам.

dig +yaml

Краткое примечание о dig: в новых версиях dig есть формат вывода +yaml , который мне кажется более понятным, однако на мой взгляд он слишком многословен (довольно простой DNS-ответ не помещается у меня на экране).

Странные особенности

В DNS есть странные аспекты, с которыми достаточно легко столкнуться, но почти невозможно разобраться, потому что никто не говорит тебе, что происходит. Вот несколько примеров (в моей статье Some ways DNS can break есть и другие):

• негативное кэширование! (о котором я говорила в этом докладе) Мне понадобилось пять лет, чтобы осознать, что не стоит посещать домен для которого ещё нет записи DNS, потому что в таком случае будет кэшировано отсутствие такой записи, а это кэшируется на несколько часов, что очень раздражает.

• Различия в реализациях getaddrinfo: до начала 2023 года musl не поддерживал TCP DNS

• Ресолверы, игнорирующие TTL: если задать TTL для своих записей DNS (например, "5 минут"), некоторые ресолверы полностью игнорируют такие TTL и кэшируют записи на более долгий срок, возможно, на 24 часа

• Если неправильно настроить nginx (вот так), но он будет кэшировать записи DNS бесконечно.

• ndots может замедлить DNS Kubernetes

Как справляться со странными особенностями

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

Некоторые мысли:

• Невероятно полезно, когда люди чётко говорят о странностях при объяснении темы. Например, (на секунду забудем о DNS) во введении в Flexbox Джоша Комо объясняется тонкий момент о минимальном размере, с которым я сталкивалась ОЧЕНЬ много раз за долгие годы, прежде чем нашла объяснение происходившему.

• Мне бы хотелось видеть больше общественных сборников подобных распространённых странностей. Например, shellcheck – это потрясающая коллекция тонкостей и особенностей bash.

Сложность документирования странного поведения DNS заключается в том, что разные люди будут сталкиваться с разными странностями – если вы просто конфигурируете DNS для личного домена раз в три года, то вы, скорее всего, столкнётесь с иными странностями, чем тот, кто администрирует DNS для домена с большим трафиком.

Пара более распространённых причин:

Редкость использования

Многие люди имеют дело с DNS чрезвычайно редко. И, конечно, если вы имеете дело с DNS раз в три года, её будет гораздо сложнее изучить!

Я думаю, в этом могут сильно помочь шпаргалки (например, "поэтапное изменение серверов доменных имён").

Трудности с экспериментами

С DNS бывает сложно экспериментировать – вам не захочется портить свой домен. Но мы создали Mess With DNS, чтобы немного упростить эту задачу.

На сегодня всё

Мне бы хотелось услышать ваши мысли о том, из-за чего DNS (или другую вашу любимую загадочную технологию) так сложно изучать.