DNS 보안 트레이너에서 ICANN87 펠로우가 되기까지: 사이버 보안 엔지니어가 발리에서 주목하는 것

2024년 7월, 나는 누사 두아의 한 교육장에서 노트북과 너무 많은 DNS 다이어그램을 가지고 앉아 있었다. 인도네시아의 .id 도메인을 운영하는 레지스트리인 PANDI가 트레이너를 위한 교육(Training of Trainer) 프로그램을 진행하고 있었고, 강사들 중 일부는 ICANN 출신이었다. 우리는 '이름이 어떻게 IP 주소로 변환되는가'라는 주제로 시작하여 DNSSEC 서명과 신뢰 체인(chains of trust)으로 끝을 맺었다. 나는 그림으로 가득 찬 노트와 아직도 남아있는 습관—피싱 링크를 보면 누가 그 도메인을 등록했고, 언제 등록했는지 궁금해하는 것—을 안고 집으로 돌아왔다.

다음 주에는 같은 해안가로 돌아갈 예정이다. ICANN의 연례 총회인 ICANN87은 2026년 10월 17일부터 22일까지 누사 두아에 위치한 발리 국제 컨벤션 센터에서 열리며, 나는 PANDI의 펠로우 중 한 명으로 그곳에 갈 것이다.

나는 이 일에 대해 매우 설렌다. 회의 일정을 재미로 읽을 정도의 흥분이다. 그래서 도착하기 전에 내가 배우고 싶은 것과 돌려주고 싶은 것을 적어보고, 나중에 그것들을 바탕으로 스스로를 점검해 보고 싶다.

인터넷의 주소록에는 회의가 열린다

내 수업에 있는 대부분의 사람들은 ICANN이 무엇인지 들어본 적이 없다. 그리고 괜찮다. 웹사이트를 열거나, 이메일을 보내거나, AI 에이전트가 URL을 가져오게 할 때마다, 무언가가 이름을 주소로 변환해야 한다. 그 무언가가 바로 DNS이다. ICANN은 이 시스템의 최상위 부분—루트 존(root zone), 최상위 도메인에 대한 규칙, 그리고 이름 배포 방식과 오용 시 발생하는 상황을 결정하는 정책 작업—을 조정한다.

내가 처음 이것을 배웠을 때 놀랐던 부분은 누가 그 규칙들을 작성하느냐는 점이다. 단 하나의 회사나 정부가 그렇게 하는 것이 아니다. 정부, PANDI 같은 레지스트리, 등록기관(registrars), 보안 자문가, 그리고 일반 인터넷 사용자 모두 각자의 자리를 가지고 있으며, 열린 회의에서 이 문제들을 논의한다. ICANN87은 그러한 회의 중 하나이며, 연례 총회는 그중 가장 큰 행사이다.

제가 온 배경

저는 정책 담당자가 아닙니다. 제 주 업무는 보안 엔지니어링이며, 그중 상당 부분은 DNS 문제의 수신 단계에서 발생합니다. 의심스러운 이메일이 들어오면 가장 먼저 확인하는 것 중 하나는 발신자의 도메인입니다. 얼마나 오래되었나요? 실제 브랜드를 한 글자만 바꿔서 복사했나요? 지난달에 존재했던 적이 있나요? 유사 도메인은 제가 처리하는 피싱의 큰 부분을 차지하기 때문에, 저는 DNS의 남용(abuse) 측면에 많은 시간을 할애했지만, 운영 주체들이 이 문제를 어떻게 생각하는지 본 적은 없습니다.

직장 밖에서는 2024년부터 PANDI에서 .id 아카데미 트레이너로 활동하며 마나도의 UNIMA와 바탐의 ITEBA에서 부트캠프를 진행했습니다. 강의실에는 학생들이, 강사들이, 그리고 작은 사업을 위해 방금 .id 도메인을 구매한 사람들이 섞여 있습니다. 요즘 제 업무 중 늘어나는 부분은 AI 에이전트(agent) 및 MCP 보안인데, 이는 제가 예상치 못한 방식으로 DNS를 다시 관련시키고 있습니다. 웹을 탐색하거나 도구를 호출하는 에이전트도 도메인 이름을 해석하기 때문에, 인간이 링크를 먼저 확인하지 않아도 브라우저가 신뢰하듯이 그 답변을 신뢰합니다.

발리에서 제가 찾고 있는 것

첫째, 정책 관점에서의 DNS 오용(abuse) 문제입니다. 저는 받은 편지함에서 어떤 것이 오용처럼 보이는지는 알고 있습니다. 하지만 레지스트리(registries)와 등록기관(registrars)이 무엇을 오용으로 간주하는지, 얼마나 빨리 조치해야 하는지, 그리고 거짓 양성(false positives)이나 합법적인 것으로 밝혀진 도메인을 폐쇄하는 것과 같이 어려운 부분이 어디인지에 대해서는 훨씬 적게 알고 있습니다. 매일 이것을 다루는 사람들에게 그 논리를 듣고 싶습니다.

둘째, 실제 배포 환경에서의 DNSSEC 문제입니다. ToT(Training of Trainers)에서 우리는 DNSSEC이 어떻게 DNS 답변에 서명하여 리졸버(resolver)가 누군가 변조했는지 알 수 있게 하는지 배웠습니다. ICANN 회의에는 보통 DNSSEC 및 보안 워크숍이 포함되는데, 저는 실무에서 무엇이 고장 나는지에 대한 운영자들의 이야기를 듣고 싶습니다. 제 학생들이 저에게 그 질문을 하는데, 지금은 제가 가진 것이 교과서적인 답변뿐입니다.

제가 모든 학생들에게 스스로의 도메인에 대해 실행할 수 있기를 바라는 확인 절차는 다음과 같습니다:

# 존(zone)이 서명되었는지? 답변에 RRSIG 레코드가 있으면 '예'를 의미합니다.
dig +dnssec SOA .

...

셋째, DNS 클라이언트로서의 AI 에이전트 문제입니다. 이것은 계획이라기보다는 직감에 가깝습니다. 아무도 의도적으로 결정하지 않았는데도 에이전트들이 무거운 DNS 사용자(heavy DNS users)로 변하고 있습니다. ICANN 커뮤니티 사람들은 이미 이 문제에 대해 이야기하고 있는지, 그리고 그렇지 않다면 유용한 논문이 있는지 궁금합니다.

제가 돌려주고 싶은 것 (What I want to give back)

PANDI는 각 펠로우(fellow)에게 한 주를 기여로 바꾸어 논문 형태로 작성하도록 요청합니다. 저는 그 점을 매우 좋아합니다. 그것은 그 주에 결과물(deliverable)이 생겨나게 하고, 저는 그런 것과 함께 일할 때 더 잘 합니다. 저의 대략적인 계획은 순환 구조입니다: 듣고, 제가 들은 것을 직장에서 보는 것과 연결하고, PANDI를 위해 작성한 후, .id Academy 자료로 만들고, 열린 부분은 여기에 게시하는 것입니다.

아직 논문 주제를 확정하지 못했습니다. 저는 저의 두 세계가 교차하는 지점에 마음이 기울고 있습니다. 즉, 방어자(defender)의 받은 편지함에서 보이는 DNS 남용 사례와 인도네시아 도메인 소유자 및 트레이너들이 현실적으로 할 수 있는 조치에 관한 것입니다. 만약 AI 에이전트 관련 논의가 구체화된다면, 그것은 별도의 발표 자료가 될 수도 있을 것 같습니다.

저에게 가장 중요한 부분은 강의실에서의 경험입니다. 마나도(Manado)나 바탐(Batam)에서 가르칠 때, 학생들은 루트 서버에 대해 질문하는 경우가 거의 없습니다. 대신 링크가 안전한지 어떻게 확인하는지, 또는 누군가가 자신의 캠퍼스 웹사이트를 위조했을 때 무엇을 해야 하는지에 대해 묻습니다. 만약 제가 더 나은 답변과 이러한 문제들을 처리하는 사람들과 프로세스의 이름들을 가지고 그 강의실로 돌아갈 수 있다면, 이번 주는 충분히 가치 있을 것입니다.

참석하신다면

만약 여러분이 ICANN87에 계시거나, 누사두아(Nusa Dua) 또는 온라인에서 DNS 남용, DNSSEC 또는 AI 에이전트가 DNS와 만나는 모든 분야로 일하고 계신 분이라면, 저는 이야기를 나누고 싶습니다. 제가 너무 많은 메모를 할 사람일 것입니다. 이 게시물에서 잘못된 부분까지 포함하여 회의 후 배운 내용을 올리겠습니다.