dns-aid

Name: dns-aid
Author: infobloxopen

ローカル

github.com/infobloxopenAI・エージェント74今日更新

リポジトリ

dns-aid について

DNS-AID は IETF ドラフト draft-mozleywilliams-dnsop-dnsaid-02 の参照実装で、AI エージェントが DNS の SVCB レコードを使って相互に発見・公開できるようにします。集中型レジストリやハードコードされた URL に依存しません。既存の DNS 基盤でエージェントを公開・解決したい開発者や運用者を対象とし、仕様は IETF ドラフトが正とされています。

主な機能

01SVCB レコードによるエージェントの公開と解決
02Python SDK、コマンドラインツール、MCP サーバー
03エージェント索引レコードと HTTP インデックスによる発見
04TXT チャレンジによるドメイン制御検証（DCV）
05任意の OpenTelemetry テレメトリと認証情報コールバック

活用シーン

01所有するドメインで MCP エージェントを公開し、他システムから発見できるようにする
02DNS を通じて指定ドメイン上で利用可能なエージェントを解決する
03MCP サーバー経由で MCP クライアントからエージェントを公開・検索する

MCP 対応

本プロジェクトは MCP サーバー（dns-aid-mcp）を提供し、stdio または HTTP トランスポート経由でエージェントの公開・発見ツールを MCP クライアントに公開します。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

mcp.json · 共通設定

{
  "mcpServers": {
    "infobloxopen-dns-aid": {
      "command": "uvx",
      "args": [
        "dns-aid"
      ],
      "env": {
        "DNS_AID_BACKEND": "<DNS_AID_BACKEND>"
      }
    }
  }
}

起動コマンドuvx dns-aid

設定が必要な環境変数

DNS_AID_BACKENDDNS backend to use (route53, cloudflare, infoblox, nios, ns1, ddns, mock). Not required for discovery-only operations.

ローカルサーバーにはマシン上の実行環境（Node.js 18 以上など）が必要です。設定ファイルの場所はクライアントごとに異なります。

パッケージ

pypidns-aid0.17.3stdio

ツール

ツール一覧はまだ取得されていません

ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。

詳細

DNS-AID

DNS ベースのエージェント識別と検出

IETF draft-mozleywilliams-dnsop-dnsaid-02のリファレンス実装です。

DNS-AID を使うと、AI エージェントは集中型レジストリやハードコードされた URL ではなく、インターネットの既存の名前解決インフラストラクチャを利用して、DNS 経由で互いを検出できます。

IETF との関係

DNS-AID 仕様は IETF 内で策定されています：https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/。

このリポジトリはリファレンス実装を提供します。

このプロジェクトは仕様を定義しません。IETF ドラフトが正式な仕様です。

このリポジトリの範囲

このプロジェクトは実装、ツール、およびエコシステムの活動に重点を置いています。

プロトコルの動作に関する変更は、IETF 内で議論してください。

DNS-AID を初めてお使いですか？ インストール、最初のエージェント公開、バックエンドのセットアップについては、Getting Started Guideから始めてください。

ドキュメント

Getting Started Guide — インストール、最初のエージェント公開、バックエンドのセットアップ
API Reference — Python SDK、CLI、MCP サーバーのツールリファレンス
ARD ai-catalog discovery — Agentic Resource Discoveryとの相互運用：カタログ検出、host-anywhere DNS ポインター、カードの参照
Architecture — プロトコルレイヤー、メタデータの解決、統合ポイント
Integrations — バックエンドごとのセットアップに関する注意事項
Demo Guide — 講演やプレゼンテーション向けのエンドツーエンドの解説
Roadmap — プロジェクトの今後の方向性（短期・中期・長期）
Privacy Policy | Security Policy | Trademarks

エコシステムと統合

DNS-AID は基盤です。このリポジトリのライブラリだけで利用でき、特定のディレクトリ、インデクサー、テレメトリバックエンドに依存せず、あらゆる DNS プロバイダーに対してエージェントレコードを公開・解決します。

検索、インデックス作成、またはテレメトリのレイヤーが必要な場合、SDK はドキュメント化されたインターフェースを実装する任意の HTTP エンドポイントを指定できます。運用者には独自のものを運用することを推奨します。インデクサーは、このライブラリが公開・検出するものと同じ DNS レコードを扱う薄いレイヤーであり、SDK のテレメトリシンクは DNS_AID_SDK_HTTP_PUSH_URL で設定できます（デフォルトでは無効）。エコシステム全体に独立したディレクトリ実装が存在します。DNS-AID は単一の実装を標準化するのではなく、どの実装とも相互運用できるよう設計されています。

クイックスタート

インストール

# Install from PyPI
pip install "dns-aid[cli,mcp]"

# Or install the latest unreleased main from GitHub
pip install "dns-aid[cli,mcp] @ git+https://github.com/dns-aid/dns-aid-core.git"

バックエンド固有の追加機能（route53、cloudflare、ns1、cloud_dns、infoblox、akamai-edgedns、ddns）については、Getting Started Guideを参照してください。

Python ライブラリ

import dns_aid

# Publish your agent to DNS
await dns_aid.publish(
    name="my-agent",
    domain="example.com",
    protocol="mcp",
    endpoint="agent.example.com",
    capabilities=["chat", "code-review"]
)

# Discover agents at a domain (Path A: DNS substrate)
agents = await dns_aid.discover("example.com")
for agent in agents:
    print(f"{agent.name}: {agent.endpoint_url}")

# Discover via HTTP index (richer metadata; format aligns with the ANS schema) —
# also auto-detects and dereferences ARD ai-catalogs (see docs/ard-catalog.md)
agents = await dns_aid.discover("example.com", use_http_index=True)
# (0.26.3+) A catalog on your own domain needs nothing. An off-domain catalog
# pointer is trusted only via per-record JWS (verify_signatures=True) or, opt-in,
# a DNSSEC-validated pointer (trust_dnssec_pointers=True) — otherwise it is ignored
# and discovery falls back to the on-domain catalog. The trust basis is surfaced as
# AgentRecord.catalog_trust (tls_domain | dnssec | jws). See docs/ard-catalog.md.

# (0.26.4+) Opt-in DNSSEC/DANE hardening (SDK/CLI/MCP; all default off — DNSSEC is
# never required). require_dnssec / min_dnssec enforce the resolver AD flag on
# DNS-plane agents (ARD / HTTP-catalog agents are exempt — they carry no DNS SVCB
# record). verify_dane binds each agent endpoint's TLS cert to its DANE/TLSA record
# (defense-in-depth, meaningful only under DNSSEC) → AgentRecord.dane_verified.
# (0.26.5+) trust_dnssec_pointers (above) is exposed the same way — CLI
# --trust-dnssec-pointers / MCP — so all four opt-in trust controls have SDK/CLI/MCP parity.

# Filtered discovery — pure-Python predicates over the in-memory result (v0.19.0+)
result = await dns_aid.discover(
    "example.com",
    capabilities=["payment-processing"],
    auth_type="oauth2",
    realm="prod",
    require_signed=True,
    require_signature_algorithm=["ES256", "Ed25519"],
)

# Verify an agent's DNS records
result = await dns_aid.verify("my-agent.example.com")
print(f"Security Score: {result.security_score}/100")

パス B：外部ディレクトリを介したドメイン横断検索（v0.19.0+）

呼び出し元が、目的のエージェントをどのドメインがホストしているかまだ把握していない場合、SDK は検索エンドポイントを実装した任意のディレクトリバックエンドに問い合わせることができます。ディレクトリ層はオプトインの利便機能です。DNS 基盤は引き続き、信頼性を判断する権威あるゲートとなります。

from dns_aid.sdk import AgentClient, SDKConfig

# Point at whichever directory the caller has chosen to trust.
# Can also be set via DNS_AID_SDK_DIRECTORY_API_URL.
config = SDKConfig(directory_api_url="https://your-directory.example.com")

async with AgentClient(config=config) as client:
    response = await client.search(q="payment processing", protocol="mcp")
    for r in response.results:
        print(r.agent.fqdn)

ディレクトリから候補が返されたら、それぞれをパス A を介して再解決し、呼び出す前に署名／DNSSEC を検証してください。これは、基盤を権威とするパターンです。ディレクトリはランキングと発見の利便性を提供しますが、呼び出し元とエージェントの間の信頼経路に入ることはありません。

async with AgentClient(config=config) as client:
    response = await client.search(q="fraud detection")
    for candidate in response.results:
        verified = await dns_aid.discover(
            candidate.agent.domain,
            name=candidate.agent.name,
            require_signed=True,
        )
        # Invoke only when DNS substrate confirms the directory's claim.

SDK は追加のフィルターパラメーター（capabilities、min_security_score、verified_only など）を公開します。これらのシグナルを計算して返すディレクトリで利用できます。すべてのパラメーターについては、API リファレンスを参照してください。これらの値の意味は、呼び出し元が選択したディレクトリによって定義されます。DNS-AID がそれらを一元管理することはありません。

SDK：エージェントの呼び出しとテレメトリの取得（v0.6.0+）

import dns_aid

# Discover + invoke in one line — telemetry captured automatically
result = await dns_aid.discover("example.com", protocol="mcp")
agent = result.agents[0]

resp = await dns_aid.invoke(agent, method="tools/list")
print(f"Latency: {resp.signal.invocation_latency_ms}ms")
print(f"Status:  {resp.signal.status}")
print(f"Tools:   {resp.data}")

# Rank multiple agents by your own local telemetry signals
ranked = await dns_aid.rank(result.agents, method="tools/list")
for r in ranked:
    print(f"{r.agent_fqdn}: score={r.composite_score:.1f}")

OpenTelemetry（v0.23.0+）： dns-aid[otel] をインストールし、 otel_enabled=True（または DNS_AID_SDK_OTEL_ENABLED=true）を設定すると、呼び出しごとにスパンとメトリクスを出力し、W3C トレースコンテキストをダウンストリームのエージェントに伝播します。 docs/integrations/opentelemetry.mdを参照してください。

高度な使い方（接続の再利用、OpenTelemetry のエクスポート、プラグイン可能なテレメトリシンク）については、次を参照してください。

from dns_aid.sdk import AgentClient, SDKConfig

config = SDKConfig(
    otel_enabled=True,         # Export to any OpenTelemetry collector
    caller_id="my-app",
    # Optional: push telemetry to any HTTP endpoint the caller controls
    # http_push_url="https://your-telemetry.example.com/v1/signals",
)

async with AgentClient(config=config) as client:
    resp = await client.invoke(agent, method="tools/call", arguments={...})
    fqdns = [a.fqdn for a in agents]
    ranked = client.rank(fqdns)  # Rank by the caller's own observed telemetry

外部アグリゲーターがコミュニティ全体のランキングを HTTP 経由で公開している場合、SDK は client.fetch_rankings(...) で取得できます。エンドポイントはライブラリではなく、呼び出し元が設定します。

SDK：呼び出しごとの認証情報プロバイダーコールバック（v0.21.0+）

短期間のみ有効な認証情報（RFC 8693 トークン交換、AWS STS のロール引き受け、 HashiCorp Vault の動的シークレット、HSM/KMS を利用した署名鍵）を使用する場合は、オプトインの非同期 credential_provider コールバックを invoke() に渡します。SDK は呼び出し時に遅延してコールバックを実行し、対象の AgentRecord を渡します。また、返された dict を認証情報の解決に使用します。既存のすべての呼び出し箇所はソースを変更しなくても引き続き動作します。変更は完全に追加的です。

async def token_exchange_provider(agent: AgentRecord) -> dict[str, str]:
    # Mint a fresh delegation token per call — e.g., RFC 8693 token exchange
    # against Keycloak / Okta / Auth0 / Microsoft Entra ID.
    return {"token": await my_idp.exchange_token(subject_token, agent.fqdn)}

async with AgentClient(config=config) as client:
    resp = await client.invoke(
        agent,
        method="tools/list",
        credential_provider=token_exchange_provider,
    )

優先順位：auth_handler > credentials > credential_provider > no_auth。各ハンドラーのセキュリティマトリクス、監査証跡のフロー、および標準的なパターンについては、docs/security-credentials.mdと examples/integration_oauth2_token_exchange.py および examples/integration_aws_sts_assume_role.py を参照してください。

CLI の使い方

# Publish an agent to DNS
dns-aid publish \
    --name my-agent \
    --domain example.com \
    --protocol mcp \
    --endpoint agent.example.com \
    --capability chat \
    --capability code-review

# Publish with transport and auth metadata (v0.10.0+)
dns-aid publish \
    --name billing \
    --domain example.com \
    --protocol mcp \
    --endpoint mcp.example.com \
    --capability billing --capability invoicing \
    --transport streamable-http \
    --auth-type bearer

# Publish with DNS-AID custom SVCB parameters (v0.4.8+)
dns-aid publish \
    --name booking \
    --domain example.com \
    --protocol mcp \
    --endpoint mcp.example.com \
    --capability travel --capability booking \
    --cap-uri https://mcp.example.com/.well-known/agent-cap.json \
    --cap-sha256 dGVzdGhhc2g \
    --bap "mcp/1,a2a/1" \
    --policy-uri https://example.com/agent-policy \
    --realm production

# Discover agents at a domain (pure DNS - default)
dns-aid discover example.com

# Discover with substrate filters
dns-aid discover example.com --protocol mcp --name chat

# Discover with in-memory filters (v0.19.0+)
dns-aid discover example.com \
    --capabilities payment-processing --capabilities fraud-detection \
    --auth-type oauth2 --realm prod \
    --require-signed --require-signature-algorithm ES256

# Cross-domain search via a directory the caller has chosen (v0.19.0+)
export DNS_AID_SDK_DIRECTORY_API_URL=https://your-directory.example.com
dns-aid search "payment processing" --protocol mcp

# Discover via HTTP index (richer metadata; format aligns with the ANS schema)
dns-aid discover example.com --use-http-index

# Output as JSON
dns-aid discover example.com --json

# Verify DNS records
dns-aid verify my-agent.example.com

# List DNS-AID records in a zone
dns-aid list example.com

# List available zones (Route 53)
dns-aid zones

# Delete an agent
dns-aid delete --name my-agent --domain example.com --protocol mcp

# Index Management (v0.3.0+)
# List agents in a domain's index record
dns-aid index list example.com

# Sync index with actual DNS records (useful for repair)
dns-aid index sync example.com

# Advertise an ARD ai-catalog via DNS pointer (host-anywhere; v0.26.0+)
# Publishes _catalog._agents + _index._agents SVCB → the catalog host.
dns-aid index publish-catalog example.com catalogue.example.com

# Publish without updating the index (for internal agents)
dns-aid publish --name internal-bot --domain example.com --protocol mcp --no-update-index

# Domain Submission to a Directory (v0.4.0+)
# Submit your domain to a directory of your choice for indexing.
# The --to flag (or DNS_AID_SDK_DIRECTORY_API_URL) selects which directory.
dns-aid submit example.com --to https://your-directory.example.com

# Submit with company metadata
dns-aid submit example.com \
    --to https://your-directory.example.com \
    --company-name "Example Corp" \
    --company-website "https://example.com" \
    --company-description "We build AI agents"

エージェントインデックスレコード

DNS-AID v0.3.0 は、効率的に検出できるよう、_index._agents.{domain} にインデックスレコードを自動的に管理します。

_index._agents.example.com. TXT "agents=chat:mcp,billing:a2a,support:https"

メリット：

1 回の DNS クエリで、あるドメインにあるすべてのエージェントを検出できます
クローラーがドメインを効率的にインデックス化できます
公開されたエージェントの明示的な一覧を取得できます（推測する必要はありません）

エージェントの publish または delete を実行すると、インデックスは自動的に更新されます。内部エージェントについて更新を無効にするには、--no-update-index を使用します。

ドメイン制御の検証（v0.20.0+）

DCV を使用すると、有効期間の短い TXT レコードチャレンジにより、一方の当事者が DNS ゾーンを管理していることをもう一方の当事者に証明できます。用途は 2 つあります。匿名エージェントによる組織への所属表明と、エージェントを組織確認済みとして掲載する前の、ディレクトリによるなりすまし対策です。

# Challenger: issue a challenge for a domain
CHALLENGE=$(dns-aid dcv issue orgb.example.com --agent assistant --issuer orga.example.com --json)
TOKEN=$(echo $CHALLENGE | python3 -c "import sys,json; print(json.load(sys.stdin)['token'])")

# Claimant: place the challenge TXT record in the zone (using their own DNS credentials)
dns-aid dcv place orgb.example.com $TOKEN

# Challenger: verify the record is present and unexpired
dns-aid dcv verify orgb.example.com $TOKEN

# Claimant: revoke after successful verification
dns-aid dcv revoke orgb.example.com $TOKEN

from dns_aid.core import dcv

# Challenger
challenge = dcv.issue("orgb.example.com", agent_name="assistant", issuer_domain="orga.example.com")
# ... deliver challenge out-of-band to claimant ...

# Claimant (different process, different credentials)
await dcv.place(challenge.domain, challenge.token, bnd_req=challenge.bnd_req)

# Challenger
result = await dcv.verify(challenge.domain, challenge.token, expected_bnd_req=challenge.bnd_req)
if result.verified:
    await dcv.revoke(challenge.domain, token=challenge.token)

詳細については、API リファレンスのドメイン制御の検証を参照してください。

HTTP インデックスによる検出

DNS-AID は、ANS スタイルのディレクトリに準拠したスキーマを持つ、HTTP ベースのエージェント検出にも対応しています。DNS 経由でエンドポイントを検証しながら、より詳細なメタデータ（説明、モデルカード、機能、コスト）を提供します。

試行するエンドポイントのパターン（順番どおり）：

https://index.aiagents.{domain}/index-wellknown（デモ向け、アンダースコアなし）
https://_index._aiagents.{domain}/index-wellknown（ANS スタイル）
https://{domain}/.well-known/agents-index.json（well-known パス）

Capability Document エンドポイント（v0.4.8+）：

https://index.aiagents.{domain}/cap/{agent-name} — エージェントごとの Capability Document JSON を返します

# Fetch HTTP index directly
curl https://index.aiagents.example.com/index-wellknown

# Fetch capability document for a specific agent
curl https://index.aiagents.example.com/cap/booking-agent

# CLI with HTTP index
dns-aid discover example.com --use-http-index

# Python with HTTP index
agents = await dns_aid.discover("example.com", use_http_index=True)

検出方法	使用する場合
DNS（デフォルト）	分散性を最大化し、オフラインキャッシュを利用して、ラウンドトリップを最小限に抑えます
HTTP インデックス	詳細なメタデータ、ANS 互換性、モデルカード、機能、直接のエンドポイントが事前に必要な場合

信頼できる情報源としての FQDN（v0.4.7）： HTTP インデックスが提供する必要があるのは、各エージェントの FQDN（例：booking.example.com）のみです。エージェント名とプロトコルは FQDN から抽出されるため、個別の protocols フィールドは不要です。その後、DNS SVCB ルックアップによって権威あるエンドポイントが解決されます。

検出の透明性（v0.4.6+）： 検出された各エージェントには、データの解決方法を示すソースフィールドが含まれます。

フィールド	値	説明
`endpoint_source`	`dns_svcb`、`http_index_fallback`、`direct`	エンドポイントの解決方法
`capability_source`	`cap_uri`、`txt_fallback`、`none`	機能の検出方法（v0.4.8+）

機能の解決（v0.4.8+）： 機能は次の優先順位で解決されます。

SVCB cap URI → 機能、バージョン、説明を含む Capability Document を取得します
TXT レコードへのフォールバック → DNS TXT レコードから capabilities=chat,support を取得します
HTTP インデックスに埋め込み → インデックスの JSON レスポンスに埋め込まれた機能を使用します

MCP サーバー

DNS-AID には、Claude などの AI エージェントがほかのエージェントを公開および検出できるようにする、MCP（Model Context Protocol）サーバーが含まれています。

MCP サーバーの実行

# Run with stdio transport (default - for Claude Desktop, etc.)
dns-aid-mcp

# Run with HTTP transport
dns-aid-mcp --transport http --port 8000

利用可能な MCP ツール

ツール	説明
`publish_agent_to_dns`	AI エージェントを DNS に公開します（インデックスを自動更新）
`discover_agents_via_dns`	ドメイン上の AI エージェントを検出します（HTTP インデックスによる検出には `use_http_index` を指定できます）
`list_agent_tools`	検出された MCP エージェントで利用可能なツールを一覧表示します
`call_agent_tool`	検出された MCP エージェントのツールを呼び出します（リクエストをプロキシ）
`verify_agent_dns`	DNS-AID レコードとセキュリティを検証します
`list_published_agents`	ドメイン内のすべてのエージェントを一覧表示します
`delete_agent_from_dns`	DNS からエージェントを削除します（インデックスを自動更新）
`list_agent_index`	ドメインのインデックスレコード内のエージェントを一覧表示します
`sync_agent_index`	インデックスを実際の DNS レコードと同期します
`diagnose_environment`	環境診断を実行します（依存関係、DNS、バックエンド）

Claude Desktop との統合

Claude Desktop の設定に追加します（~/Library/Application Support/Claude/claude_desktop_config.json）：

{
  "mcpServers": {
    "dns-aid": {
      "command": "dns-aid-mcp"
    }
  }
}

これで Claude は AI エージェントを検出して接続できるようになります。

「example.com で利用可能なエージェントを探して」

「mycompany.com の DNS にチャットエージェントを公開して」

「example.com のエージェントを検出して、SFO から JFK へのフライトを検索して」

ライブデモ

Claude Desktop でライブデモをお試しください。

{
  "mcpServers": {
    "dns-aid": {
      "command": "python",
      "args": ["-m", "dns_aid.mcp.server"]
    }
  }
}

次に、Claude に予約エージェントを検出して使用するよう依頼します。

「HTTP インデックスを使って example.com のエージェントを検出し、予約エージェントを見つけて、2026 年 3 月 15 日の SFO から JFK へのフライトを検索して」

Claude は次の操作を行います。

discover_agents_via_dns を呼び出す → https://booking.example.com/mcp の booking-agent を検出します
list_agent_tools を呼び出す → search_flights、get_flight_details、check_availability、create_reservation を確認します
call_agent_tool を呼び出す → フライトを検索して結果を返します

仕組み

DNS-AID は SVCB レコード（RFC 9460）を使用して AI エージェントを広告します。

chat.example.com. 3600 IN SVCB 1 chat.example.com. alpn="a2a" port=443 mandatory="alpn,port"
chat.example.com. 3600 IN TXT "capabilities=chat,assistant" "version=1.0.0"

DNS-AID カスタム SVCB パラメーター（v0.4.8+）： IETF ドラフトに従い、SVCB レコードには、より詳細なエージェントメタデータを提供するカスタムパラメーターを追加できます。

booking.example.com. SVCB 1 mcp.example.com. alpn="mcp" port=443 \
    cap="https://mcp.example.com/.well-known/agent-cap.json" \
    cap-sha256="dGVzdGhhc2g" bap="mcp/1,a2a/1" \
    policy="https://example.com/agent-policy" realm="production"

パラメーター	目的
`cap`	機能ドキュメントへの URI（詳細な JSON メタデータ）
`cap-sha256`	整合性検証用の機能記述子の SHA-256 ダイジェスト
`bap`	バージョン管理された、サポート対象の一括エージェントプロトコル
`policy`	エージェントポリシードキュメントへの URI
`realm`	マルチテナントのスコープ識別子

これにより、どの DNS クライアントでも、独自プロトコルや中央レジストリを使わずにエージェントを検出できます。

検出フロー（DNS-AID ドラフト準拠）

  Agent A                        DNS                           Agent B
     │                            │                               │
     │  "Find agents at           │                               │
     │   salesforce.com"          │                               │
     │                            │                               │
  ┌──┴──────────────────────────────────────────────────────────────┐
  │  Step 1: Fetch HTTP Index (primary)                             │
  │  ──────────────────────────────────                             │
  │  GET https://index.aiagents.salesforce.com/index-wellknown      │
  │  Response: [{"fqdn":"chat.salesforce.com",...}]   │
  │                                                                 │
  │  Fallback: Query TXT Index via DNS                              │
  │  Query: _index._agents.salesforce.com TXT                       │
  │  Response: "agents=chat:a2a,billing:mcp"                        │
  └──┬──────────────────────────────────────────────────────────────┘
     │                            │                               │
  ┌──┴──────────────────────────────────────────────────────────────┐
  │  Step 2: Query SVCB per agent                                   │
  │  ────────────────────────────                                   │
  │  Query: chat.salesforce.com SVCB                  │
  │  Response: SVCB 1 chat.salesforce.com. alpn="a2a" port=443      │
  │            cap="https://chat.salesforce.com/.well-known/cap.json"│
  │  (DNSSEC validated)                                             │
  └──┬──────────────────────────────────────────────────────────────┘
     │                            │                               │
  ┌──┴──────────────────────────────────────────────────────────────┐
  │  Step 2b: Fetch Capability Document (if cap URI present)        │
  │  ───────────────────────────────────────────────────            │
  │  GET https://chat.salesforce.com/.well-known/cap.json           │
  │  Response: {"capabilities":["chat","support"],"version":"1.0"}  │
  │  (cap_sha256 integrity verified)                                │
  └──┬──────────────────────────────────────────────────────────────┘
     │                            │                               │
  ┌──┴──────────────────────────────────────────────────────────────┐
  │  Step 3: TXT Capabilities (fallback if no cap document)         │
  │  ──────────────────────────────────────────────────             │
  │  Query: chat.salesforce.com TXT                   │
  │  Response: "capabilities=chat,support" "version=1.0.0"          │
  └──┬──────────────────────────────────────────────────────────────┘
     │                            │                               │
     ├────────────────────────────────────────────────────────────►│
     │  Connect to https://chat.salesforce.com:443                │

インデックス解決の優先順位： HTTP インデックスエンドポイント → TXT インデックスレコード → 一般的な名前のプロービング。 機能解決の優先順位： SVCB cap URI → 機能ドキュメント → TXT レコードへのフォールバック。検出された各エージェントには、使用された経路を示す endpoint_source と capability_source が含まれます。

エージェントメタデータ契約（v0.10.0+）

DNS 検出では、エージェントがどこにいるかがわかります。エージェントメタデータ契約では、接続方法、実行できること、そして現在もアクティブかどうかがわかります。

すべての DNS-AID エージェントは、.well-known/agent.json エンドポイントを提供できます。

GET https://mcp.example.com/.well-known/agent.json

{
  "aid_version": "1.0",
  "identity": { "name": "billing", "version": "2.1.0", "deprecated": false },
  "connection": { "protocol": "mcp", "transport": "streamable-http" },
  "auth": { "type": "bearer", "header_name": "Authorization" },
  "capabilities": {
    "supports_streaming": true,
    "actions": [
      { "name": "get_invoice", "intent": "query", "semantics": "read" },
      { "name": "process_payment", "intent": "transaction", "semantics": "write" }
    ]
  }
}

オーケストレーター（LangGraph、CrewAI など）にとって重要な理由：

フィールド	オーケストレーターの判断
`intent: query`	並列呼び出しが安全で、キャッシュ可能
`intent: transaction`	アトミックな実行が必要。失敗時はロールバック
`semantics: read`	タイムアウト時の再試行が安全
`semantics: write`	再試行は安全ではありません。副作用が重複する可能性があります
`auth.type: oauth2`	呼び出し前にトークン交換が必要
`deprecated: true`	代わりに `successor_fqdn` にルーティング

A2A 互換性： DNS-AID と Google A2A はどちらも /.well-known/agent.json を使用します。メタデータフェッチャーは形式を自動検出し、DNS-AID ネイティブ形式（aid_version キーを含む）または A2A Agent Card のどちらかを判別して、両方を同じメタデータフィールドに正規化します。

アーキテクチャ

クライアント側：ツールキット

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────────────┐
│   AI Agents     │     │   Developers    │     │   Infrastructure Ops    │
│  (Claude, etc.) │     │                 │     │                         │
└────────┬────────┘     └────────┬────────┘     └────────────┬────────────┘
         │                       │                           │
         │ MCP Protocol          │ CLI                       │ CLI / API
         ▼                       ▼                           ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                         DNS-AID TOOLKIT                                 │
│                                                                         │
│  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────────────┐ │
│  │   MCP Server    │  │      CLI        │  │     Python Library      │ │
│  │                 │  │                 │  │                         │ │
│  │ • publish_agent │  │ • dns-aid       │  │ • dns_aid.publish()     │ │
│  │ • discover_     │  │   publish       │  │ • dns_aid.discover()    │ │
│  │   agents        │  │ • dns-aid       │  │ • dns_aid.verify()      │ │
│  │ • verify_agent  │  │   discover      │  │ • dns_aid.invoke()  ◄── Tier 1 SDK
│  │ • list_agents   │  │ • dns-aid       │  │ • dns_aid.rank()        │ │
│  │ • call_agent    │  │   verify        │  │                         │ │
│  └────────┬────────┘  └────────┬────────┘  └────────────┬────────────┘ │
│           │                    │                        │              │
│           └────────────────────┴────────────────────────┘              │
│                                │                                       │
│                                ▼                                       │
│  ┌─────────────────────────────────────────────────────────────────┐  │
│  │                        CORE ENGINE                              │  │
│  │                                                                 │  │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────────┐ │  │
│  │  │  Publisher  │  │ Discoverer  │  │      Validator          │ │  │
│  │  │             │  │             │  │                         │ │  │
│  │  │ Create SVCB │  │ Query DNS   │  │ • DNSSEC validation     │ │  │
│  │  │ Create TXT  │  │ Parse SVCB  │  │ • DANE/TLSA check       │ │  │
│  │  │             │  │ Return      │  │ • Endpoint health       │ │  │
│  │  │             │  │ endpoints   │  │                         │ │  │
│  │  └──────┬──────┘  └──────┬──────┘  └────────────┬────────────┘ │  │
│  │         │                │                      │              │  │
│  └─────────┴────────────────┴──────────────────────┴──────────────┘  │
│                             │                                        │
└─────────────────────────────┼────────────────────────────────────────┘
                              │
                              ▼
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│                          DNS BACKEND ABSTRACTION                                             │
│                                                                                              │
│  ┌───────────┐  ┌───────────┐  ┌───────────┐  ┌───────────┐  ┌───────────┐  ┌───────────┐    │
│  │  Route53  │  │ Infoblox  │  │   DDNS    │  │Cloudflare │  │  Akamai   │  │   Mock    │    │
│  │  (AWS)    │  │   UDDI    │  │ (RFC2136) │  │           │  │ Edge DNS  │  │ (Testing) │    │
│  └─────┬─────┘  └─────┬─────┘  └─────┬─────┘  └─────┬─────┘  └─────┬─────┘  └─────┬─────┘    │
│        │              │              │              │              │              │          │
└────────┴──────────────┴──────────────┴──────────────┴──────────────┴──────────────┴──────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                       DNS INFRASTRUCTURE                                │
│                                                                         │
│   Authoritative DNS servers hosting _agents.{domain} zones              │
│   with SVCB, TXT, and TLSA records secured by DNSSEC                   │
└─────────────────────────────────────────────────────────────────────────┘

ディレクトリおよびインデックス作成レイヤー（外部）

DNS-AID を基盤として構築されるディレクトリおよびインデックス作成サービス（エージェントレコードを求めてパブリック DNS を巡回するクローラー、.well-known/agent.json メタデータをインデックス化するサービス、検索フロントエンドなど）は、このリポジトリの対象範囲外です。これらは基盤の上に構築されますが、独立して運用されます。実装者は独自のスコアリング、ランキング、キュレーションポリシーを自由に定義できます。DNS-AID はそうした選択を一元化しません。

適切なインターフェースの選択

DNS-AID には 3 つのインターフェースがあります。用途に応じて選択してください。

Python ライブラリ

最適な用途： エージェント検出機能をコードに組み込むアプリケーション開発者。

import dns_aid

# Integrate directly into your Python application
agents = await dns_aid.discover("example.com", protocol="mcp")

用途	例
他のエージェントを検出する AI エージェントの構築	エージェントメッシュアプリケーション
既存の Python アプリへの検出機能の組み込み	Flask/FastAPI サービスへの DNS-AID の追加
自動パイプラインとスクリプト	CI/CD、定期的な公開
モックバックエンドを使用した単体テスト	実際の DNS を使わないテスト

CLI ツール

最適な用途： オペレーター、DevOps、手早く手動で操作したい場合。

dns-aid discover example.com --protocol mcp

用途	例
手動での公開／検出	新しいエージェントのデプロイのテスト
シェルスクリプトと自動化	`cron` ジョブ、デプロイスクリプト
デバッグとトラブルシューティング	DNS レコードの存在確認
ゾーン管理	エージェントの一覧表示、一括操作

MCP サーバー

最適な用途： DNS-AID の機能を必要とする AI アシスタント（Claude など）。

dns-aid-mcp  # Claude can now use DNS-AID tools

用途	例
Claude Desktop との統合	「salesforce.com のエージェントを探して」
AI 主導のインフラストラクチャ	エージェントの自己登録と検出
自然言語による DNS 管理	「自分のチャットエージェントを DNS に公開して」
エージェント型ワークフローの構築	マルチエージェントオーケストレーション

選択マトリックス

目的	使用するもの
Python アプリにディスカバリー機能を組み込む	Python Library
ターミナルからアドホックなコマンドを実行する	CLI
シェルスクリプトで自動化する	CLI
Claude／AI が DNS-AID を管理できるようにする	MCP Server
実際の DNS を使わずにテストする	Python Library（MockBackend と併用）
DNS レコードの問題をデバッグする	CLI（`dns-aid verify`）

DNS バックエンド

プロバイダーごとの環境設定については、Getting Started Guide のバックエンドに関するセクションを参照してください。

DNS-AID は複数の DNS バックエンドに対応しています。

バックエンド	説明	インストール用エクストラ	ステータス
Akamai Edge DNS	Akamai Edge DNS	`dns-aid[akamai-edgedns]`	✅ 本番環境対応
Route 53	AWS Route 53	`dns-aid[route53]`	✅ 本番環境対応
Cloudflare	Cloudflare DNS	`dns-aid[cloudflare]`	✅ 本番環境対応
NS1	NS1（現 IBM）Managed DNS	`dns-aid[ns1]`	✅ 本番環境対応
Google Cloud DNS	GCP Cloud DNS	`dns-aid[cloud-dns]`	✅ 本番環境対応
Infoblox NIOS	Infoblox NIOS（オンプレミス WAPI）	`dns-aid[nios]`	✅ 本番環境対応
Infoblox UDDI	Infoblox Universal DDI（クラウド）	`dns-aid[infoblox]`	✅ 本番環境対応
DDNS	RFC 2136 ダイナミック DNS（BIND など）	`dns-aid[ddns]`	✅ 本番環境対応
Mock	メモリー内（テスト専用）	（組み込み）	✅ 本番環境対応

Route 53 のセットアップ

AWS 認証情報を設定します。

export AWS_ACCESS_KEY_ID="your-access-key"
export AWS_SECRET_ACCESS_KEY="your-secret-key"
export AWS_DEFAULT_REGION="us-east-1"  # Optional

または AWS CLI プロファイルを使用します。

aws configure
# Or use a named profile
export AWS_PROFILE="my-profile"

ゾーンへのアクセスを確認します。
```
dns-aid zones
```

エージェントを公開します。

dns-aid publish -n my-agent -d myzone.com -p mcp -e mcp.myzone.com

Infoblox UDDI のセットアップ

Infoblox UDDI（Universal DDI）は、Infoblox のクラウドネイティブな DDI プラットフォームです。DNS-AID は Infoblox API を介した SVCB レコードと TXT レコードの作成に対応しています。

環境変数

変数	必須	デフォルト	説明
`INFOBLOX_API_KEY`	はい	-	Cloud Portal で取得した Infoblox UDDI API キー
`INFOBLOX_DNS_VIEW`	いいえ	`default`	DNS ビュー名（ゾーンはビュー内に存在します）
`INFOBLOX_BASE_URL`	いいえ	`https://csp.infoblox.com`	API ベース URL

手順に沿ったセットアップ

Infoblox Cloud Portal からAPI キーを取得します。
- Administration → API Keys に移動します
- DNS 権限を付与した新しい API キーを作成します
- キーをコピーします（表示されるのは一度だけです）

環境変数を設定します。

export INFOBLOX_API_KEY="your-api-key"
export INFOBLOX_DNS_VIEW="default"  # Or your specific view name

ゾーンとビューを確認します。
- Infoblox Portal で DNS → Authoritative Zones に移動します
- ゾーン名（例：example.com）と、所属するビューを確認します

Python で使用します。

from dns_aid.backends.infoblox import InfobloxBloxOneBackend
from dns_aid.core.publisher import set_default_backend
from dns_aid import publish

# Initialize backend (reads from environment variables)
backend = InfobloxBloxOneBackend()

# Or with explicit configuration
backend = InfobloxBloxOneBackend(
    api_key="your-api-key",
    dns_view="default",  # Your DNS view name
)

set_default_backend(backend)

await publish(
    name="my-agent",
    domain="example.com",
    protocol="mcp",
    endpoint="agent.example.com",
    capabilities=["chat", "code-review"]
)

Infoblox UDDI の SVCB 対応

Infoblox UDDI は、標準キー（alpn、port、mandatory、ipv4hint、ipv6hint など）と、プライベート用途の範囲 key65280～key65534 を含む、完全な ServiceMode SVCB（RFC 9460）に対応しています。優先度は priority > 0、svc_params は必須です。DNS-AID のカスタムパラメーター（cap、cap-sha256、bap、policy、realm、sig、connect-class、connect-meta、enroll-uri。key65400～key65405 としてエンコード）は、TXT レコードに移されず、SVCB レコードにネイティブに書き込まれます。

DNS-AID の要件	Akamai Edge DNS	Route 53	Infoblox UDDI
ServiceMode（priority > 0）	✅	✅	✅
`alpn`／`port`／`mandatory`	✅	✅	✅
プライベート用途のキー（cap／bap／policy／realm／sig／…）	✅	✅	✅

Infoblox UDDI と Akamai Edge DNS は、ServiceMode SVCB バックエンドとして完全に DNS-AID に準拠しています。

API を介してレコードを確認する

Infoblox UDDI のゾーンはパブリックに名前解決できない場合があるため、API を介してレコードを確認します。

async with InfobloxBloxOneBackend() as backend:
    async for record in backend.list_records("example.com", name_pattern="my-agent"):
        print(f"{record['type']}: {record['fqdn']}")

DDNS のセットアップ（RFC 2136）

DDNS（ダイナミック DNS）は、BIND9、Windows DNS、PowerDNS、Knot DNS など、RFC 2136 に対応するあらゆる DNS サーバーで動作する汎用バックエンドです。ベンダー固有の API を使用しないオンプレミス DNS インフラストラクチャに最適です。

環境変数

変数	必須	デフォルト	説明
`DDNS_SERVER`	はい	-	DNS サーバーのホスト名または IP
`DDNS_KEY_NAME`	はい	-	TSIG キー名
`DDNS_KEY_SECRET`	はい	-	TSIG キーシークレット（base64）
`DDNS_KEY_ALGORITHM`	いいえ	`hmac-sha256`	TSIG アルゴリズム
`DDNS_PORT`	いいえ	`53`	DNS サーバーのポート

手順に沿ったセットアップ

DNS サーバーで TSIG キーを作成します（BIND の例）：

tsig-keygen -a hmac-sha256 dns-aid-key > /etc/bind/dns-aid-key.conf

キーを使った更新を許可するよう、ゾーンを設定します：

zone "example.com" {
    type master;
    file "/var/lib/bind/example.com.zone";
    allow-update { key "dns-aid-key"; };
};

DNS-AID を設定します：

export DDNS_SERVER="ns1.example.com"
export DDNS_KEY_NAME="dns-aid-key"
export DDNS_KEY_SECRET="your-base64-secret"

Python で使用します：

from dns_aid.backends.ddns import DDNSBackend
from dns_aid import publish

backend = DDNSBackend()
# Or with explicit configuration
backend = DDNSBackend(
    server="ns1.example.com",
    key_name="dns-aid-key",
    key_secret="base64secret==",
    key_algorithm="hmac-sha256"
)

await publish(
    name="my-agent",
    domain="example.com",
    protocol="mcp",
    endpoint="agent.example.com",
    backend=backend
)

DDNS の利点

汎用性：BIND、Windows DNS、PowerDNS、Knot、および RFC 2136 に対応するあらゆるサーバーで動作します
ベンダーロックインなし：標準プロトコルを使用し、独自 API は不要です
オンプレミスに最適：企業内 DNS に最適です
DNS-AID に完全準拠：すべてのパラメーターを含む ServiceMode SVCB に対応しています

Cloudflare のセットアップ

Cloudflare DNS は、無料プランと優れた API サポートにより、デモ、ワークショップ、迅速なプロトタイピングに最適です。DNS-AID は、ネイティブのプライベート用途 SVCB キーを含む Cloudflare の SVCB レコード実装を完全にサポートしています。DNS-AID のカスタムパラメーター（cap、cap-sha256、bap、policy、realm、...）は、TXT への降格なしに SVCB レコード（key65400～key65409）へ直接書き込まれます。

環境変数

変数	必須	デフォルト	説明
`CLOUDFLARE_API_TOKEN`	はい	-	DNS 編集権限を持つ API トークン
`CLOUDFLARE_ZONE_ID`	いいえ	-	ゾーン ID（未設定の場合は自動検出）

手順に沿ったセットアップ

Cloudflare Dashboard で API トークンを作成します：
- My Profile → API Tokens → Create Token に移動します
- 「Edit zone DNS」テンプレートを使用するか、次の設定でカスタムトークンを作成します：
  - Permissions：Zone → DNS → Edit
  - Zone Resources：Include → Specific zone → your-domain.com
- トークンをコピーします（表示されるのは一度だけです）

環境変数を設定します：

export CLOUDFLARE_API_TOKEN="your-api-token"
# Optional: specify zone ID (otherwise auto-discovered from domain)
export CLOUDFLARE_ZONE_ID="your-zone-id"

最初のエージェントを公開します：

dns-aid publish \
    --name my-agent \
    --domain your-domain.com \
    --protocol mcp \
    --endpoint agent.your-domain.com \
    --backend cloudflare

Python で使用します：

from dns_aid.backends.cloudflare import CloudflareBackend
from dns_aid import publish

# Initialize backend (reads from environment variables)
backend = CloudflareBackend()

# Or with explicit configuration
backend = CloudflareBackend(
    api_token="your-api-token",
    zone_id="optional-zone-id",  # Auto-discovered if not provided
)

await publish(
    name="my-agent",
    domain="your-domain.com",
    protocol="mcp",
    endpoint="agent.your-domain.com",
    backend=backend
)

Cloudflare の利点

無料プラン：無制限のドメインで DNS ホスティングを無料で利用できます
SVCB サポート：SVCB Type 64 レコードを使用した RFC 9460 に完全準拠しています
ネイティブのプライベート用途 SVCB キー：DNS-AID のカスタムパラメーターは SVCB レコード（key65400～key65409）へ直接格納されます。TXT への降格はなく、NS1 および NIOS と同じ方式です
グローバルエニーキャスト：世界中で高速な DNS 名前解決を実現します
シンプルな API：ドキュメントが充実した REST API v4 です
DNS-AID に完全準拠：すべてのパラメーターを含む ServiceMode SVCB に対応しています

Akamai Edge DNS のセットアップ

Akamai Edge DNS はプライベート用途キーを完全にサポートした ServiceMode SVCB レコードに対応しているため、DNS-AID ドラフトに完全準拠しています。すべての DNS-AID カスタムパラメーター（cap、bap、realm など）は、TXT への降格なしに SVCB へ直接書き込まれます。

同時実行時も安全に書き込めます。バックエンドはゾーンごとに自身の書き込みを直列化し、Akamai の一時的な 409 concurrentZoneModification 応答が発生した場合は、指数バックオフを使って自動的に再試行します。

環境変数

変数	必須	デフォルト	説明
`AKAMAI_HOST`	いいえ*	-	EdgeGrid API ホスト名（例：`akab-xxxx.luna.akamaiapis.net`）
`AKAMAI_CLIENT_TOKEN`	いいえ*	-	EdgeGrid クライアントトークン
`AKAMAI_CLIENT_SECRET`	いいえ*	-	EdgeGrid クライアントシークレット
`AKAMAI_ACCESS_TOKEN`	いいえ*	-	EdgeGrid アクセストークン
`AKAMAI_EDGERC`	いいえ	`~/.edgerc`	`.edgerc` 認証情報ファイルへのパス
`AKAMAI_EDGERC_SECTION`	いいえ	`default`	使用する `.edgerc` 内のセクション

* .edgerc を使用しない場合は必須です。両方が設定されている場合、環境変数が .edgerc より優先されます。

ステップごとのセットアップ

Akamai Control CenterでAPI認証情報を作成します。
- Identity & Access → Create API Clientに移動します
- DNS—Zone Record Managementに読み取り／書き込み権限を付与します
- .edgercファイルをダウンロードするか、4つの認証情報の値を控えます

認証情報を設定します（いずれかを選択します）。

.edgercファイルを使用する場合（Akamai標準）：

# ~/.edgerc
[default]
host = akab-xxxx.luna.akamaiapis.net
client_token = akab-xxxx
client_secret = xxxx
access_token = akab-xxxx

環境変数を使用する場合：

export AKAMAI_HOST="akab-xxxx.luna.akamaiapis.net"
export AKAMAI_CLIENT_TOKEN="akab-xxxx"
export AKAMAI_CLIENT_SECRET="xxxx"
export AKAMAI_ACCESS_TOKEN="akab-xxxx"

最初のエージェントを公開します。

dns-aid publish \
    --name my-agent \
    --domain your-domain.com \
    --protocol mcp \
    --endpoint agent.your-domain.com \
    --backend akamai-edgedns

Pythonで使用します。

import asyncio
from dns_aid.backends.akamai_edgedns import AkamaiEdgeDNSBackend
from dns_aid import publish

async def main():
    # Initialize backend (reads from ~/.edgerc or environment variables)
    backend = AkamaiEdgeDNSBackend()
    await publish(
        name="my-agent",
        domain="your-domain.com",
        protocol="mcp",
        endpoint="agent.your-domain.com",
        backend=backend,
    )

asyncio.run(main())

Akamai Edge DNSの機能

ネイティブSVCBサポート：プライベート用途のキーを含む、RFC 9460への完全準拠
DNS-AIDへの完全準拠：すべてのカスタムパラメーター（cap、bap、realmなど）はSVCBレコードにネイティブに書き込まれ、TXTに格下げされません
DNSSEC：署名して配信する方式による、組み込みのゾーン署名
柔軟な認証情報：.edgercファイルと環境変数の両方をサポート

DNS-AIDと他の取り組みとの関係

エージェントのディスカバリーは現在も設計が進められている領域であり、スタックの異なるレイヤーで複数の提案が進められています。DNS-AIDは意図的に対象を絞り、公開者とリゾルバーが利用できるDNSレイヤーの基盤を標準化する一方、ディレクトリ、ランキング、決済、名前空間ポリシーは他の取り組みに委ねています。以下の概要は、運用者がDNS-AIDの位置付けを理解するためのものであり、他の取り組みと対比することを目的としていません。

隣接する取り組み

Agent Name Service（ANS） — JSONメタデータスキーマとレジストリインターフェースを定義する、ディレクトリ指向のアプローチです。DNS-AIDのHTTP Index形式は、重複する部分について意図的にANSスキーマに合わせているため、ANS形式のディレクトリは、DNS-AIDの公開者が生成するデータと同じデータから提供できます。
A2A — エージェント間のメッセージングのための通信プロトコルです。DNS-AIDはこれを補完します。A2Aは2つのエージェントがどのように通信するかを定義し、DNS-AIDは一方のエージェントが通信先となるもう一方のエージェントのエンドポイントをどのように見つけるかを定義します。
AgentDNS — DNSプリミティブ上にエージェントの命名レイヤーを構築する、別の提案です。両者は理念が重なる一方、仕組みが異なります。DNS-AIDはRFC 9460のSVCBの範囲内にとどまることを選択しているため、既存の権威サーバーやリゾルバーを変更せずに利用できます。
NANDA — ピアツーピアのオーバーレイアプローチです。DHT形式の基盤が適している環境で役立ちます。DNS-AIDはその代わりに、組織がすでに運用しているDNSインフラストラクチャを対象とします。
ai.txt / llms.txt — 既知のURLに配置する自由形式のテキストファイルです。人が読みやすいディスカバリーに役立ちます。DNS-AIDでは構造化されたSVCBレコードと、オプションのDNSSEC検証済みの信頼性を追加します。
.agent gTLD — 専用の名前空間（mycompany.agent）を作成するための、Agent CommunityによるICANNの新gTLDの取り組みです。DNS-AIDを補完するもので、.agentドメインが利用可能になれば、他のゾーンと同じようにDNS-AIDレコードを使用できます。

DNS-AIDの対象範囲

DNS-AIDは公開／解決の基盤、つまりSVCBレコードの形式、命名規則、機能およびポリシーのパラメーター、DNSSECに基づく検証経路を標準化します。特定のディレクトリ、ランキングアルゴリズム、決済システム、信頼機関を優先するものではありません。運用者はDNS-AIDを上記のいずれかの取り組みと自由に組み合わせることも、単独で運用することもできます。

背景と比較

DNS-AIDと他のエージェントディスカバリーのアプローチ（ANS、Google A2A+UCP、.agent gTLD、AgentDNS、NANDA、Web3、ai.txt）との比較、および「主権の問題」の背景については、docs/positioning.mdを参照してください。この内容は規範的なものではありません。プロトコルの位置付けはIETFによって決定されます。

例

examples/ディレクトリを参照してください。

demo_route53.py - Route 53の基本的な公開／検出
demo_full.py - エンドツーエンドの完全なデモ

# Run the full demo
export DNS_AID_TEST_ZONE="your-zone.com"
python examples/demo_full.py

開発

# Clone the repo
git clone https://github.com/dns-aid/dns-aid-core.git
cd DNS-AID

# Install all workspace packages (requires uv)
uv sync

# Run all tests
uv run pytest

# Run tests for a specific package
uv run pytest packages/dns-aid-directory/tests/
uv run pytest packages/dns-aid-crawlers/tests/
uv run pytest packages/dns-aid-k8s/tests/

# Run with coverage
uv run pytest --cov=dns_aid_directory --cov=dns_aid_crawlers --cov=dns_aid_k8s

ライセンス

Apache 2.0

コントリビューション

コントリビューションを歓迎します！このプロジェクトは、Linux Foundation でのホスティングを予定している実装エコシステムを支援しています。DNS-AID 仕様は IETF で開発されています。

ガイドラインについては、CONTRIBUTING.md をご覧ください。

Markdown 対応

ログインしてコメント

基本情報

作者: infobloxopen
言語: python
バージョン: 0.17.3
トランスポート: stdio
掲載日: 2026年4月14日
最終更新: 今日
公式 Registry: io.github.infobloxopen/dns-aid

問題を報告

MCP は初めてですか？

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

入門ガイドを読む

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。

dns-aid

dns-aid について

主な機能

活用シーン

MCP 対応

設定

ツール

詳細

DNS-AID

IETF との関係

このリポジトリの範囲

ドキュメント

エコシステムと統合

クイックスタート

インストール

Python ライブラリ

パス B：外部ディレクトリを介したドメイン横断検索（v0.19.0+）

SDK：エージェントの呼び出しとテレメトリの取得（v0.6.0+）

SDK：呼び出しごとの認証情報プロバイダーコールバック（v0.21.0+）

CLI の使い方

エージェントインデックスレコード

ドメイン制御の検証（v0.20.0+）

HTTP インデックスによる検出

MCP サーバー

MCP サーバーの実行

利用可能な MCP ツール

Claude Desktop との統合

ライブデモ

仕組み

検出フロー（DNS-AID ドラフト準拠）

エージェントメタデータ契約（v0.10.0+）

アーキテクチャ

クライアント側：ツールキット

ディレクトリおよびインデックス作成レイヤー（外部）

適切なインターフェースの選択

Python ライブラリ

CLI ツール

MCP サーバー

選択マトリックス

DNS バックエンド

Route 53 のセットアップ

Infoblox UDDI のセットアップ

環境変数

手順に沿ったセットアップ

Infoblox UDDI の SVCB 対応

API を介してレコードを確認する

DDNS のセットアップ（RFC 2136）

環境変数

手順に沿ったセットアップ

DDNS の利点

Cloudflare のセットアップ

環境変数

手順に沿ったセットアップ

Cloudflare の利点

Akamai Edge DNS のセットアップ

環境変数

ステップごとのセットアップ

Akamai Edge DNSの機能

DNS-AIDと他の取り組みとの関係

背景と比較

例

開発

関連規格

ライセンス

コントリビューション

コメント

MCP は初めてですか？

MCP（Model Context Protocol）とは？

MCP サーバーとクライアントの違いは？

ローカルとリモート、どちらを選ぶべき？

Claude や Cursor にサーバーを導入するには？

掲載プロジェクトは審査されていますか？「認証済み」とは？

自分のプロジェクトが掲載されています。どう申請できますか？