Кратко

  • Индивидуальный проект Changshan Su предлагает локальные DNS-SD-записи для поиска шлюзов ИИ и описания их путей и заявленных возможностей.
  • Найденную службу автор называет «кандидатной конечной точкой»: сначала клиент подтверждает доверие, потом отправляет запрос или учётные данные.

Ноутбук может найти принтер без проверки его документов. Со шлюзом ИИ вопрос дороже: кому разрешено передать ключ, который оплатит следующий запрос?

26 октября 2026 года Changshan Su подал версию 00 документа «DNS-Based Service Discovery for AI Gateways» как индивидуальный Internet-Draft. Datatracker указывает его как индивидуальное предложение: у текста нет RFC-потока и целевого статуса RFC. Имя службы _ai-gateway._tcp предложено автором; в самом документе сказано, что IANA его ещё не присвоила.

В основе — знакомые детали DNS-SD. PTR перечисляет экземпляр службы, SRV указывает целевой хост и TCP-порт, TXT хранит короткие сведения о службе, а A или AAAA даёт адрес хоста. Su предлагает компактные поля для пути шлюза, защиты транспорта, требования аутентификации и заявленных протоколов. Клиент сможет прочитать, что обещает служба, не вбивая один постоянный адрес в настройки.

Объём намеренно ограничен: типовая TXT-нагрузка должна быть меньше 200 байт, предел для всей записи — 400 байт. Влезут имя, порт, путь и несколько утверждений. Конституцию туда не поместить. Несколько дополнительных байт и не дали бы записи права принимать решение.

Главное слово в проекте — «кандидатная конечная точка». Клиент прочитал запись, но ещё не доверяет машине и не разрешил ей получать учётные данные. Предложенный порядок такой: поиск, разрешение имени, проверка, соединение, подтверждение доверия и затем запрос. Запросить каталог моделей можно по желанию. API-ключам в TXT места нет.

Порядок важен: локальная сеть позволяет устройствам объявлять о себе, но не судит, кому можно расходовать чужой секрет. В разделе безопасности сказано, что участник того же сегмента может подделать mDNS-объявление, заявить auth=0 или направить SRV на подконтрольный ему хост. Указанный в записи id не удостоверяет личность. Клиенту нужны подтверждение пользователя, заранее заданное правило доверия или проверенная идентичность TLS-сервера. Повторно используемый API-ключ нельзя отправлять по незашифрованному HTTP или WebSocket без явного одобрения такой доверенной локальной среды пользователем или администратором.

Новое объявление с plaintext также не должно понизить уровень уже доверенного шлюза HTTPS/WSS.

RFC 6763 отводит DNS-SD конкретную задачу: находить именованные экземпляры службы. RFC 6762 описывает mDNS на локальном сегменте и оговаривает, что разрешение конфликтов имён предполагает сотрудничество участников. Ни тот, ни другой документ не наделяет найденную машину правом расходовать учётные данные клиента. Звонок может сообщить: «Шлюз здесь». Решение открыть дверь остаётся у владельца ключа.

Вот зачем разделять три решения. Поиск указывает место. Идентичность TLS помогает установить, какой сервер ответил. Правило клиента определяет, можно ли передать этому серверу секрет. Если слить всё в одну зелёную лампочку «найдено», запись каталога превратится в пропуск. Проект оставляет дополнительное решение на виду — у пользователя или администратора.

Сегодня перед нами текст спецификации, а не отчёт с эксплуатации: Datatracker показывает только индивидуальный проект версии -00. В собранных источниках нет испытания совместимости, сравнения реализаций или статистики внедрения; первичный отчёт испытаний изменил бы любые выводы о распространении. Пока главное — интерфейс между тремя решениями. Если клиент просит согласие, он должен показать хост, порт, путь, состояние TLS и заявленный режим аутентификации. «Шлюз ИИ найден» — результат поиска. «Этой машине можно использовать мой ключ» — решение о полномочиях.

Источники