Кратко

  • RFC 5001, опубликованный в августе 2007 года, определил опцию DNS NSID. Резолвер посылает пустое поле EDNS, а сервер при согласии возвращает свои идентифицирующие байты вместе с ответом.
  • Опция относится к одному обмену между резолвером и отвечающим сервером. Рекурсивный резолвер называет себя; запрос к авторитативному серверу за ним требует отдельного обмена. Формат значения оставлен на усмотрение оператора.
  • В документе L-Root 2014 года описано, как узлы возвращали свои полные имена в NSID. Реестр параметров DNS IANA отводит опции номер 3 в EDNS.

Повторный запрос попал к другому свидетелю

У инженера есть два пакета с одинаковым адресом источника: один содержит ошибочный ответ, другой — правильный. Легко написать, что сервер исправился. При anycast адрес служит общим входом для нескольких узлов. Действующая маршрутизация выбирает получателя каждого запроса. Балансировщик нагрузки тоже может распределять обращения между процессами за одним адресом. В двух пакетах одинаковая строка IP, но за неё могут отвечать разные машины с разными копиями данных.

Руководство по эксплуатации anycast 2006 года объясняло, почему при неполадке полезно установить конкретный узел. Можно позднее задать специальный вопрос об имени сервера. Однако путь между первым и вторым запросом мог измениться. Полученное имя честно обозначит того, кто ответил на дополнительный вопрос; происхождение первоначального неверного ответа оно не восстановит. Расследователь получил имя нового дежурного и приписал ему прошлую смену.

RFC 5001 поместил запрос идентичности внутрь исходного обмена DNS. В документе названы anycast и балансировка нагрузки, позволяющие нескольким серверам имён делить один IP. У запроса DNS нет сохранённой сессии, которая удерживала бы повтор на той же машине. Надёжный способ узнать, кто отправил конкретный ответ, — получить идентифицирующую информацию в этом самом ответе. Тогда результат, время и объявленная личность отправителя оказываются в одном захвате трафика.

Пустое поле на выходе, метка на возврате

Резолвер включает пустую опцию NSID в псевдозапись OPT механизма EDNS. В запросе не должно быть данных NSID. IANA закрепила за опцией код 3. Сервер, который понимает запрос и решает ответить, добавляет идентифицирующие байты в свой ответ. Он обязан игнорировать данные, если клиент неправильно поместил их в запрос, и не вправе отправлять NSID резолверу, который его не просил. Запрос, ответ, байты и отметку времени можно сохранить как единый след.

Стандарт не предписывает привычное имя хоста. Значение представляет собой непрозрачную последовательность байтов. Это может быть действительное имя узла, его адрес обслуживания, постоянный случайный код, вычисленный псевдоним, меняющийся знак, подписанный либо зашифрованный блок. Спецификация согласует способ спросить и место для ответа; смысл и степень раскрытия выбирает оператор. Публичное имя делает жалобу клиента понятной. Стабильный псевдоним позволяет сравнить два узла, не открывая адреса обслуживания. Меняющаяся метка ограничивает внешнее наблюдение, но требует аккуратного внутреннего журнала соответствий.

Цена раскрытия реальна. Если сервис прячет узлы за общим адресом ради устойчивости, выдача каждого адреса обслуживания строит карту именно этих узлов. Полный отказ от меток оставляет клиенту противоречивые ответы якобы от одного IP. Раздел безопасности RFC 5001 относит NSID к сигналам канала, которые сами по себе не входят в защиту данных DNS механизмом DNSSEC. Для проверки спорной метки нужны защищённый канал или сопоставимые записи оператора.

L-Root выбрал читаемое имя

В январе 2014 года операторы L-Root опубликовали описание применявшихся способов идентификации своих узлов anycast. Их NSID содержал полное имя узла, ответившего на запрос. В примере вывода dig байты представлены в шестнадцатеричном виде и читаются как ytz01.l.root-servers.org. Необязательное непрозрачное поле стало доступной постороннему исследователю меткой по решению оператора.

В том же документе описаны отдельные вопросы HOSTNAME.BIND и ID.SERVER. Они способны назвать узел, который отвечает на новый вопрос. При смене маршрута этот узел может отличаться от отправителя плохого ответа. NSID, запрошенный прямо в проблемном обмене, связывает ответ и объявленную идентичность в одном сетевом событии. Оператор получает точный след вместо просьбы ещё раз посмотреть на общий адрес.

Документ фиксирует опубликованную практику L-Root в 2014 году. Он не является сегодняшней переписью всех корневых серверов. Для конкретного инцидента сохраняют исходный запрос, ответ, сырые байты NSID, источник, транспорт и время. Соответствие метки машине или процессу устанавливается по инвентарю и журналам эксплуатирующей стороны.

Рекурсивный сервер представляется за себя

NSID действует только на одном участке. Если клиент просит рекурсивный резолвер назвать себя, ответ относится к этому резолверу. Тот может отдельно послать запрос NSID авторитативному серверу. Это другая транзакция с другим отправителем и адресатом. Метка в ответе клиенту не превращается в имя удалённого авторитативного узла. Сервер также не может вложить NSID в ответ клиенту, который опцию не запросил.

Чтобы узнать, какой авторитативный сервер работал за рекурсивным ответом, нужен журнал или захват запроса вверх по цепочке. Один нижний пакет не перечисляет все пройденные узлы. Эта граница защищает расследование от ложного переноса ответственности. Даже в пределах участка метка показывает, как ответивший назвал себя; причина расхождения данных устанавливается по настройкам и журналам конкретного узла.

Общий адрес перестал быть оправданием

RFC 5001 сохранил обычный адрес сервиса и добавил необязательное место для метки рядом с ответом. IANA хранит номер опции, оператор определяет её содержание, резолвер запрашивает и сохраняет результат. Для такой узкой задачи — выяснить автора именно этого ответа — изменение протокола оказалось достаточно небольшим.

Сервер может отказаться раскрывать метку. Дополнительные байты иногда увеличивают пакет до усечения ответа, поэтому включение NSID всегда остаётся добровольным. Отсутствие поля в конкретном захвате означает только то, что оно не было возвращено в том обмене. Узел придётся установить по другим следам. Общий IP от этого не становится паспортом одной машины.

Распределённому DNS нужен единый адрес для доступности, а расследованию нужен отправитель отдельного сообщения. L-Root использовал публичное имя; другой оператор может использовать внутренний код. Оба варианта помогают, когда код прикреплён к спорному ответу. Следующий запрос может встретить другую машину и услышать совершенно другую историю.