한글 도메인이 xn--로 바뀌는 이유: 국제화 도메인과 퓨니코드

한국어.com을 샀다고 해 봅시다. 브라우저 주소창에는 한글이 그대로 보이는데, 호스팅 업체의 DNS 설정 화면이나 SSL 인증서 신청서는 xn--3e0bk47br7k.com을 적으라고 합니다. 오타처럼 생긴 이 문자열이 사실 같은 도메인입니다. 한글 이름은 사람을 위한 얼굴이고, xn--로 시작하는 쪽이 인터넷 장비들이 실제로 주고받는 이름입니다.

인터넷의 이름표에는 영문자만 들어간다

인터넷 초기에 정해진 호스트 이름 규칙은 영문자, 숫자, 하이픈만 허용합니다(흔히 LDH 규칙이라고 부릅니다). DNS 서버, 메일 서버, 방화벽, 수십 년 된 소프트웨어가 모두 이 규칙을 전제로 만들어졌습니다. 이 모든 것을 한꺼번에 바꿀 수는 없으니, 반대로 한글 이름을 영문자만으로 적는 방법을 정했습니다. 그 규칙 묶음이 IDNA(Internationalized Domain Names in Applications)이고, 현재 판은 RFC 5890~5893(IDNA2008)입니다.

IDNA는 두 가지 형태를 구분합니다.

이름	예	쓰이는 곳
U-label	한국어	사람이 읽고 입력하는 형태
A-label	xn--3e0bk47br7k	DNS, 인증서, HTTP 요청이 실제로 싣는 형태

xn--는 “이 라벨은 변환된 것”이라는 표시로, ACE 접두사라고 부릅니다. 변환은 점(.)으로 나뉜 라벨마다 따로 합니다. .com처럼 이미 영문인 라벨은 그대로 둡니다.

퓨니코드: 영문자는 그대로, 나머지는 “어디에 무엇을”

라벨을 A-label로 바꾸는 알고리즘이 퓨니코드(Punycode, RFC 3492)입니다. 독일어 bücher로 보면 원리가 잘 보입니다.

1. 라벨에서 영문자만 뽑아 순서대로 적습니다. bcher
2. 영문자가 하나라도 있으면 뒤에 하이픈을 붙입니다.
3. 빠진 글자(ü, U+00FC)를 몇 번째 자리에 넣을지와 그 문자 번호를 하나의 수로 합쳐, 그 수를 영문자와 숫자로 적습니다. kva

그래서 bücher는 bcher-kva가 되고, 접두사를 붙이면 xn--bcher-kva입니다. 한국어처럼 영문자가 하나도 없는 라벨은 1단계에서 남는 것이 없어 하이픈 없이 바로 3e0bk47br7k가 됩니다. 문자 번호의 차이를 가변 길이로 적는 방식이라, 비슷한 번호의 글자가 이어지면 결과가 짧아지고, 서로 멀리 떨어진 글자가 섞이면 길어집니다.

변환하기 전에 한 번 다듬는다

퓨니코드로 바꾸기 전에 브라우저는 입력을 정리합니다. 이 규칙은 유니코드 기술 표준 UTS #46에 있습니다.

• 대문자는 소문자로 바뀝니다. Bücher와 bücher는 같은 도메인입니다.
• 전각 영문자 ＡＢＣ.jp는 abc.jp로, 일본어 입력기에서 찍힌 마침표 。는 점으로 바뀝니다.
• 호환 문자는 기본 형태로 바뀝니다. 옛 독일 문자 ſ(긴 s)는 s가 됩니다.

다만 모든 것이 합쳐지지는 않습니다. 독일어 ß는 예전 규칙(IDNA2003)에서는 ss로 바뀌었지만, 지금 브라우저들은 ß를 그대로 두어 faß.de를 xn--fa-hia.de로 보냅니다. 규칙이 바뀌면서 같은 입력이 다른 곳으로 가던 시기가 있었다는 뜻입니다.

길이 제한은 A-label 기준

DNS 라벨 하나는 63바이트를 넘을 수 없습니다(RFC 1035). 이 한도는 한글 글자 수가 아니라 변환된 A-label의 길이에 걸립니다. 서로 다른 한글 음절로 긴 라벨을 만들어 시험해 보면 20자 안팎에서 63자에 닿습니다. 반복되는 글자나 번호가 가까운 글자로 이루어진 이름은 더 길게 쓸 수 있으니, 정확한 한도는 실제 변환 결과로 확인해야 합니다.

xn–를 보게 되는 곳

• DNS 설정: 레코드를 추가할 때 많은 서비스가 A-label을 요구합니다.
• 인증서: TLS 인증서의 도메인 항목(SAN)에는 A-label이 들어갑니다. 인증서 상세 정보를 열면 xn--가 보입니다.
• HTTP 요청과 서버 로그: 브라우저는 요청의 Host 헤더에 A-label을 보냅니다. 서버 로그와 접속 통계에도 이 형태로 남습니다.
• 이메일: 받는 서버가 국제화 메일(SMTPUTF8, RFC 6531)을 지원하지 않으면, 주소의 도메인 부분은 A-label로 바꿔 보냅니다. @ 앞부분까지 한글이면 이 방법이 통하지 않아 상대 서버가 지원해야만 전달됩니다.

같은 모양, 다른 글자: 동형 문자 피싱

국제화 도메인에는 부작용이 하나 있습니다. 키릴 문자 а(U+0430)는 라틴 문자 a와 모양이 같아서, аpple.com은 눈으로는 구별이 안 되지만 A-label로는 xn--pple-43d.com이라는 전혀 다른 도메인입니다.

그래서 브라우저는 무조건 한글이나 한자로 보여 주지 않습니다. Chrome과 Firefox는 한 라벨 안에서 문자 체계가 수상하게 섞여 있거나, 잘 알려진 도메인과 헷갈리게 생겼다면 주소창에 xn-- 형태를 그대로 보여 줍니다. 판단 기준은 UTS #39(유니코드 보안 메커니즘)를 바탕으로 합니다. 한글+한자+영문, 한자+히라가나+가타카나+영문처럼 실제로 함께 쓰는 조합은 허용되므로, 정상적인 한글 도메인은 한글로 보입니다. 주소창에 뜻 모를 xn--가 보인다면 한 번 의심해 볼 만합니다.

두 형태를 오가야 할 때

DNS 레코드나 인증서에 넣을 값을 확인하거나, 로그에 찍힌 xn--가 어느 도메인인지 알고 싶다면 퓨니코드 변환 도구에 넣어 보세요. 한글·일본어 도메인을 넣으면 A-label을, xn--로 시작하는 값을 넣으면 원래 이름을 함께 보여 줍니다. URL을 통째로 붙여 넣어도 호스트 이름만 골라내고, 입력은 브라우저 안에서만 처리합니다.

참고

• RFC 3492, Punycode: A Bootstring encoding of Unicode for IDNA
• RFC 5890–5893, Internationalized Domain Names for Applications (IDNA)
• Unicode Technical Standard #46, Unicode IDNA Compatibility Processing
• Unicode Technical Standard #39, Unicode Security Mechanisms
• RFC 1035, Domain Names – Implementation and Specification
• RFC 6531, SMTP Extension for Internationalized Email