DNS-AID 以 SVCB 與 DNSSEC 建立代理發現層，MCP、A2A 端點不再依賴中央目錄

DNS-AID 試圖處理代理互通堆疊中尚未統一的一層：一個代理在不知道中央註冊服務的情況下，如何找到另一個組織提供的 MCP、A2A 或 HTTPS 端點。其命名格式把代理與協定放入 `_<agent>._<protocol>._agents.<domain>`，再利用 RFC 9460 的 SVCB 記錄發布主機、連接埠及協定資訊。能力文件網址、雜湊、政策、版本與租戶範圍等額外中繼資料可放入自訂參數；不支援自訂 SVCB 參數的 DNS 供應商則退回 TXT 記錄。

設計的核心優點是沿用既有控制平面。企業可以在自己的網域下發布代理，透過 split-horizon DNS 對內外使用者顯示不同清單，並利用 DNSSEC 證明記錄未遭竄改；TLSA/DANE 也可把服務憑證連回 DNS 信任鏈。DNS 查詢具有現成快取與全球分散解析能力，不必把代理名稱、端點或組織身分交給單一平台。規格本身不限定通訊協定，SVCB 的 `alpn` 可標示 MCP、A2A 或後續協定。

公開的 Python 工具包包含 CLI、SDK 與 MCP server，支援 Route 53、Cloudflare、Infoblox 及 RFC 2136 動態 DNS。它也能維護 `_index._agents` 索引、取得能力文件、呼叫已發現的代理，並輸出 OpenTelemetry spans。短效憑證則可在每次呼叫前透過 callback 動態取得，避免把長期 bearer token 固定在發現資料內。

不過 DNSSEC 只能確認「這個網域發布了這筆記錄」，不能驗證代理實際能力、模型品質、執行程式完整性或授權範圍。能力搜尋仍可能需要額外目錄，而 TTL 快取也會使撤銷延遲。更重要的是，目前文件只是個人提交的 IETF Internet-Draft，明確不代表 IETF 背書；參考實作規模亦小。工程團隊下一步應觀察名稱格式、自訂 SVCB 參數、撤銷語義及與其他代理目錄方案能否收斂，再決定是否導入生產環境。