Servfail что это
Для проверки работы резолвера или DNS-сервера удобно использовать утилиту drill.
drill позволяет увидеть подробную картину разрешения имени. Для того чтобы убедиться, что сервер или резолвер работает корректно, можно использовать следующие команды, предварительно добавив в конфигурационный файл ключ домена в качестве доверенного:
drill -D @xx.xx.xx.xx www.m-system.net
xx.xx.xx.xx — ip адрес Вашего резолвера, поддерживающего ГОСТ После выполнения этой команды в ответе должен присутсвовать флаг ad — данные подтверждены.
Если флаг ad отсутсвтует, но Вы запрашиваете адрес имени из домена, ключ которого Вы добавили в доверенные — что-то не так.
Ответ SERVFAIL значит, что подпись не соответствует доверенному ключу либо отсутствует.
drill -D -o cd @xx.xx.xx.xx www.m-system.net
xx.xx.xx.xx — ip адрес вашего резолвера, поддерживающего ГОСТ. Данная команда выдаст данные даже если данные признаны не авторитетными. Таким образом можно, например, проверить данные, если ответ от сервера SERVFAIL.
Почему DNS по-прежнему сложно изучать?
Я много пишу о технологиях, которые показались мне сложными. Недавно моя подруга Сумана задала мне интересный вопрос – почему все эти вещи так сложно изучать? Почему они кажутся такими загадочными?
Для примера возьмём DNS. Мы пользуемся DNS с 80-х (больше 35 лет!). Он применяется на каждом веб-сайте Интернета. И он довольно стабилен – во многих смыслах он работает точно так же, как делал это тридцать лет назад.
Но мне понадобились ГОДЫ, чтобы понять, как с уверенностью отлаживать проблемы с DNS, и я видела множество программистов, тоже испытывавших трудности с отладкой DNS. Что же происходит?
Я приведу пару своих рассуждений о том, почему устранять проблемы DNS трудно.
(В этом посте я не буду глубоко объяснять DNS, подробности о его работе см. в моей статье Implement DNS in a Weekend или в других моих постах о DNS.)
Большая часть системы спрятана
Когда вы делаете DNS-запрос на своём компьютере, в целом это выглядит так:
- Ваш компьютер делает запрос к серверу, называемому ресолвером
- Ресолвер проверяет свой кэш и делает запросы к каким-то другим серверам, называемым полномочными серверами доменных имён
А вот, чего вы не видите:
- Кэш ресолвера. Что в нём находится?
- Какой код библиотеки на вашем компьютере делает 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 Я запросила несуществующий домен и получила расширенную ошибку 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 А вот как для homestarrunner.com :
$ dig +norecurse @8.8.8.8 homestarrunner.com ;; Got answer: ;; ->>HEADER Здесь мы видим обычный ответ NOERROR для google.com (который находится в кэше 8.8.8.8 ), но SERVFAIL для homestarrunner.com (которого в кэше нет). Это не значит, что DNS-записи homestarrunner.com нет (она есть!), просто она не кэширована.
Но если вы не привыкли, то чтение такого результата сбивает с толку! Вот некоторые из его аспектов, которые кажутся мне странными:
- Странные заголовки (есть ->>HEADER
- Странная расстановка пробелов (почему между OPT PSEUDOSECTION и QUESTION SECTION нет символа новой строки?)
- MSG SIZE rcvd: 47 странен (есть ли другие поля в MSG SIZE , за исключением rcvd ? Какие?)
- В ответе говорится, что в разделе 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 (или другую вашу любимую загадочную технологию) так сложно изучать.
SERVFAIL на DNS запись
Мой домен — celest.in, в качестве NS серверов используется afraid.org. На afraid.org я создал NS запись seed.celest.in указывающую на celest.in (а это А запись).
Делаю dig, ничего не получаю, в статусе SERVFAIL.
Поменял seed.celest.in на seed1.celest.in, потыкал dig'ом, получил статус NXDOMAIN, в authority section сразу SOA появилась.
Что я делаю не так?
У кого есть dig, nslookup, проверяйте. Потому что у меня сработало только после того как я поменял поддомен.
a1batross ★★★★★
22.02.14 12:42:57 MSK
А саму зону seed.celest.in вы создали? Может я чего-то путаю, но рекурсивный DNS-сервер хочет получить ответ «кто такой NS seed.celest.in» от сервера, ответственного за зону seed.celest.in, а не от сервера, ответственного за зону celest.in.
А проверять, что запись есть можно спрашивая прямо у ns1.afraid.org. или ″dig +trace″.
mky ★★★★★
( 22.02.14 13:33:39 MSK )
Вы все как будто специально логи не читаете и не постите. Люди, что с вами?
ICANN опубликовала подробное руководство о том, чего следует ожидать во время обновления KSK в корневой зоне
Корпорация ICANN готовится к первой в истории смене криптографических ключей, которые служат защитой для системы доменных имен интернета (DNS), в связи с чем ею было опубликовано руководство с описанием того, чего следует ожидать в этом процессе.
Ссылка на текст новости от ICANN.
Смена ключей, процесс, известный под названием «обновление ключа для подписания ключей (KSK)», назначена на 11 октября 2018 года.
Это новое руководство ICANN предназначено для аудитории с любым уровнем технических знаний. Предоставленная в нем информация о том, чего следует ожидать, призвана помочь всем подготовиться к обновлению ключа.
Руководство публикуется в рамках текущей работы корпорации ICANN над повышением осведомленности об обновлении ключа, в нем также предоставлено подробное описание всего процесса.
Полный текст руководства доступен здесь.
Наибольшую пользу руководство представляет для операторов валидирующих резолверов, которые желают получить четкие инструкции о том, чего следует ожидать после обновления ключа, а также для журналистов без технической специализации, блогеров и других, планирующих писать об обновлении ключа до, во время и после самого события.
Кроме того, документ может оказаться полезным исследователям, которые будут наблюдать за DNS на предмет отказа резолверов после завершения процедуры обновления ключа.
Хотя корпорация ICANN предполагает, что последствия смены KSK в корневой зоне для пользователей будут минимальные, ожидается, что небольшой процент интернет-пользователей испытает сложности при разрешении доменных имен, что на не техническом языке значит, что у них возникнут проблемы с достижением онлайн-пункта назначения.
На текущий момент небольшой ряд рекурсивных резолверов, валидирующих расширения безопасности системы доменных имен (DNSSEC), имеет неправильную конфигурацию, от чего могут пострадать некоторые пользователи, зависящие от этих резолверов.
В настоящем документе описано, которые пользователи могут иметь сложности и типы этих сложностей на разных этапах.
На ком обновление не отразится:
- На пользователях, которые зависят от резолвера с последним KSK
- На пользователях, которые зависят от резолвера, в котором не включена DNSSEC-валидация
ПРИМЕЧАНИЕ: Нет возможности предсказать, когда операторы резолверов, на которых отразится обновление заметят, что у них прекратилась валидация.
Результаты анализа позволяют заключить, что более 99% пользователей, чьи резолверы выполняют валидацию, от обновления KSK не пострадают.
Пользователи, использующие хотя бы один резолвер, готовый к обновлению, не заметят никаких изменений в использовании DNS и интернета в принципе после обновления (то же можно сказать и о пользователях, в чьих резолверах не включена DNSSEC-валидация. На текущий момент предполагается, что приблизительно две трети пользователей применяют резолверы, в которых не включена DNSSEC-валидация).
И, наконец, хотя сейчас обновление ключа запланировано на 11 октября 2018 года, эта дата еще подлежит ратификации Правлением ICANN.
Информация обо всем, что связано с обновлением ключа доступна здесь.
- Информационная безопасность
- Администрирование доменных имен
- Сетевые технологии
- DNS