Кратко

  • Опция 137 DHCPv4 и опция 51 DHCPv6 содержат по одному FQDN. Это не готовый IP-адрес, не список резервных серверов и не результат отображения LoST.
  • Имя передаётся в U-NAPTR и DNS; затем выбирается адрес, устанавливается соединение и проверяется идентичность сервиса. Каждый переход создаёт собственное свидетельство.
  • Флаг discovered=true опасен, если за ним нельзя восстановить сеть, DHCP-сообщение, имя, решение DNS, проверенного партнёра и фактический ответ LoST.

Сначала сработал декодер

Рассмотрим специально построенный пример, а не реальное происшествие. В 08:14:00 устройство подключается к сети. В 08:14:01 приходит DHCPACK с опцией 137. Поле разбирается как lost.access.example, длины меток допустимы, в конце находится ровно одна корневая метка. В 08:14:02 панель объявляет обнаружение LoST успешным.

В журнале ещё нет запроса U-NAPTR, DNS-ответа, выбранного адреса, статуса валидации, соединения, результата проверки идентичности TLS, запроса LoST, карты или URI контакта. Тем более нет попытки вызова и ответа. Декодер подтвердил структуру, а панель незаметно расширила предмет утверждения.

RFC 5223 говорит точнее. Сеть доступа, которая сама развёртывает LoST или знает стороннего оператора, может сообщить клиенту доменное имя. Оно используется как вход для DNS-механизма обнаружения LoST. DHCP не выдаёт готовую карту и не получает полномочия судить о всей дальнейшей цепочке.

Нормативная скромность здесь полезна: стандарт связывает системы, не смешивая их ответственность.

Один FQDN означает именно один

OPTION_V4_LOST имеет код 137, OPTION_V6_LOST — 51. Обе опции используют DNS-кодирование меток и содержат одно полное имя с одной завершающей корневой меткой. Клиент может запросить значение средствами соответствующей версии DHCP.

Поле не содержит IP-адрес, конечный URI или упорядоченный набор целей. Оно не определяет универсальную политику повторов и кэширования. Если продукт строит собственный список отказоустойчивости, это локальное решение, которое нельзя выдавать за смысл RFC 5223.

Для аудита нужны исходные байты, код и длина опции, декодированный FQDN, результат проверки синтаксиса и контекст транзакции. Одна строка скрывает возможную неправильную кодировку. Один бит присутствия скрывает смену значения. Запись позднейшего IP в событие DHCP уничтожает промежуточный выбор DNS.

Код IANA тоже не служит подписью. Он позволяет двум реализациям одинаково понять поле, но ничего не говорит о правомерности конкретного отправителя.

Указатель принадлежит конкретному подключению

RFC 2131 определяет выбор DHCPv4-сервера, подтверждение, параметры и аренду. RFC 8415 задаёт современную основу DHCPv6. Их свидетельство относится к определённому обмену конфигурацией.

Идентификатор DHCP-сервера называет участника обмена, но не утверждает, что он же управляет указанным LoST. RFC 3046 добавляет сведения relay-агента, полезные для понимания пути доступа. Топология пути не является сертификатом конечного сервиса.

При переходе с корпоративного Wi-Fi на мобильную сеть приложение может сохранить прежний FQDN. Тогда корректная в прошлом подсказка переживает административную область, в которой возникла. Запись должна связывать имя с интерфейсом, сетью, транзакцией, сервером, relay, временем и состоянием аренды.

Нужен явный ответ на вопрос, что запускает повторное обнаружение: Renew, Rebind, смена линка, адреса или профиля сети. Иначе последний сохранённый указатель становится постоянной политикой без нового решения.

RFC прямо описывает подмену

RFC 5223 предупреждает: противник, изменивший DHCP-ответ или вставивший свой, может направить клиента на подконтрольный ему LoST-сервер или неверный адрес. RFC 5069 рассматривает соответствующие угрозы маркировке и отображению экстренных вызовов.

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

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

Принцип Heng Lu о первичности работающего кода возвращает доказательство к месту решения: компонент показывает вход, проверку и локальный результат. DHCP-клиент не может свидетельствовать за DNS-резолвер, TLS-партнёра, оператора LoST или принимающую службу.

DNS должен ещё выбрать сервис

Полученный FQDN поступает в процедуру U-NAPTR/DNS, связанную с RFC 5222. Требуется найти подходящую сервисную запись, выбрать транспорт и цель, разрешить адрес и подключиться.

Правильное имя может не иметь нужной записи. DNS может не ответить, адрес — оказаться недоступным, а идентичность партнёра — не совпасть с ожидаемой. RFC 8446 защищает TLS, RFC 9525 уточняет проверку идентичности сервиса. Шифрование соединения с неверно выбранным партнёром не исправляет выбор.

Следует хранить вопрос U-NAPTR, выбранную запись, DNS-ответ, TTL, состояние валидации, набор адресов, фактическую цель и решение об идентичности. Тогда отказ можно точно назвать: например, «FQDN получен, подходящий сервис не найден».

RFC 8917 назначает отдельный S-NAPTR-тег службе валидации LoST. Тег различает требуемую роль, но не доказывает корректность выполнения роли найденным узлом.

Сервер найден — карта ещё не получена

После соединения клиенту предстоит отправить LoST-запрос и разобрать ответ. Ответом может быть ошибка, предупреждение, перенаправление или карта со своим источником, временем, сроком и границей.

Опубликованный материал о RFC 5222 уже проводит следующую границу: карта с URI не доказывает установленный и принятый вызов. Настоящий материал не повторяет её. Его тезис раньше: DHCP-имя не доказывает будущую карту.

RFC 6739 усиливает происхождение синхронизируемых карт между серверами. Подписанный backend не аутентифицирует задним числом DHCP-ответ или DNS-представление клиента. RFC 6881 включает обнаружение в широкую практику экстренной связи, но не объединяет доказательства конфигурации, карты, сигнализации и результата.

Цепочка, по которой можно вернуться

Сохраняйте контекст подключения; DHCP-транзакцию, сервер и relay; результат защиты сообщения; сырую опцию и FQDN; аренду и решение об инвалидировании; U-NAPTR; DNS; идентичность TLS; LoST-запрос и ответ; пригодность карты; установление сессии; приём и результат.

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

Источники

  1. RFC 5223
  2. RFC 5223 в IETF Datatracker
  3. Статус RFC 5223
  4. История RFC 5223
  5. Errata RFC 5223
  6. RFC 2131
  7. RFC 2132
  8. RFC 8415
  9. RFC 3118
  10. RFC 3046
  11. RFC 5222
  12. RFC 5069
  13. RFC 6881
  14. RFC 8917
  15. RFC 6739
  16. RFC 8446
  17. RFC 9525
  18. Heng Lu — первичность работающего кода
  19. Heng Lu — минимальная начальная спецификация и добровольное принятие