Кратко

  • Срок хранения ответа, период действия подписи и время физического измерения — разные характеристики. Первые две не позволяют восстановить третью.
  • LOC хранит размер объекта отдельно от неопределённости его положения. Тысячные доли угловой секунды в кодировке совместимы с кругом горизонтальной погрешности диаметром десять километров.
  • Поиск может заменить местоположение узла приближённым местоположением сети. Если карта не показывает эту замену, она сообщает больше, чем установил источник.

Три времени у одной точки

Ответ только что получен. Подпись действительна. Координаты выглядят подробными. Из этих трёх наблюдений легко составить впечатление, что место недавно проверяли. Но ни одно не сообщает, когда кто-либо действительно определял положение объекта.

В модели DNS, описанной в RFC 1035, TTL регулирует срок использования кэшированной записи до нового обращения к источнику. Это не возраст географического измерения. Можно получить свежий ответ, который добросовестно повторяет давно внесённые данные.

RFC 4033, опубликованный в марте 2005 года, отдельно различает согласованность кэша и период действия подписи DNSSEC. Аутентификация происхождения и защита целостности позволяют проверить данные в своей области ответственности. Они не проверяют высоту здания, правильность географической системы отсчёта или присутствие оборудования на месте.

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

География, которую можно было поддерживать на месте

Экспериментальный RFC 1876 в январе 1996 года определил запись LOC для узлов, сетей и подсетей. Она должна была позволить приложениям получать географические сведения через DNS, в том числе для карт управления сетью и географического представления traceroute.

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

Предыстория включала сведения о некоторых площадках в картах UUCP. Централизованное обновление и проверка таких карт создавали трудности. DNS обещал другое распределение работы: тот, кто обслуживает имя, может поддерживать связанное с ним описание места.

Ещё в ноябре 1994 года экспериментальный RFC 1712 предложил GPOS. Он обсуждал локально поддерживаемую и широко доступную информацию, сопоставляя её с sysLocation в SNMP и тогдашними ограничениями распространения X.500. Эти замечания относятся к условиям того времени, а не к нынешней статистике использования технологий.

GPOS представлял географические компоненты тремя печатными числовыми строками. Это не три двоичных числа IEEE с плавающей запятой. Длинная дробная часть строки могла передать много цифр, но не объясняла, откуда они взялись.

Даже направление зависело от подписи поля

В тексте RFC 1712 есть перестановка названий и определений долготы и широты. Официальное исправление 541, заявленное в 2006 году, указывает на проблему и предлагает поправить обозначения, сохранив числовой порядок.

Его статус — «Held for Document Update», а не «Verified». Наличие такой записи не означает, что исходный стандарт уже официально переписан или что все реализации приняли единое толкование. Поэтому старые примеры координат здесь не воспроизводятся как готовые настройки.

Позднейший LOC не объявил GPOS отменённым: RFC 1876 не помечает RFC 1712 как устаревший документ. В реестре параметров DNS IANA остаются GPOS с номером 27 и LOC с номером 29. Реестр различает форматы, но не измеряет их популярность и не гарантирует качество опубликованных значений.

Маленький объект, большое незнание

Главное достоинство LOC для читателя — не количество цифр, а разделение сущностей. SIZE обозначает диаметр сферы, охватывающей описываемый объект. Горизонтальная точность задаёт диаметр круга возможной ошибки положения. Вертикальная — полный диапазон возможной ошибки по высоте.

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

Диаметр — не радиус. Полный диапазон — не величина, которую без преобразования следует писать после знака «плюс-минус». При соответствующем переходе нужна половина полного размера. При этом RFC не задаёт статистическую вероятность: нельзя самостоятельно приписать кругу уровень доверия, которого источник не называл.

В текстовой форме размеры и точности можно опустить. Тогда используются один метр для SIZE, десять тысяч метров для горизонтальной точности и десять метров для вертикальной. Документ связывает эти значения с доступностью приблизительных координат по почтовым индексам.

Получается вполне осмысленное сочетание: объект метрового размера и круг горизонтальной ошибки диаметром десять километров. Опущенные в тексте поля всё равно присутствуют в двоичных данных со значениями по умолчанию. Их может потерять уже программа, которая берёт только центр и рисует остриё указателя.

Формат умел различать больше, чем источник знал

RDATA нулевой версии LOC занимает шестнадцать октетов. Это только данные данного типа, не вся ресурсная запись и не всё сообщение DNS. По одному октету отведено версии, размеру и двум точностям; по четыре — широте, долготе и высоте.

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

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

Размер и точности сжаты в один октет каждый: одна десятичная цифра и показатель степени десяти, с результатом в сантиметрах. Значения полубайтов от десяти до пятнадцати не определены. Ноль, умноженный на десять в нулевой степени, означает менее сантиметра, а не абсолютное отсутствие ошибки.

Номер версии требует проверки. Если программа не знает версию, нельзя без основания приписывать последующим байтам прежний смысл. Успешно получить данные и правильно их прочитать — разные результаты.

Нулевая высота не была универсальным нулём

Для высоты LOC использует референц-эллипсоид WGS84. Отсчёт хранимого значения начинается на сто тысяч метров ниже него и ведётся в сантиметрах. Поэтому нулевая высота относительно эллипсоида кодируется числом десять миллионов.

Смещение позволяет представить положения ниже опорной поверхности без отрицательного целого в хранилище. Оно не переносит настоящий объект на сто километров вверх. Средний уровень моря также не тождествен референц-эллипсоиду.

RFC допускает приближение по уровню моря с соответствующей корректировкой высоты или вертикальной точности. Это требование не смешивать разные основания. Дополнительные десятичные знаки не исправят неправильно выбранный нуль.

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

Если ответа об узле не было

LOC мог описывать не только отдельный узел. При поиске по имени сначала следовало запросить его LOC, обычным образом следуя CNAME. Если прямой записи нет, связанные A-адреса могли позволить поискать расположение сети или подсети.

При поиске по IPv4-адресу первым шагом было получение имени через IN-ADDR.ARPA, а затем LOC для найденного имени. Это не общее требование помещать LOC непосредственно под каждым обратным именем адреса.

Необязательный сетевой поиск использовал исторический механизм RFC 1101 1989 года. Специальные обратные имена, PTR и данные формы A помогали получить имена сетей и маски подсетей. Некоторые A-подобные значения здесь означали именно маски, а не адреса доступных служб.

Имена собирались, после чего поиск LOC шёл от более конкретной подсети к более широким сетям. Это не обычный подъём по родительским меткам DNS и не маршрутизация BGP по наиболее длинному префиксу. Процедура сохраняет предпосылки IPv4 и классовых сетей своего времени; общего расширения для IPv6 документ не определяет.

Идея состояла в том, чтобы при недостатке точного места всё же показать более широкую область. Но местоположение сети не становится от этого измерением конкретного компьютера. Если у имени несколько A-адресов, приложение могло выбирать, какие приближённые места использовать или сочетать. Итог зависел и от решения потребителя.

Публикация имела ещё одну границу

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

Кроме того, DNSSEC не обеспечивает конфиденциальность. GPOS прямо говорил об общедоступности данных DNS, а LOC предупреждал о риске раскрытия точного физического места. Это исторические предупреждения, не доказательство конкретной атаки и не современная правовая рекомендация.

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