DNS가 AI 에이전트를 위한 탐색 계층(Discovery Layer)이 되고 있습니다: DNS-AID가 인프라에 의미하는 바

DNS는 40년 동안 조용히 진화해 왔습니다. 1986년에는 MX 레코드(MX records)가 인터넷에 이메일을 어디로 전달해야 할지 알려주었습니다. 2000년에는 SRV 레코드(SRV records)가 VoIP, 인스턴트 메시징 및 디렉토리 서비스를 위한 서비스 탐색(Service Discovery)을 가능하게 했습니다. 2023년에는 SVCB 레코드(RFC 9460)가 브라우저가 HTTPS 서비스를 찾고 연결하는 방식을 최적화했습니다.

이제 2026년, DNS는 다음 단계로 나아가고 있습니다. 바로 AI 에이전트(AI agents)를 위한 탐색 계층(Discovery Layer)이 되는 것입니다.

현재 IETF 내에서 개발 중인 DNS-AID 규격 (DNS-based Agent Identification and Discovery)은 AI 에이전트가 스스로를 게시하고 서로를 발견하기 위한 표준 메커니즘으로 DNS를 사용할 것을 제안합니다. 중앙 집중식 레지스트리, 하드코딩된 URL 또는 독점적인 디렉토리 대신, 에이전트들은 인터넷상의 어떤 리졸버(Resolver)라도 쿼리할 수 있는 DNS 레코드를 통해 자신의 기능, 엔드포인트(Endpoints) 및 인증 요구 사항을 광고합니다.

Infoblox가 개발하고 Linux Foundation에서 호스팅하는 참조 구현체는 이미 RFC 2136을 통해 Route 53, Cloudflare, NS1, Google Cloud DNS, BIND를 포함한 여러 DNS 제공업체에 걸쳐 게시(Publishing), 탐색(Discovery), 검증(Verification) 및 호출(Invocation)을 지원합니다.

이는 DNS 인프라를 관리하는 모든 이에게 중요한 발전입니다. 만약 DNS-AID가 채택된다면, 여러분이 오늘날 모니터링하고 있는 DNS 레코드에는 완전히 새로운 범주의 항목들이 추가될 것이며, DNS 설정 오류(Misconfiguration), 하이재킹(Hijacking) 및 방치로 인한 보안 영향은 실질적으로 훨씬 더 심각해질 것입니다.

DNS가 어떻게 서비스 탐색 프로토콜이 되었는가

DNS-AID가 왜 타당한지 이해하려면, 지난 40년 동안 반복되어 온 패턴을 살펴보는 것이 도움이 됩니다.

DNS는 원래 도메인 이름을 IP 주소로 변환하기 위해 구축되었습니다. 그러다 사람들은 이와 동일한 분산형, 캐시형, 계층적 시스템이 더 광범위한 질문에 답할 수 있다는 것을 깨달았습니다. 단순히 "이 서버가 어디에 있는가?"뿐만 아니라, "이 도메인에 대한 이메일을 어디로 보내야 하는가?" (MX 레코드), "이 도메인은 어떤 서비스를 제공하는가?" (SRV 레코드), "이 도메인에 대한 이메일 발송 권한은 누구에게 있는가?" (TXT 레코드를 통한 SPF), 그리고 "어떤 인증 기관이 이 도메인에 대한 인증서를 발급할 수 있는가?" (CAA 레코드)와 같은 질문들 말입니다.

이러한 각각의 확장 기능은 동일한 논리를 따랐습니다. DNS는 이미 보편적으로 배포되어 있고, 보편적으로 쿼리(Query)되며, 보편적으로 캐시(Cache)되어 있다는 점입니다. 처음부터 새로운 탐색 메커니즘을 구축하는 대신, 이미 어디에나 존재하는 것을 사용하는 방식입니다.

DNS-AID는 AI 에이전트 시대를 위해 정확히 이 패턴을 따릅니다. DNS-AID가 답하는 질문은 다음과 같습니다: "이 도메인은 어떤 AI 에이전트를 제공하며, 어떻게 그들에게 연결할 수 있는가?"

DNS-AID의 작동 방식

DNS-AID는 AI 에이전트를 광고하기 위해 SVCB 레코드 (RFC 9460)를 사용합니다. 에이전트를 게시하고자 하는 조직은 표준화된 명명 규칙(Naming Convention)에 따라 자신의 DNS 존(Zone)에 레코드를 추가합니다:

_chat._mcp._agents.example.com. 3600 IN SVCB 1 chat.example.com. alpn="mcp" port=443
_chat._mcp._agents.example.com. 3600 IN TXT "capabilities=chat,assistant" "version=1.0.0"

이를 분석하면 다음과 같습니다:

• _chat — 에이전트 이름
• _mcp — 프로토콜 (MCP, A2A, HTTPS 등)
• _agents — DNS-AID 네임스페이스 (Namespace)
• example.com — 에이전트를 소유한 도메인
• SVCB 레코드 — 전송 메타데이터와 함께 에이전트의 엔드포인트(Endpoint)를 가리킴
• TXT 레코드 — 에이전트의 기능(Capabilities) 및 버전을 설명함

_index._agents.example.com에 있는 인덱스 레코드는 해당 도메인에 게시된 모든 에이전트를 나열하여, 단 한 번의 DNS 쿼리로 조직이 제공하는 모든 에이전트를 발견할 수 있게 합니다:

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

탐색 흐름 (The Discovery Flow)

탐색 흐름 (The Discovery Flow)

AI 에이전트(또는 LangGraph나 CrewAI와 같은 오케스트레이터)가 특정 도메인에 있는 에이전트를 찾고자 할 때:

1. 인덱스 레코드(index record)를 쿼리하여 어떤 에이전트가 존재하는지 확인합니다.
2. 개별 SVCB 레코드를 쿼리하여 엔드포인트 상세 정보(호스트, 포트, 프로토콜)를 확인합니다.
3. TXT 레코드를 쿼리하여 기능(capabilities) 및 버전 정보를 확인합니다.
4. 선택적으로 /.well-known/agent.json에 있는 메타데이터 문서를 가져와 더 풍부한 상세 정보(인증 요구사항, 액션 의미론(action semantics), 라이프사이클 상태)를 확인합니다.
5. DNSSEC을 통해 전체 체인을 검증하여 레코드가 유효한지 확인합니다.
6. 에이전트 엔드포인트에 연결합니다.

전체 프로세스는 표준 DNS 쿼리를 사용합니다. 독점적인 API, 중앙 집중식 레지스트리, 벤더 종속(vendor lock-in)이 없습니다. 지구상의 어떤 DNS 리졸버(resolver)라도 이러한 레코드를 제공할 수 있습니다.

DNSSEC을 통한 신뢰

DNS-AID의 신뢰 모델은 DNSSEC을 기반으로 구축되었습니다. 에이전트가 DNS를 통해 다른 에이전트를 발견할 때, DNSSEC 검증은 레코드가 변조되지 않았으며 실제로 도메인 소유자에 의해 게시되었음을 확인합니다. 또한 이 사양은 TLS 인증서 검증을 위한 DANE/TLSA를 지원하며, DNSSEC 상태, TLSA 존재 여부 및 엔드포인트 상태를 평가하는 보안 점수 시스템을 포함합니다.

이는 중앙 집중식 레지스트리와는 근본적으로 다른 신뢰 모델입니다. 에이전트를 심사하는 레지스트리 운영자를 신뢰하는 대신, 이미 귀하의 이메일(DMARC), 인증서(CAA), 웹 트래픽(HTTPS)을 보호하고 있는 것과 동일한 인프라인 DNS와 DNSSEC을 신뢰하게 됩니다.

이것이 중요한 이유

AI 에이전트 생태계가 폭발적으로 성장하고 있습니다. Google의 A2A (Agent-to-Agent) 프로토콜, Anthropic의 MCP (Model Context Protocol), Microsoft의 AutoGen, LangChain의 LangGraph, 그리고 수십 개의 다른 프레임워크들은 AI 에이전트들이 대규모로 서로를 찾고 통신해야 하는 세상을 만들고 있습니다.

현재 에이전트 탐색(agent discovery)은 대부분 수동으로 이루어집니다. 개발자들이 에이전트 URL을 하드코딩하거나, JSON 파일에 MCP 서버를 설정하거나, 독점적인 디렉토리에 에이전트를 등록합니다. 이는 확장성이 없습니다. 모든 기업이 내부 도구, 고객 대응 서비스, 파트너 통합, 그리고 제3자 SaaS에 걸쳐 수십 개의 에이전트를 보유하게 될 때, 표준화되고 탈중앙화된 탐색 메커니즘이 필요합니다.

DNS-AID의 주장은 이러한 메커니즘이 이미 존재한다는 것입니다. 그것은 바로 DNS입니다. 그리고 이 주장은 몇 가지 이유로 설득력이 있습니다.

탈중앙화 (Decentralization). 어떤 단일 엔티티도 DNS를 통제하지 않습니다. 다운되거나, 해킹당하거나, 어떤 에이전트를 목록에 올릴지 결정하며 게이트키핑을 할 수 있는 중앙 등록소는 없습니다. 모든 조직은 자신만의 DNS 존(zone)을 제어하고, 자체적인 에이전트 레코드(agent records)를 게시하며, 자체적인 권한(authority)을 유지합니다.

보편적 인프라 (Universal infrastructure). 인터넷상의 모든 장치는 이미 DNS 리졸버(resolver)를 가지고 있습니다. 모든 조직은 이미 DNS 인프라를 갖추고 있습니다. 새로 배포해야 할 프로토콜도, 실행해야 할 새로운 서비스도, 관리해야 할 새로운 의존성도 없습니다.

운영의 익숙함 (Operational familiarity). IT 팀은 이미 DNS 레코드를 관리하고 있습니다. 에이전트를 위해 SVCB 레코드를 추가하는 것은 이메일을 위한 MX 레코드나 인증서를 위한 CAA 레코드를 추가하는 것과 동일한 운영 모델을 따릅니다. 도구, 프로세스, 모니터링은 이미 존재합니다.

내장된 보안 (Built-in security). DNSSEC는 즉시 사용할 수 있는 암호화 검증을 제공합니다. 운영자의 검증 프로세스를 신뢰해야 하는 중앙 집중식 등록소와 달리, DNSSEC를 사용하면 도메인의 서명 키(signing keys)를 통해 에이전트 레코드를 직접 검증할 수 있습니다.

리스크: 새로운 공격 표면, 익숙한 취약점

에이전트 탐색을 위해 DNS를 사용하는 모든 이점에는 그에 상응하는 리스크가 따릅니다. DNS는 수십 년 동안 괴롭혀온 모든 취약점을 그대로 물려받았으며, 이제 그 취약점들이 훨씬 더 이해관계가 높은(high-stakes) 영역에 적용되기 때문입니다.

DNS 하이재킹이 에이전트 하이재킹으로 변모

공격자가 도메인의 DNS를 탈취하면 웹 트래픽을 리다이렉트(redirect)하고 이메일을 가로챌 수 있습니다. DNS-AID 환경에서는 AI 에이전트의 트래픽 또한 리다이렉트할 수 있습니다. SVCB 레코드를 수정하는 공격자는 귀하의 에이전트 엔드포인트(endpoint)를 자신의 인프라로 지정하여, DNS를 통해 귀하의 서비스를 발견하는 모든 에이전트와 오케스트레이터(orchestrator)로부터 오는 모든 요청을 가로챌 수 있습니다.

이는 AI 에이전트 간의 상호작용이 금융 거래, 고객 정보, 내부 비즈니스 로직, API 자격 증명(credentials)과 같은 민감한 데이터를 포함하는 경우가 많기 때문에 특히 위험합니다. 에이전트 하이재킹(Agent hijacking)은 단순한 리다이렉션이 아닙니다. 이는 데이터 유출(data exfiltration) 채널이자 잠재적인 공급망 침해(supply chain compromise)입니다.

Dangling DNS가 에이전트 탈취로 변모

CNAME 또는 A 레코드가 폐기된 클라우드 서비스를 가리키는 Dangling DNS 레코드는 이미 인터넷에서 가장 많이 악용되는 공격 표면(attack surface) 중 하나입니다. DNS-AID는 여기에 새로운 차원인 'Dangling 에이전트 레코드'를 추가합니다. 조직이 AI 에이전트를 폐기하면서 SVCB 및 TXT 레코드를 삭제하는 것을 잊어버리면, 공격자가 해당 엔드포인트를 점유하여 조직의 도메인 아래에서 악성 에이전트를 서비스할 수 있습니다.

그 결과는 전통적인 서브도메인 탈취(subdomain takeover)보다 훨씬 심각합니다. 탈취된 서브도메인은 일반적으로 피싱(phishing) 페이지를 제공합니다. 반면, 탈취된 에이전트 엔드포인트는 기존의 정당한 에이전트가 가졌던 신뢰와 권한을 가지고 다른 AI 시스템으로부터 오는 요청을 능동적으로 처리합니다. 만약 멀티 에이전트 워크플로(multi-agent workflow) 내의 다른 에이전트들이 DNS 레코드를 기반으로 침해된 에이전트를 발견하고 호출한다면, 공격자는 워크플로 내부로 침투하게 됩니다.

DNSSEC 의존성

DNS-AID의 신뢰 모델은 DNSSEC에 크게 의존합니다. DNSSEC가 없다면 에이전트 레코드가 인증되었다는 암호학적 보장이 없습니다. 리졸버(resolver)의 캐시를 오염(poisoning)시킬 수 있는 공격자는 DNSSEC가 아닌 모든 검사를 통과하는 가짜 에이전트 레코드를 주입할 수 있습니다.

문제점: 전 세계적인 DNSSEC 도입률은 여전히 낮습니다. 2026년 기준으로, DNSSEC가 적절히 배포되고 유지 관리되는 도메인은 극히 일부에 불과합니다. 우리가 이전 기사에서 다루었던 2026년 5월의 .de TLD 장애는, 잘 관리된 DNSSEC 배포 환경이라 할지라도 일상적인 키 롤오버 (key rollover) 과정에서 치명적인 실패가 발생할 수 있음을 보여주었습니다. 강력한 DNSSEC 없이 DNS-AID를 채택하는 조직은 존재하지 않는 신뢰 기반 위에 구축을 하고 있는 것과 같습니다.

공개된 기능 노출 (Public Capability Exposure)

DNS 레코드는 공개되어 있습니다. 누구나 이를 조회할 수 있습니다. 조직이 TXT 레코드에 에이전트 기능(capabilities=payment-processing,fraud-detection,customer-data-access)을 게시하면, 그들은 전 세계에 자신들의 내부 AI가 정확히 무엇을 할 수 있는지 알리는 셈입니다. 이는 표적 공격을 계획하는 공격자, 정찰을 수행하는 경쟁사, 그리고 가치가 높은 목표물을 식별하려는 위협 행위자들에게 매우 가치 있는 정보가 됩니다.

운영 복잡성 (Operational Complexity)

대부분의 조직은 이미 오래된 레코드(stale records), 일관되지 않은 TTL, 누락된 SPF 레코드, 잊혀진 서브도메인 등 기본적인 DNS 위생 관리에도 어려움을 겪고 있습니다. 모든 AI 에이전트에 대해 SVCB 레코드, 기능 TXT 레코드, 인덱스 레코드 및 기능 문서를 추가하는 것은 관리 부담을 크게 증가시킵니다. 자동화된 모니터링이 없다면, DNS에 게시된 내용과 실제 운영 환경에서 실행 중인 내용 사이의 간극은 빠르게 벌어질 것입니다.

DNS Assistant가 이 미래에 부합하는 방식

DNS가 AI 에이전트를 위한 탐색 계층 (discovery layer)이 된다면, DNS 모니터링은 곧 AI 에이전트 보안 모니터링이 됩니다. 오늘날 DNS Assistant가 제공하는 모든 기능은 DNS-AID 보안 요구 사항과 직접적으로 매핑됩니다.

SVCB 레코드 모니터링

DNS Assistant는 이미 SVCB를 포함하여 귀하의 도메인 전반에 걸친 모든 레코드 유형을 모니터링하고 있습니다. 조직이 에이전트 레코드 (agent records)를 게시함에 따라, DNS Assistant는 에이전트 엔드포인트 (agent endpoints), 프로토콜 구성 (protocol configurations), 그리고 서비스 파라미터 (service parameters)의 변경 사항을 감지할 것입니다. 침해된 DNS 제공업체 계정, 등록 대행사 (registrar) 수준의 공격, 또는 내부 설정 오류로 인한 승인되지 않은 SVCB 수정이 발생하면 즉각적인 경고가 트리거됩니다.

TXT 레코드 변경 감지 (TXT Record Change Detection)

에이전트 기능 (capabilities), 버전 (versions), 그리고 인덱스 레코드 (index records)는 TXT 레코드에 저장됩니다. DNS Assistant는 TXT 레코드를 모니터링하며 모든 변경 사항에 대해 경고를 보냅니다. 공격자가 에이전트의 기능 목록을 수정하거나, 버전을 다운그레이드하거나, 인덱스 레코드에 가짜 에이전트 (rogue agent)를 추가하는 경우, 귀하의 팀은 이를 즉시 알 수 있습니다.

Dangling DNS 감지 (Dangling DNS Detection)

DNS Assistant는 22개 이상의 클라우드 제공업체 지문 (cloud provider fingerprints)을 통해 Dangling DNS 레코드를 확인합니다. 에이전트 엔드포인트가 클라우드 인프라로 이동함에 따라, 웹 서브도메인에 영향을 미치는 것과 동일한 Dangling DNS 위험이 에이전트 엔드포인트에도 영향을 미치게 됩니다. 폐기된 클라우드 서비스를 가리키는 방치된 SVCB 레코드는 에이전트 탈취 (agent takeover)로 이어질 수 있는 위험 요소입니다. DNS Assistant는 공격자가 이를 이용하기 전에 미리 포착합니다.

DNSSEC 검증 (DNSSEC Validation)

DNS-AID의 신뢰 모델 (trust model)은 DNSSEC에 의존하기 때문에, 유효한 DNSSEC 체인을 유지하는 것은 단순한 권장 사항이 아닌 보안 요구 사항이 됩니다. DNS Assistant는 모니터링되는 도메인에 대해 전체 DNSSEC 신뢰 체인 (chain of trust)을 검증하며, 서명 유효성 (signature validity), 만료 기간 (expiration windows), 그리고 체인 무결성 (chain integrity)을 확인합니다. 만약 DNSSEC이 깨지면 에이전트 신뢰도 깨지게 되며, DNS Assistant는 그러한 일이 발생하기 전에 귀하에게 경고를 보냅니다.

WHOIS 및 등록 모니터링 (WHOIS and Registration Monitoring)