국제화 도메인 네임

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

국제화 도메인 네임(IDN)은 ASCII 문자가 아닌 문자를 포함하는 도메인 이름을 처리하기 위한 메커니즘이다. 1990년대 후반에 개념이 시작되어, 2003년 IETF에서 IDNA 표준이 확립되었다. 한국에서는 1998년 한글 도메인 네임 시스템이 개발되었고, 2011년에는 .한국 최상위 도메인이 도입되었다. IDNA는 비 ASCII 문자를 ASCII 기반 형식으로 변환하여 웹 브라우저와 같은 응용 프로그램에서 처리할 수 있도록 한다. ToASCII와 ToUnicode 알고리즘을 사용하여 변환을 수행하며, Punycode와 Nameprep 기술이 사용된다. IDN은 다양한 브라우저에서 지원되지만, 피싱 공격에 악용될 수 있는 보안 문제가 존재한다.

국제화 도메인 네임

국제화 도메인 이름

설명	애플리케이션(IDNA)에서의 국제화 도메인 이름은 애플리케이션에서 사용되는 도메인 이름이 유니코드로 표현될 수 있도록 하는 메커니즘

역사

초기 제안	1996년 마틴 듀스트가 제안
IETF 표준화	2003년 국제 인터넷 표준화 기구(IETF)에서 표준으로 채택 (RFC 3490, RFC 3491, RFC 3492)
IDNA2008	IDNA2003 표준의 문제점을 해결하기 위해 2010년 IDNA2008 발표 (RFC 5890, RFC 5891, RFC 5892)

주요 특징

다국어 지원	다양한 문자 집합(예: 한글, 중국어, 아랍어)을 사용하여 도메인 이름 등록 가능
호환성	기존 DNS 시스템과 호환성을 유지하면서 국제화된 도메인 이름 지원
변환 과정	퓨니코드(Punycode)를 사용하여 유니코드 도메인 이름을 ASCII 문자열로 변환
보안 문제	시각적으로 유사한 문자를 이용한 피싱 공격에 취약할 수 있음

기술적 상세 내용

IDNA 변환	유니코드 도메인 이름을 A-label(ASCII 호환 인코딩)로 변환하는 과정 포함
ACE 접두사	A-label은 항상 "xn--"으로 시작
유니코드 정규화	문자열 비교 전에 유니코드 정규화 수행 (NFC, NFKC, NFKD, NFKC_CF)

활용 분야

다국어 웹사이트	자국어 도메인 이름을 사용하여 사용자의 접근성 향상
국제화 이메일 주소	다국어 도메인 이름을 이메일 주소에 활용
지역화 서비스	특정 언어 또는 지역 사용자를 위한 서비스 제공

장점

사용자 편의성	사용자가 자국어로 도메인 이름을 입력하여 웹사이트에 접근 가능
브랜드 인지도 향상	자국어 도메인 이름을 통해 브랜드 인지도 향상 및 마케팅 효과 증대
국제화 지원	글로벌 시장 진출 시 다양한 언어의 도메인 이름을 활용하여 경쟁력 강화

단점

구현 복잡성	IDNA 지원을 위한 추가적인 개발 및 설정 필요
보안 문제	유사 문자 공격에 대한 대비책 마련 필요
브라우저 호환성	일부 구형 브라우저에서는 IDNA 도메인 이름이 제대로 표시되지 않을 수 있음

보안 고려 사항

유사 문자 공격 방지	시각적으로 유사한 문자를 이용한 공격을 방지하기 위한 대책 필요 (예: 유니코드 정규화, 문자 제한)
스푸핑 방지	사용자가 신뢰할 수 있는 도메인 이름인지 확인하는 메커니즘 필요

구현 및 지원

소프트웨어 지원	웹 브라우저, 이메일 클라이언트, 운영체제 등 다양한 소프트웨어에서 IDNA 지원
등록 기관	다국어 도메인 이름 등록을 지원하는 등록 기관을 통해 등록 가능

퓨니코드(Punycode)	유니코드 문자열을 ASCII 문자열로 변환하는 알고리즘 (RFC 3492)
NAMEPREP	문자열 비교 전에 유니코드 문자열을 정규화하는 과정 (RFC 3491)
IDNA2008	IDNA2003 표준의 문제점을 개선한 최신 표준 (RFC 5890, RFC 5891, RFC 5892)

관련 항목	국제화 및 지역화 유니코드 도메인 이름 시스템(DNS) 퓨니코드(Punycode)

2. 역사

1996년 12월, 마틴 듀르스트(Martin Dürst)가 UTF-5 인코딩 방식을 제안하면서 IDN 개념의 초기 기반을 마련했다. 1998년 싱가포르 국립대학교(NUS)와 Bioinformatrix Pte. Ltd.(BIX Pte. Ltd.)에서 IDN에 대한 초기 연구를 진행했다. 1999년에는 IETF IDN Birds-of-Feather 회의가 i-DNS.net에 의해 워싱턴에서 시작되었다.

2000년 1월, IETF IDN 워킹 그룹이 결성되었다. 2003년 3월에는 IDNA 관련 RFC(RFC 3454, RFC 3490, RFC 3491, RFC 3492)가 발행되어 IDNA 표준이 확립되었다. 같은 해 6월, ICANN은 레지스트리에 대한 IDN 사용 지침을 발표했으며, .cn, .info, .jp, .org 및 .tw 레지스트리에서 채택되었다.

2009년, ICANN은 국가 코드 최상위 도메인 규칙과 유사하게 국가 및 독립 지역에 할당 가능한 새로운 종류의 최상위 도메인을 구현하기로 결정했다. 2010년에는 최초의 국제화된 국가 코드 최상위 도메인(IDN ccTLD)이 생성되었는데, 이들은 이집트, 사우디아라비아, 아랍에미리트를 위한 아랍어 알파벳의 ccTLD였다.

2010년 8월, IETF는 업데이트된 "IDNA2008" 사양을 RFC 5890–5894로 발행했다.

3. IDNA (Internationalizing Domain Names in Applications)

국제화 도메인 네임(IDNA, Internationalizing Domain Names in Applications)은 비-ASCII 문자를 포함하는 도메인 네임을 처리하기 위해 2003년에 정의된 메커니즘이다.

도메인 네임 시스템(DNS)은 비ASCII 문자를 지원하지만, 웹 브라우저나 이메일과 같은 응용 프로그램은 호스트 이름 등에 사용할 수 있는 문자를 제한한다. IDNA는 이러한 응용 프로그램이 비ASCII 문자로 작성된 도메인 이름을 적절한 ASCII 기반 형식으로 변환하여 처리할 수 있도록 해준다.

IDNA 지원 응용 프로그램은 도메인 이름의 국제화된 표현(비ASCII 문자)과 ASCII 표현 간 변환을 수행한다. DNS 조회에는 ASCII 형식이 사용되지만, 사용자에게는 아랍어나 히라가나와 같이 비ASCII 문자로 된 도메인 이름을 보여줄 수 있다. IDNA를 지원하지 않는 응용 프로그램은 비ASCII 문자가 포함된 도메인 이름을 처리할 수 없지만, ASCII로 변환된 이름을 받으면 해당 도메인에 접근할 수 있다.

ICANN은 2003년 6월 IDNA 사용 지침을 발표했고, 2003년 7월부터 .jp 도메인 등록이 가능해졌다. 2004년 3월에는 .info 도메인 등록이 시작되었고, 이후 여러 최상위 도메인 레지스트리가 IDNA 기반 등록을 시작했다. IDN 지침은 2003년 6월에 처음 만들어졌으며, 2005년 11월 피싱 문제에 대응하기 위해 업데이트되었다.

모질라 1.4, 넷스케이프 7.1, 오페라 7.11은 IDNA를 지원하는 초기 응용 프로그램 중 하나였다. Internet Explorer 6용 브라우저 플러그인을 통해 IDN 지원을 제공할 수 있었으며, Internet Explorer 7.0 및 Windows Vista의 URL API는 IDN을 기본적으로 지원한다.

3.1. ToASCII와 ToUnicode

ToASCII와 ToUnicode는 도메인 이름의 ASCII와 비ASCII 형태 간 변환을 수행하는 알고리즘이다. 이 알고리즘들은 도메인 이름 전체에 적용되는 것이 아니라 개별 레이블에 적용된다. 예를 들어, 도메인 이름이 www.example.com인 경우 레이블은 www, example, com이며, ToASCII 또는 ToUnicode는 이 세 레이블 각각에 개별적으로 적용된다.

ToASCII는 ASCII 레이블을 변경하지 않고 그대로 둔다. 레이블이 도메인 네임 시스템에 적합하지 않은 경우 실패한다. 하나 이상의 비 ASCII 문자를 포함하는 레이블의 경우 ToASCII는 Nameprep 알고리즘을 적용하여 레이블을 소문자로 변환하고 다른 정규화를 수행한다. 그런 다음 ToASCII는 Punycode를 사용하여 결과를 ASCII로 변환한다. 마지막으로, 4자 문자열 "xn--"를 앞에 추가한다. 이 문자열은 ASCII 호환 인코딩 (ACE) 접두사라고 하며, Punycode로 인코딩된 레이블과 일반 ASCII 레이블을 구별하는 데 사용된다. ToASCII 알고리즘은 여러 가지 방법으로 실패할 수 있으며, 예를 들어 최종 문자열이 DNS 레이블의 63자 제한을 초과할 수 있다. ToASCII가 실패하는 레이블은 국제화 도메인 이름에 사용할 수 없다.

ToUnicode 함수는 ToASCII의 역작용을 수행하며, ACE 접두사를 제거하고 Punycode 디코딩 알고리즘을 적용한다. Nameprep 처리는 단순히 정규화이고 본질적으로 되돌릴 수 없기 때문에 Nameprep 처리를 되돌리지 않는다. ToASCII와 달리 ToUnicode는 디코딩에 실패하면 단순히 원래 문자열을 반환하므로 항상 성공한다. 이는 ToUnicode가 ACE 접두사로 시작하지 않는 문자열에 영향을 미치지 않음을 의미한다.

3.2. IDNA 인코딩 예시

독일어 "Bücher.example" 도메인은 "xn--bcher-kva.example"로 인코딩된다. 이 도메인 이름은 Bücher와 example 두 개의 레이블을 가지고 있다. 두 번째 레이블은 순수한 ASCII이므로 변경되지 않는다. 첫 번째 레이블은 Nameprep에 의해 처리되어 bücher^독일어가 되고, 그 다음 Punycode로 변환되어 `bcher-kva`가 된다. 그런 다음 `xn--`가 앞에 붙어 `xn--bcher-kva`가 생성된다. 따라서 DNS 레코드와 쿼리에 사용하기에 적합한 결과 이름은 `xn--bcher-kva.example`이다.

4. 관련 기술 및 표준

국제화 도메인 네임(IDNA)은 2003년에 정의된, 비-ASCII 문자를 포함하는 국제화 도메인 네임을 처리하기 위한 메커니즘이다.

도메인 네임 시스템(DNS)은 비 ASCII 문자를 지원하지만, 이메일 및 웹 브라우저와 같은 응용 프로그램은 호스트 이름 등과 같은 목적으로 도메인 이름에 사용할 수 있는 문자를 제한한다. IDNA는 이러한 응용 프로그램에서 사용할 수 있도록 비 ASCII 문자로 작성된 이름을 ASCII 기반 표현으로 변환하는 방법을 제공한다.

IDNA 지원 응용 프로그램은 도메인 이름의 국제화된 표현과 ASCII 표현 간에 변환할 수 있다. DNS 조회를 위해 ASCII 형식을 사용하지만, 사용자에게는 국제화된 형식을 보여준다. IDNA를 지원하지 않는 응용 프로그램은 비 ASCII 문자가 포함된 도메인 이름을 처리할 수 없지만, ASCII에 해당하는 이름을 받으면 이러한 도메인에 접근할 수 있다.

ICANN은 2003년 6월에 IDNA 사용에 대한 지침을 발표했으며, 2005년 11월 피싱 문제에 대응하기 위해 업데이트되었다. 2003년 7월부터 .jp 도메인을, 2004년 3월에는 .info 도메인을 IDNA 시스템을 사용하여 등록할 수 있었다. 여러 다른 최상위 도메인 레지스트리가 2004년과 2005년에 등록을 시작했다. 2007년 11월에는 최상위 국가 코드 도메인 이름에 중점을 둔 ICANN 워킹 그룹이 결성되었다. 또한 ICANN은 모든 응용 프로그램, 장치 및 시스템에서 IDN 및 기타 새로운 gTLD의 사용성을 증진하기 위해 노력하는 커뮤니티 주도의 범용 수용 운영 그룹을 지원한다.

모질라 1.4, 넷스케이프 7.1, 오페라 7.11은 IDNA를 지원하는 최초의 응용 프로그램 중 하나였다. Internet Explorer 6용 브라우저 플러그인을 통해 IDN 지원을 제공할 수 있다. Internet Explorer 7.0 및 Windows Vista의 URL API는 IDN을 기본적으로 지원한다.

도메인 이름의 ASCII와 비 ASCII 형태 간의 변환은 ToASCII 및 ToUnicode라는 두 알고리즘을 통해 수행된다. 이 알고리즘은 도메인 이름 전체에 적용되는 것이 아니라 개별 레이블에 적용된다. 예를 들어, 도메인 이름이 www.example.com인 경우 레이블은 www, example, com이며, 각 레이블에 ToASCII 또는 ToUnicode가 개별적으로 적용된다.

4.1. Punycode

Punycode는 유니코드 문자열을 ASCII 문자열로 변환하는 인코딩 방식이다. (RFC 3492) IDNA에서 비ASCII 문자를 포함하는 도메인 이름을 DNS에서 사용할 수 있는 형태로 변환하는 데 사용된다.

Punycode는 유니코드 문자열을 ASCII 문자열로 표현한다. 예를 들어, "bücher"라는 독일어 단어는 Punycode를 사용하여 "bcher-kva"로 변환된다. 여기에 "xn--"이라는 ACE(ASCII Compatible Encoding) 접두사가 추가되어 "xn--bcher-kva"라는 최종 형태가 된다. 이 접두사는 Punycode로 인코딩된 레이블과 일반 ASCII 레이블을 구별하는 데 사용된다.

ToASCII 알고리즘은 ASCII 레이블은 변경하지 않고, 비ASCII 문자를 포함하는 레이블은 Nameprep 알고리즘을 적용하여 소문자로 변환하고 정규화를 수행한 후, Punycode를 사용하여 ASCII로 변환한다. ToUnicode 함수는 ToASCII의 역작용을 수행하며, ACE 접두사를 제거하고 Punycode 디코딩 알고리즘을 적용한다.

4.2. Nameprep

Nameprep은 RFC 5891에 정의된 문자열 정규화 알고리즘이다. Nameprep은 유사한 문자를 동일한 문자로 취급하며, 유니코드 정규화의 일종인 Stringprep과 관련이 있다. Nameprep은 IDN 처리 과정에서 레이블을 소문자로 변환하고 다른 정규화를 수행하는 데 사용된다. 이는 대소문자 구분 제거, 불필요한 공백 제거 등 문자열 비교 및 처리를 위한 준비 작업을 포함한다.

4.3. 관련 RFC 문서

* RFC 5890 IDNA 아키텍처
* RFC 5891 Nameprep은 유사한 문자를 동일한 문자로 취급하는 정규화 방식이다. 유니코드의 정규화 Stringprep과의 관계를 나타낸다.
* RFC 3492 Punycode는 유니코드 문자를 DNS에서 사용할 수 있는 문자를 사용하여 인코딩하는 부호화 방식이다. RFC 5891은 RFC 3492를 갱신했지만, 규정된 알고리즘의 변경은 없다.
* RFC 2825 IDN을 포함하는 DNS의 확장을 위한 IAB (Internet Architecture Board, 인터넷 아키텍처 위원회)의 요구 사항
* RFC 2826 IDN의 실현을 위한 IAB (Internet Architecture Board, 인터넷 아키텍처 위원회)의 요구 사항

5. 최상위 도메인 구현

2009년, ICANN은 국가 코드 최상위 도메인과 유사하게 국가 및 독립 지역에 할당 가능한 새로운 종류의 최상위 도메인(IDN ccTLD)을 구현하기로 결정했다. 이는 신청자의 언어에 해당하는 비 라틴 문자 또는 스크립트에서 원하는 문자열, 기호 등을 사용할 수 있도록 하는 것이었지만, 충분한 시각적 고유성을 보장하기 위한 특정 지침이 적용되었다.

이러한 노력의 결과로, 2010년에는 실사용을 위한 최초의 국제화된 국가 코드 최상위 도메인(IDN ccTLD)이 생성되었다.

이러한 도메인 이름은 DNS에서 "xn--" 접두사 뒤에 언어별 글리프의 유니코드 표현을 Punycode로 번역한 ASCII 표현을 사용한다. 예를 들어, 러시아 IDN ccTLD의 키릴 문자 이름은 "рф"이며, Punycode로는 "p1ai"이고, DNS 이름은 "xn--p1ai"이다.

6. IDN 지원 브라우저

모질라 1.4, 넷스케이프 7.1, 오페라 7.11은 IDNA를 지원하는 최초의 웹 브라우저 중 하나였다. Internet Explorer 6용 브라우저 플러그인을 통해 IDN 지원을 추가할 수 있었으며, Internet Explorer 7.0 및 Windows Vista의 URL API는 IDN을 기본적으로 지원한다.

현재 IDN을 지원하는 주요 브라우저는 다음과 같다.

* Internet Explorer (Windows)
* IE 컴포넌트 브라우저 (일부)
* jig 브라우저 (휴대 전화용)
* Netscape 시리즈
* Mozilla
* SeaMonkey
* Mozilla Firefox
* Opera
* Safari
* Google Chrome

다만, 일부 브라우저에서는 가짜 키릴 문자 등을 이용해 URL을 위장하는 피싱 사기를 방지하기 위해 다음과 같은 경우 국제화 표기 대신 Punycode(「xn--」로 시작하는 영숫자와 하이픈)로 표기한다.

* IE: 이용 언어 이외의 문자를 포함하거나, 복수의 문자 체계가 혼재하는 경우, 기호 등을 포함하는 경우에는 국제화 표기를 하지 않는다.
* Google Chrome: 이용 언어 이외의 문자를 포함하거나, 복수의 문자 체계가 혼재하는 경우, 또는 내장된 블랙리스트 내의 문자를 포함하는 경우 국제화 표기를 하지 않는다. 문자 종류가 혼재되지 않는 경우의 호모그래프 공격은 Chrome 58에서 수정될 예정이었다.
* Mozilla Firefox: 내장된 블랙리스트 내의 문자를 포함하는 경우 국제화 표기를 하지 않는다. "about:config"에서 "network.IDN_show_punycode"를 true로 설정하면 국제화 표기를 강제 정지할 수 있다.
* Opera: 내장된 화이트리스트 외의 최상위 도메인에서는 국제화 표기를 하지 않는다.
* Safari: 내장된 화이트리스트 외의 문자 체계를 포함하는 경우 국제화 표기를 하지 않는다. 표준에서는 라틴 문자와 오인하기 쉬운 문자를 포함하는 키릴 문자, 그리스 문자, 체로키 문자가 목록에서 제외되어 있다.

7. 보안 문제 (IDN 동형이의어 공격)

도메인 네임에 유니코드를 사용하면 웹 브라우저에서 IDN 문자열의 시각적 표현이 스푸핑하려는 합법적인 사이트와 구별할 수 없게 보일 수 있으므로 웹사이트 스푸핑 공격이 더 쉬워질 수 있다. 예를 들어, 유니코드 문자 U+0430(키릴 소문자 a)는 영어에 사용되는 유니코드 문자 U+0061(라틴 소문자 a)와 동일하게 보일 수 있다. 구체적인 예로, 키릴 문자 а, е, і, р (a; 다음 "Ie"/"Ye" U+0435는 라틴 문자 e와 본질적으로 동일하게 보이며, U+0456은 라틴 문자 i와 본질적으로 동일하고, "Er" U+0440은 라틴 문자 p와 본질적으로 동일함)로 URL wіkіреdіа.org가 형성되는데, 이는 합법적인 wikipedia.org의 시각적 표현과 거의 구별할 수 없다(글꼴에 따라 다를 수 있음).

이러한 피싱 사기를 방지하기 위해 일부 브라우저에서는 다음과 같은 대책을 사용한다.

* Internet Explorer (Windows), IE 컴포넌트 브라우저(일부): 이용 언어 이외의 문자를 포함하거나, 복수의 문자 체계가 혼재하는 경우, 기호 등을 포함하는 경우에는 국제화 표기를 하지 않고 Punycode(「xn--」로 시작하는 영숫자와 하이픈)로 표기한다.
* Google Chrome: 이용 언어 이외의 문자를 포함하거나, 복수의 문자 체계가 혼재하는 경우, 내장된 블랙리스트 내의 문자를 포함하는 경우 국제화 표기를 하지 않는다. 문자 종류가 혼재되지 않는 경우의 호모그래프 공격이 지적되어 Chrome 58에서 수정될 예정이다.
* Mozilla Firefox: 내장된 블랙리스트 내의 문자를 포함하는 경우에는 국제화 표기를 하지 않는다. "about:config"에서 "network.IDN_show_punycode"를 true로 하면 국제화 표기를 강제 정지할 수 있다.
* Opera: 내장된 화이트리스트 외의 최상위 도메인에서는 국제화 표기를 하지 않는다.
* Safari: 내장된 화이트리스트 외의 문자 체계를 포함하는 경우에는 국제화 표기를 하지 않는다. 표준에서는 라틴 문자와 오인하기 쉬운 문자를 포함하는 키릴 문자, 그리스 문자, 체로키 문자가 목록에서 제외되어 있다.
* jig 브라우저(휴대 전화용)
* Netscape 시리즈
* Mozilla
* SeaMonkey