도메인 네임 시스템(DNS)은 보통 '사람이 읽는 이름을 IP 주소로 바꿔 주는 전화번호부' 정도로 설명된다. 그러나 DNS는 질의와 응답을 주고받는 범용 메시지 교환 체계이기도 하다. 'DNS 뮤지엄(dns.museum)'은 바로 이 점에 주목해 DNS의 평범하지 않은 활용 사례를 수집해 둔 일종의 현장 도감이다. 전시물 하나하나는 장난스럽지만, 그 밑에는 'DNS가 사실은 어디까지 할 수 있는 범용 조회 프로토콜인가'라는 진지한 질문이 깔려 있다. 실무자에게 이 모음집은 DNS를 단순한 인프라 부품이 아니라 설계·보안·운영 관점에서 다시 들여다보게 만드는 자료다.
역방향 DNS가 만드는 전광판
가장 눈에 띄는 범주는 traceroute와 역방향 DNS(PTR 레코드)를 결합한 장난이다. 경로상의 라우터 홉마다 돌아오는 호스트명을 조작하면, 평범한 네트워크 진단 명령이 글자나 그림을 출력하는 화면으로 바뀐다. 전시물 중에는 돈 매클레인의 'American Pie'나 'Let It Snow' 가사를 홉별 이름으로 뿌리는 사례, bad.horse로 traceroute를 돌리면 가사가 펼쳐지고 signed.bad.horse는 TLS 인증서 체인에 별도의 이스터에그를 숨겨 둔 사례가 있다. IPv6 경로에서 홉 제한(hop limit)을 올릴수록 손 그림이 한 홉씩 드러나거나, 정적 경로로 크리스마스트리나 스타워즈 이야기를 그려 내고, 심지어 유로 2020 경기 스코어를 실시간으로 보여 준 사례까지 등장한다. 공통점은 '경로를 통제할 수 있으면 역방향 DNS 이름을 자유 텍스트 채널로 쓸 수 있다'는 발상이다.
익숙한 인터페이스 뒤에 숨긴 리졸버
두 번째 범주는 DNS 조회를 전혀 다른 통로에 실어 보내는 실험들이다. DialDNS는 전화로 리졸버에게 질문을 걸 수 있게 하고, 어떤 프로젝트는 DNS 질의와 응답을 ICMP 핑 패킷 안에 담아 운반한다. Signal, Telegram, SMS, 과거의 짧게 운영된 소셜 계정, XMPP 확장 규격인 XEP-0418까지 — 모두 채팅이나 메시징 인터페이스 뒤에 리졸버 교환을 숨긴다. Mastodon 봇은 질의 결과가 DNSSEC 검증을 통과했는지까지 함께 보고한다. 이름의 우스꽝스러움과 달리, 이들은 'DNS는 특정 전송 계층에 묶여 있지 않다'는 사실을 반복해서 상기시킨다. DONUTS('DNS over normal, unencrypted TCP streams')라는 의도적으로 직설적인 이름이 그 점을 압축한다.
응답 레코드를 콘텐츠·연산·저장소로
TXT 레코드를 데이터 그릇으로 쓰는 전시물은 특히 실무적 상상력을 자극한다. txtrex는 블로그 글 자체를 TXT 레코드에 저장해, 한 이름으로 글 목록을 조회하고 다른 이름으로 본문을 받아 오는 'DNS만으로 하는 퍼블리싱'을 구현했다. 역폴란드 표기법 계산기는 피연산자를 DNS 이름에 담아 받으면 dig로 질의해 계산 결과를 돌려주고, dns.toys와 Stéphane Bortzmeyer의 실험용 권한 서버 Drink는 통화 환산, 세계 시각, 클라이언트 주소 반향, 숫자-문자 변환, 사용 가능한 CIDR 범위 계산, 날씨 같은 소형 유틸리티를 질의 이름 설계만으로 제공한다. ASCII 아트·미로·QR 코드·음악·게임을 TXT로 반환하는 모음, Wordle식 추측을 질의로 보내고 상태를 응답으로 받는 게임, 제한된 연결 환경을 겨냥해 위키백과 조회 결과를 DNS 응답으로 돌려주는 사례도 있다. 더 나아가 DNSKV·DNS 기반 NoSQL·DNSFS처럼 이름 계층을 키로, 레코드를 값으로 삼아 분산 캐시를 공짜 저장 계층으로 재활용하는 실험은 리졸버 캐싱의 의미를 다시 생각하게 한다.
터널링: 편리함과 위협의 양면
같은 '범용성'이 보안 관점에서는 경계 대상이 된다. 전시물에는 DNS 질의 이름과 응답에 데이터를 인코딩해 통신 채널을 만드는 DNS 터널링이 정당한 용도와 악용 사례를 함께 가진 패턴으로 소개된다. iodine은 DNS 위에 IP 터널을 세워 다른 트래픽을 흘려보내고, 안드로이드 앱 SlowDNS는 DNS만 허용되는 망에서 VPN을 DNS로 실어 나른다. FToDNS는 크기·시간 제약을 감수하며 파일을 쪼개 전송하고, Browsertunnel은 브라우저의 DNS 프리페치를 이용해 데이터를 단방향으로 유출한다 — 자바스크립트가 DNS 응답을 읽을 수 없기에 구조적으로 한 방향이다. 특히 dnscat2는 셸, 파일 전송, TCP 포트 포워딩까지 지원하는 암호화된 명령·제어(C2) 채널을 DNS 위에 구축하며, 악성코드가 TXT 레코드에 저장한 페이로드 조각을 받아 오는 방어 연구용 사례도 포함된다. 방화벽이 웹 트래픽은 막아도 DNS는 대체로 통과시킨다는 운영 현실이 이런 기법들의 전제이며, 그래서 DNS 질의 로깅과 이상 탐지가 보안 운영에서 중요하다는 점을 역설적으로 드러낸다.
이 도감의 가치와 한계는 분명히 구분해 둘 필요가 있다. 대부분은 실험이자 장난이고, DNS 특유의 작은 메시지 크기, 캐싱으로 인한 신선도 문제, 엄격한 타이밍 제약 때문에 실제 서비스의 대안이 되기는 어렵다. 파일 시스템을 DNS에 얹어 MP3를 스트리밍했다는 DNSFS나 이미지를 DNS 크기 조각으로 나눠 재조립하는 실험은 '된다'는 증명일 뿐 '쓸 만하다'는 뜻은 아니다. 그럼에도 실무자에게 주는 시사점은 실질적이다. 첫째, DNS는 통제만 확보되면 임의 데이터를 양방향으로 운반할 수 있는 채널이므로 방어 설계에서 결코 가볍게 볼 계층이 아니다. 둘째, Team Cymru의 IP-ASN 매핑이나 국제우주정거장 위치를 LOC 레코드로 15분마다 갱신하는 사례처럼, 잘 설계된 질의 이름 규약 하나로 스크립트화 가능한 조회 서비스를 만들 수 있다는 점은 사내 도구 설계에도 응용할 여지가 있다. DNS 뮤지엄은 결국 익숙한 프로토콜을 낯설게 바라보는 연습이며, 그 낯섦이 운영과 보안의 사각지대를 비춘다.