Agent-native DNS: как хотят маршрутизировать запросы ИИ-агентов

Осенью 2024 — 2025 годов в отраслевых блогах и на конференциях по инфраструктуре зазвучал термин agent-native DNS — попытка ответить на вопрос, который раньше не стоял: как ИИ-агент находит нужный сервис, если он действует без человека за клавиатурой. Классический DNS переводит имя вроде example.com в IP-адрес и был спроектирован под браузеры и людей, которые заранее знают, куда идут. Автономный агент часто не знает — ему нужен не конкретный хост, а сервис, который умеет решать задачу: обработать платёж, забронировать столик, вернуть структурированные данные. Единого стандарта пока нет, речь идёт о наборе обсуждаемых идей, а не о готовом продукте.

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

Почему обычного DNS не хватает

DNS отвечает на вопрос «где находится это имя». Агенту чаще нужен ответ на вопрос «кто умеет это делать и как с ним говорить». Разница принципиальная.

• Обнаружение по возможностям, а не по имени. Человек вводит адрес магазина. Агент ищет любой сервис, принимающий заказ на доставку в конкретный город, и хочет выбрать по цене и надёжности.
• Машиночитаемое описание. Агенту нужен не HTML-лендинг, а описание интерфейса: какие методы есть, в каком формате запрос, какая авторизация.
• Доверие и подлинность. Если агент сам решает, куда отправить платёжные данные, цена ошибки в маршрутизации выше, чем у случайного клика человека.
• Стоимость и лимиты. Машинный трафик масштабируется мгновенно, и сервисы хотят заранее объявлять цену вызова и ограничения по частоте.

DNS отвечает на вопрос «где это». Агенту нужен ответ на вопрос «кто это умеет и на каких условиях» — а между этими двумя вопросами лежит вся сложность новой инфраструктуры.

Какие идеи обсуждаются

Предложения группируются вокруг трёх подходов, которые не исключают друг друга.

1. Надстройка над существующим DNS

Самый консервативный путь — не менять протокол, а класть машиночитаемые метаданные в существующие записи. DNS давно умеет хранить произвольный текст в TXT-записях и структурированные данные о сервисах в SRV-записях. Идея в том, чтобы по стандартному пути (по аналогии с тем, как поисковые роботы читают robots.txt) агент забирал описание доступных API, условий и точек входа. Плюс — работает на текущей инфраструктуре. Минус — TXT-записи не задумывались как каталог возможностей, и в них тесно.

2. Реестры и каталоги агентских сервисов

Второй подход — отдельный слой поверх сети: реестр, где сервисы публикуют описание своих возможностей, а агенты делают запросы вида «найди сервисы категории X с поддержкой метода Y». По духу это ближе к маркетплейсу API, чем к DNS. Сюда же примыкают инициативы вокруг протоколов взаимодействия агентов и инструментов — например, публичный протокол Model Context Protocol^*, который описывает, как модель обращается к внешним источникам и инструментам. Реестр отвечает на вопрос «что существует», протокол — «как с этим говорить».

3. Новый слой адресации для машинного трафика

Самая амбициозная и самая гипотетическая ветка — отдельное пространство имён и маршрутизации, спроектированное под агентов с нуля: встроенная верификация подлинности сервиса, объявление цены вызова, приоритизация машинного трафика. Здесь пока больше манифестов, чем работающего кода, и именно к этой ветке стоит относиться скептичнее всего.

Сравнение подходов

Обратите внимание: ни одна строка таблицы не описывает утверждённый стандарт. Это срез обсуждения, а не список продуктов, которые можно купить.

Кому это пригодится, а кому нет

Пригодится:

• Командам, строящим автономных агентов^**, которые должны сами находить и вызывать сторонние сервисы, а не работать с жёстко прописанным списком URL.
• Поставщикам API и SaaS, которые хотят, чтобы их сервис агенты обнаруживали и вызывали, — заранее публиковать машиночитаемое описание уже имеет смысл.
• Инфраструктурным инженерам, которым нужно контролировать и тарифицировать машинный трафик отдельно от человеческого.

Пока не нужно:

• Тем, у кого агент работает с двумя-тремя известными API — прописать их напрямую проще и надёжнее любого динамического обнаружения.
• Продуктам, где человек остаётся в цикле принятия решений: браузер и обычный DNS закрывают их задачи.
• Всем, кто ищет готовый стандарт для внедрения в продакшн: его сейчас нет, и опираться на конкретную схему рискованно — она может не дожить до утверждения.

Что можно делать уже сейчас

1. Публиковать машиночитаемое описание своих API (OpenAPI-спецификацию, описание инструментов) по предсказуемому пути — это полезно независимо от исхода дискуссии.
2. Следить за развитием протоколов взаимодействия агентов и инструментов, а не за манифестами про «новый интернет для ИИ».
3. Отделять машинный трафик от человеческого на уровне логов и лимитов, чтобы позже управлять им предметно.
4. Не привязывать архитектуру к одной экспериментальной схеме адресации: слой обнаружения стоит держать заменяемым.

^* Model Context Protocol (MCP) — открытый протокол, описывающий стандартный способ подключения языковых моделей к внешним данным и инструментам. Он отвечает за то, как агент вызывает инструмент, а не за то, как его находит.

^** Агент — программа на основе языковой модели, которая не просто отвечает текстом, а планирует шаги и сама вызывает внешние инструменты и сервисы для выполнения задачи.