지난 10년간, 회사 사내망을 .corp로 굴렸다면 당신은 무단 점유(squatting) 중이었다. 도덕적인 의미가 아니다 — Active Directory 쓰는 데면 수천 곳이 똑같이 했고 툴도 딱히 말리지 않았다. 문자 그대로의 의미다: .corp는 아무도 소유하지 않은 top-level domain이었고, 원칙적으로 ICANN이 돈 내는 누군가에게 위임(delegate)할 수 있는 이름이었다. 그리고 2012–2013년 즈음엔 실제로 그걸 사겠다고 줄 선 사람들이 있었다.
이게 DNS에서 조용히 제일 무서운 문제 중 하나의 배경이고, ICANN이 10년을 들여 2024년 7월에야 해결책을 내놓은 이유다. 해결책은 .internal이다. 좋은 일이다. 그런데 사람들이 기대하는 것의 딱 절반만 해결하고, 남겨둔 절반이 실제로 당신을 무는 쪽이다.
아무도 예상 못 한 collision
함정은 이렇다. 노트북이 fileserver.corp에 접속하려 한다. 로컬 resolver는 관리자가 설정해둔 덕에 .corp를 알고 있어서 내부 zone에서 답을 주고, 파일이 열린다. 좋다. 근데 이건 .corp가 진짜 public root에 존재하지 않는 동안만 성립한다. 누군가 .corp를 진짜 gTLD로 사서 위임되는 순간, resolver 밖으로 새어 나간 내부 쿼리 — 호텔 wifi 위의 노트북, 설정 꼬인 VPN, search domain 잘못 박힌 컨테이너 — 는 전부 낯선 사람의 서버로 해석된다. 방금 당신 파일 서버의 내부 호스트명을 알게 됐고, 그 이름에 답까지 해줄 수 있는 서버로.
2013년 ICANN은 Interisle Consulting에 이게 실제로 얼마나 심각한지 측정을 맡겼다. 그해 8월 나온 보고서는 사람들이 사설이라고 믿었던 문자열에 대해 root 서버로 새어 들어오는 쿼리를 셌는데, 숫자가 어마어마했다. .home과 .corp는 root 전체에서 가장 많이 조회되는 존재하지 않는 TLD 축에 들었다 — 건물 밖으로 나갈 일이 없어야 할 이름에 하루 수십억 건씩.
ICANN의 대응이 Name Collision Occurrence Management Framework였고, 그중 당신이 실제로 야생에서 봤을 법한 조각이 127.0.53.53이다. 진짜 새 gTLD가 위임되면, 레지스트리는 그 zone 전체를 90일간 이 루프백 주소로 가리켰다 — 새어 나가는 내부 이름을 가진 사람이 진짜 서버가 답하러 나타나기 전에 알아채도록 일부러 눈에 띄게 고장 내는 것이다. 53.53은 니모닉이다: port 53, 두 번. 이게 랜덤 장애가 아니라 DNS collision임을 알아보라고. 애초에 필요하지 말았어야 할 문제에 대한 영리한 땜빵이었다.
.corp, .home, .mail은 더 나쁜 부류였다. 경고 기간을 두고 위임된 게 아니라 고위험으로 분류돼 보류됐고, 진짜 지원자들이 진짜 영수증을 들고 있었다 — 신청 하나당 18만 5천 달러. ICANN이 공식적으로 손을 든 건 2018년 2월이었다. 수수료를 환불하고, 뻔한 사실을 인정했다: 이 문자열들은 사설망에 너무 깊이 박혀서 public root에서 절대 안전할 수 없다고.
여기서 놓치기 쉬운 지점. .corp를 진짜 TLD로 가질 수 없었던 이유는 너무 많은 사람이 이미 그걸 사설처럼 쓰고 있었기 때문이다. 무단 점유가 이겼다. 그게 나머지 모두를 위한 namespace를 망가뜨렸다.
.internal이 실제로 뭔가
그래서 상식적인 수순은 — 보안 커뮤니티가 SSAC의 SAC113 권고를 통해 계속 요청해온 것 — “어떤 문자열이 점유해도 안전한가”를 추측 게임으로 두지 말고 하나를 그냥 지정하는 것이었다. 라벨 하나를 골라, root에 절대 위임하지 않겠다고 공식 문서로 약속하고, 모두에게 말한다: 여기 위에 지어라, 진짜 등록과 충돌할 일이 영영 없다, 그런 등록 자체가 없을 테니까.
2024년 7월 29일, ICANN 이사회가 그걸 했다. .internal은 이제 사설 용도로 예약됐고 root zone에 절대 나타나지 않는다. 1996년 RFC 1918이 IP 주소에 해준 걸 DNS 이름에 해준 셈이다 — 10.0.0.0/8과 192.168.0.0/16을 떼어내서 모든 가정용 공유기와 회사 LAN이 아무 조율 없이 같은 사설 공간을 재사용할 수 있게 한 그것. 이제 이름에도 같은 보장이 생겼다. printer.internal, git.internal, k8s.internal — 아무거나 골라라, 당신 것이고, 동시에 모두의 것이고, 그래도 괜찮다, 어차피 public 인터넷에서 라우팅되지 않으니까.
2026년에 새 내부 zone을 세운다면, 답은 이거다. .corp 아니고(죽음), .local도 아니고(그건 mDNS, RFC 6762 — 겹쳐 쓰지 마라), 소유한 진짜 도메인을 내부에서 슬쩍 다르게 해석하는 것도 아니다. .internal. 끝.
해결 안 되는 절반
여기서 내가 파티 깨는 사람이 될 차례다.
.internal은 *예약(reservation)*이지 special-use domain name이 아니다. 이 구분은 ICANN 행정용어처럼 들리고 실제로 그렇지만, 당신이 체감할 결과가 따라온다. .local과 .home.arpa는 RFC 6761 아래 등록돼 있어서 resolver가 그 존재를 알고 특별 취급하도록 되어 있다 — 표준 문서가 규격에 맞는 stub resolver에게 .local 쿼리를 public DNS로 내보내지 말라고 명시한다. .internal엔 그런 게 없다. RFC 6761 등록도, 정의된 resolution 동작도, resolver에게 .internal을 특별 취급하라고 말하는 그 어떤 것도 없다. 존재하는 건 오직 위임하지 않겠다는 ICANN의 약속뿐이다.
이 문장을 다시 읽어라. 이게 핵심 전부니까. 예약은 collision 위험을 없앤다 — 낯선 사람이 .internal을 소유해서 당신 파일 서버를 사칭하는 일은 이제 불가능하다. 하지만 *유출(leak)*엔 아무것도 안 한다. 당신 resolver에겐 foo.internal을 사내망 안에 붙잡아 둘 이유가 내장돼 있지 않다. 쿼리가 새면 — 그 호텔 wifi, 그 설정 꼬인 컨테이너 — 예전과 똑같이 public recursive resolver와 root로 곧장 올라가서, 경로상의 모든 운영자에게 당신 내부 호스트명을 노출한다. 달라진 건 이제 아무의 서버도 답하지 않아서 아무도 탈취할 수 없다는 것. 하지만 호스트명은 이미 문밖으로 걸어 나갔다.
그러니까 .internal은 무서운 문제(사칭)를 지루한 문제(정보 유출)와 맞바꾼 것이고, 지루한 문제는 아무도 굳이 안 고치는 쪽이다. 여전히 당신은 resolver가 .internal을 authoritative하게 답하고 가능하면 upstream으로 forward하지 않도록 직접 설정해야 한다. 그건 예약이 아니라 당신 몫이다. ICANN은 안전한 이름을 줬지, 메커니즘을 준 게 아니다.
사람들이 하나 더 걸리는 지점: .internal 이름은 정의상 globally unique하지 않다. 지구상 모든 네트워크가 각자 git.internal을 가질 수 있다. 그래서 어떤 public Certificate Authority도 여기에 TLS 인증서를 발급하지 않는다 — 백만 개 네트워크가 공유하는 이름에 대한 전역 신뢰 인증서는 완벽한 사칭 도구가 되니까, CA/Browser Forum이 non-unique 이름에 대한 공개 신뢰 인증서를 오래전에 금지했고 브라우저는 이 부류 전체를 거부한다. .internal zone 안에서 HTTPS를 원한다면 — 원해야 한다 — 자체 내부 CA를 돌리고 그 root를 기기에 배포하는 것이다. .corp 때도 마찬가지였다. .internal이 이걸 바꾸진 않는다. 그냥 당신이 이 짓을 앞으로도 계속하게 됐다는 걸 공식화할 뿐이다.
그래도 쓸 값어치는 있다
이 중 어느 것도 .internal을 안 쓸 이유는 아니다. 써라. Active Directory가 나온 이래 인터넷이 계속 회피해온 질문 — “내 내부 것들 이름을 뭐로 하지?” — 에 대한 첫 정직한 답이다. 127.0.53.53과 보류된 gTLD와 환불된 신청 수수료로 점철된 10년이 예약된 라벨 하나에 도달했고, 그건 진심으로 옳은 결과다.
다만 헤드라인만 읽고 일이 끝났다고 생각하진 마라. ICANN은 이름을 예약했다. 내부 쿼리를 안에 붙잡아 두는 건 여전히 당신 이름이 적힌 설정 파일이다. namespace는 이제 안전하다. 배관은 아직 당신 것이다.