KR100444757B1

KR100444757B1 - 다언어 도메인 네임 서비스

Info

Publication number: KR100444757B1
Application number: KR10-2000-0004728A
Authority: KR
Inventors: 틴위 탄; 칭홍 셍; 쥬아이쾅 탄; 콕용 레옹; 동어윈트레이시 드실바; 쿠안시옹 림; 에드워드에스. 테이; 수브라마니안 수비아
Original assignee: 아이디엔에스코리아주식회사
Priority date: 1999-02-26
Filing date: 2000-01-31
Publication date: 2004-08-16
Also published as: CN1812407A; CN1266237A; WO2000050966A3; WO2000050966A2; CN1812407B; KR20000076575A; SG91854A1; EA200000136A3; EP1059789A3; US6314469B1; CN1238804C; JP3492580B2; HK1096499A1; EA200000136A2; HK1029418A1; US20010047429A1; EA002513B1; JP2000253067A; EP1059789A2; US6446133B1

Abstract

본 발명은 다언어 도메인 네임 시스템에 관한 것으로, 보다 상세히 설명하면 사용자가 비-유니코드 또는 ASCII 인코딩 형식의 도메인 네임을 사용하도록 하는 다언어 도메인 네임 시스템에 관한 것이다. 국제 DNS 서버(또는 iDNS 서버)는 다언어 DNS 요구를 수신하고 그것을 통상적인 도메인 네임 시스템에서 사용될 수 있는 포맷으로 변환한다. 우선 iDNS 서버가 DNS 요구를 수신하면, iDNS 서버는 그 요구의 인코딩 타입을 결정한다. 도메인 네임의 최상위-레벨 도메인(또는 다른 부분)의 비트 문자열을 고려하고 그 문자열을 다양한 인코딩 타입의 공지된 최상위-레벨 도메인에 대한 공지된 비트 문자열의 목록과 대조하여 일치하는 지를 조사함으로써 DNS 요구의 인코딩 타입 결정을 수행할 수 있다. 목록내의 하나의 엔트리에는 예를들면 중국의 BIG5의 ".com"에 대한 비트 문자열이 있을 수 있다. iDNS 서버가 도메인 네임의 인코딩 타입을 식별한 이후, iDNS 서버는 도메인 네임의 인코딩을 유니코드로 변환한다. 이후에 유니코드 표현을 범용 DNS 표준을 따르는 ASCII 표현으로 번역한다. 이후에 이것은 ASCII 포맷의 도메인 네임을 인식하고 그에 상응하는 IP 주소를 반환하는 통상적인 도메인 네임 시스템으로 보내진다.

Description

다언어 도메인 네임 서비스{MULTI-LANGUAGE DOMAIN NAME SERVICE}

본 발명은 네트워크 도메인 네임을 해당 네트워크 주소로 도출하는 데 사용되는 도메인 네임 서비스에 관한 것이다. 보다 상세하게 설명하면, 본 발명은 ASCII 인코딩 포맷에 맞지 않는, 다수의 다른 인코딩 포맷으로 제공되는 도메인 네임을 수용하는 대체 또는 변경 도메인 네임 서비스에 관한 것이다.

인터넷은 순수 연구단체 및 대학 단체로부터 다른 언어 및 문화를 갖는 다양한 사회를 이루는 세계적인 네트워크로 발전되었다. 모든 지역에서, 인터넷은 사용자의 지역화 요구를 처리하는 방향으로 진전되고 있다. 오늘날, 전자우편은 대부분의 언어로 교환된다. 월드 와이드 웹 상의 콘텐츠는 다언어가 가능한 소프트웨어 응용 프로그램이 증가함에 따라 현재 많은 다른 언어로 개발되고 있다. 중국어로 다른 사람에게 전자우편 메시지를 전송하거나 또는 일본어로 된 월드 와이드 웹 페이지를 보는 것이 가능하다.

오늘날 인터넷은 사람이 읽을 수 있는 이름을 숫자로된 IP 주소로 또는 그 반대의 경우로 도출(resolving)하는 데 도메인 네임 시스템(Domain Name System, DNS)에 전적으로 의존한다. 도메인 네임 시스템은 여전히 라틴-1 알파벳의 서브세트, 주로 영어에 기초하고 있다. 보편성을 제공하기 위해, 전자우편 주소, 웹 주소, 및 기타 인터넷 주소지정 포맷은 상호운용성을 보증하는 전 세계적인 표준으로ASCII를 채택했다. 전자우편 또는 웹 주소가 비-ASCII 형식의 모국어로 되도록 하는 규정은 없다. 거기에는 어떠한 인터넷 사용자가 ASCII 문자의 일정 기본 지식을 가져야만 함을 내포하고 있다.

이것은 일반적으로 말해서, 과학, 기술, 사업 및 정치의 국제 언어로서 영어를 이해할 수 있는 기술자 또는 사업가에게는 문제가 되지 않는 반면, 영어가 널리 사용되지 않는 국가에 대한 인터넷의 급속한 확산에 장애물이 된다. 그러한 국가에서, 인터넷 초학자는 전자우편 응용 프로그램이 제공된다 하더라도 전자우편 주소가 모국어를 제공할 수 없기 때문에, 그의 모국어로 전자우편을 전송하는 데 필요조건으로서 기본적인 영어를 이해하고 있어야 한다. 주식회사 인트라넷은 화일명 및 디렉토리 경로가 자국내에서 여러 나라 말로 쓰일 수 있다 하더라도 프로토콜이 도메인 네임 필드에서 ASCII 형식 이외의 것을 지원하지 않기 때문에 그들의 부서 도메인 네임 및 웹 문서를 명명하는 데 ASCII를 사용해야 한다.

또한, 유럽 언어의 사용자는 액센트 및 기타의 것 없이 그들의 도메인 네임을 근사화해야 한다. 회사의 동일성을 갖기를 희망하는 Citroёn과 같은 회사는 ASCII와 가장 유사하게 근사화해서 "www.citroen.fr"을 사용해야 하고, 프랑스 출신의씨는 "francois@email.fr"(가상의 예)으로 그의 전자우편 주소를 의도적으로 잘못 식자하는 것을 계속해서 감수해야 한다.

최근에, 전자우편 주소부에서의 사용자-id는 운영 시스템이 관련 지역의 폰트를 제공하도록 지역화되면서 다언어 스크립트로 될 수 있다. 디렉토리 및 화일명 역시 다언어 스크립트로 표현될 수 있다. 하지만, 이들 이름의 도메인 네임부는 도메인 네임 시스템을 기술하는 표준인 RFC1035의 인터넷 표준에 의해 허용되는 다언어 스크립트에서 제한된다.

이러한 상황에 대한 한 가지 정당한 이유는 소프트웨어 개발자가 중첩코드(overlapping code)를 사용하려고 하는 것이 될 수 있다. 예를들면, 한자 BIG5 및 GB2312 인코딩(즉, 그림문자 또는 문자의 디지털 표현)은 중첩되고, 일본어 JIS 및 Shift-JIS 및 한국어 KSC5601 역시 중첩된다. 결과적으로, 인코딩을 지정하는 추가적인 파라미터가 인코딩이 사용되어지는 클라이언트 응용 프로그램을 알리는 데 포함되지 않는다면, JIS로 BIG5를 또는 KSC5601로 GB2312를 인코딩하는 것 간의 차이를 쉽게 말할 수 없다. 따라서, 도메인 네임의 유일성 및 인코딩의 확실성을 보장하기 위해, DNS는 ASCII에 고정되었다.

RFC1035에 기초하여, 유효한 도메인 네임은 현재 A-Z의 알파벳 문자(대문자와 소문자를 구별하지 않음), 0-9의 숫자, 및 하이폰 기호(-)만을 포함하는 ISO-8859 라틴 1 알파벳의 서브세트에 제한되고 있다. 이러한 제한은 도메인 네임이 영어 또는 말레이어 또는 일본어의 로마지(Romaji), 또는 음역되는 타밀과 같은 로마문자의 음역과 같이 로마문자화된 형태의 언어를 효과적으로 지원하게 한다. 그외에 채용가능한 스크립트는 없다. 심지어 확장 ASCII 문자도 사용될 수 없다.

유니코드(Unicode)는 가장 중요한 언어의 거의 모든 문자가 16비트 값으로 유일하게 매핑되는 문자 인코딩 시스템이다. 유니코드가 유일한 비-중첩 인코딩 시스템에 대한 기초를 규정한 이후, 몇몇 연구가는 유니코드가 오늘날 전세계에 존재하는 매우 다양한 언어를 포용할 수 있는 장래의 DNS 이름공간에 대한 기초로서 사용될 수 있을 것인가를 조사했다(1998년 7월의 IETF 홈 페이지 "http://www.ietf.cnri.reston.va.us/ID.html"에서 찾을 수 있는 엠. 듀르스트의 인터넷 드래프트 "draft-duerst-dns-il8n-02.txt"인 "도메인 네임의 국제화(Internationalization of Domain Names)"를 참조). 이 문서는 그 전체가 여기에 참고로 도입되었다. 새로운 이름공간은 비-영어권의 사람이 인터넷 사용을 더 용이하게 하는 다언어 및 다중스크립트 기능성을 제공할 수 있어야 한다.

새로운 도메인 네임 시스템에 대한 표준 문자 세트로서 유니코드를 채택하는 것은 다른 언어의 스크립트에 대한 중첩코드공간을 피하게 된다. 이런 식으로, 인터넷 공동체가

www.citroёn.ch

와 같은 그들의 모국어 스크립트로 도메인 네임을 사용하도록 한다.

불행히도, 다언어 도메인 네임 시스템을 실시하도록 DNS 서버 및 클라이언트 응용 프로그램을 변경하는 것을 방해하는 몇 가지 어려움이 있다. 예를들면, 장래의 모든 클라이언트 응용 프로그램 및 장래의 모든 DNS 서버가 변경되어야 한다. 클라이언트 및 서버 모두 시스템이 가동되도록 변경되어야 하기 때문에, 구 시스템에서 신규 시스템으로의 변환이 어렵게 된다. 또한, 고유의 유니코드를 사용할 수 있는 클라이언트 응용 프로그램은 거의 없다. 대신, 대부분의 다언어 클라이언트응용 프로그램은 비-유니코드 인코딩을 사용하며, 다수의 후속 응용 프로그램을 갖는다.

상기 및 그 외의 점에서, 많은 언어 인코딩이 DNS 시스템에서 사용될 수 있도록 하는 기술을 갖는 것은 매우 바람직하다.

본 발명은 사용자가 비-유니코드 및 비-ASCII 인코딩 방식의 도메인 네임을 사용하여 다언어 도메인 네임 시스템을 실행하는 시스템 및 방법을 제공한다. 상기 방법은 다양한 시스템 또는 시스템들의 조합에서 실행될 수 있기 때문에, 실행 시스템은 국제 DNS 서버(또는 "iDNS" 서버)로 명명된다. iDNS 서버가 DNS 요구를 받게 되면, iDNS 서버는 그 요구의 인코딩 타입을 결정한다. 도메인 네임의 최상위-레벨(top-level) 도메인내의 비트 문자열을 고려하고 그 문자열을 다양한 인코딩 타입중 공지된 최상위-레벨 도메인에 대해 공지된 비트 문자열의 목록과 대조하여 일치하는 지를 조사함으로써 DNS 요구의 인코딩 타입 결정를 실행할 수 있다. 예를들면, 목록내의 하나의 엔트리는 중국어 BIG5의 ".com"에 대한 비트 문자열일 수 있다. iDNS 서버가 도메인 네임의 인코딩 타입을 식별한 후, iDNS 서버는 도메인 네임의 인코딩을 범용 언어 인코딩 타입(예를들면, 유니코드)으로 변환한다. 이후에 iDNS 서버는 범용 언어 인코딩 타입 표현을 범용 DNS 표준을 따르는 ASCII 표현으로 번역한다. 이후 이것은 ASCII 포맷의 도메인 네임을 인식하고 관련되는 IP 주소를 반환하는 통상적인 도메인 네임 시스템으로 보내진다.

본 발명의 일면은 디지털 방식으로 표현된 도메인 네임의 언어 인코딩 타입을 검출하는 방법을 제공한다. 상기 방법은 다음의 단계들:(a) 디지털 방식으로 표현된 도메인 네임의 사전-설정부(prespecified portion)(예를들면, 최상위-레벨 도메인)의 디지털 시퀀스를 수신하는 단계; (b) 도메인 네임으로부터의 디지털 시퀀스를 공지된 디지털 시퀀스의 콜렉션으로부터의 공지된 디지털 시퀀스와 대조하여 일치하는 지를 검사(matching) 하는 단계; 및 (c) 도메인 네임으로부터의 디지털 시퀀스와 매치되는 공지된 디지털 시퀀스와 관련되는 인코딩 타입을 식별하는 단계,에 의해서 특성화될 수 있다. 단계 (b)에서 사용되는 공지된 각각의 디지털 시퀀스는 특정 언어 인코딩 타입과 관련된다. 공지된 디지털 시퀀스의 콜렉션이 적어도 두 개의 다른 언어 인코딩 타입에 대한 공지된 디지털 시퀀스를 포함하는 것에 주의하라.

공지된 디지털 시퀀스 및 인코딩 타입을 포함하는 속성을 갖는 레코드를 포함하는 테이블 형식의 콜렉션을 제공하는 것이 편리하다. 이러한 경우에 있어서, 인코딩 타입을 식별하는 것은 매치하는 공지된 디지털 시퀀스를 갖는 레코드의 인코딩 타입을 식별하는 것이 필요하다. 테이블내에 표현되는 인코딩 타입의 예에는 ASCII, BIG5, GB2312, Shift-JIS, EUC-JP, KSC5601, 및 확장 ASCII가 포함된다.

적어도 두 개의 공지된 디지털 시퀀스가 도메인 네임으로부터의 디지털 시퀀스와 일치하는 경우, 모호성을 해결하는 것이 필요하다. 이것은 (a) 디지털 방식으로 표현된 도메인 네임의 제 2 부분의 디지털 시퀀스를 수신하고, (b) 적어도 두 개의 공지된 디지털 시퀀스와 관련되는 언어 인코딩 타입들중 다른 하나의 디코딩 기구를 사용하여, 여러 차례 제 2 부분의 디지털 시퀀스를 디코딩하고, (c) 최상의결과를 나타내는 디코딩을 식별함으로써 수행될 수 있다. 이외에, 모호성은 우선 확장된 디지털 시퀀스(도메인 네임의 제 1 및 제 2 부분을 포함)를 매칭시키고, 이후에 확장 시퀀스와 일치하는 공지된 디지털 시퀀스에 대해 확장 시퀀스를 매칭시키므로써 해결될 수 있다. 이러한 경우에 있어서, 공지된 디지털 시퀀스의 콜렉션은 확장 시퀀스의 일부를 포함해야만 한다.

특정 실시예에 있어서, 레코드는 "최소 코드 도출 문자열(minimum code resolving string)"(MCRS)의 디지털 시퀀스(또는 디지털 시퀀스의 표현)를 포함한다. 이것은 도메인 네임의 일부에 대한 디지털 시퀀스이며, 특정 인코딩 타입의 도메인 네임을 콜렉션내의 모든 다른 도메인 네임/인코딩 타입 조합과 구별하는 것으로 알려져 있다. MCRS는 최상위-레벨 도메인의 서브-문자열(sub-string), 최상위-레벨 도메인의 슈퍼-문자열(super-string)이 될 수 있고, 매칭될 때 모호성이 해결되기만 하면, 제 2 및 제 3 레벨 도메인 등으로 오버플로우(overflow) 할 수 있다.

언급된 바와 같이, 상기 방법은 특히 DNS 요구를 처리하는 데 적용가능하다. 따라서, 상기 방법은 (i) 디지털 방식으로 표현된 도메인 네임을 포함하는 DNS 요구 수신하는 단계, (ⅱ) 인식된 인코딩 타입의 루트 레벨 도메인을 도출하는 데 신뢰할 수 있는 루트 레벨 DNS 서버를 식별하는 단계, 및 (ⅲ) 상기 DNS 요구를 루트 레벨 DNS 서버에 전송하는 단계도 포함할 수 있다. DNS 요구를 전송하기 이전에, 시스템은 인식된 인코딩 타입으로부터의 도메인 네임의 디지털 시퀀스를 DNS 프로토콜과 호환가능한 DNS 인코딩 타입(예를들면, ASCII, 가능한 한 유니코드 또는 장래의 어떠한 다른 범용 인코딩)으로 변환해야 한다. 바람직한 실시예에 있어서, 이러한 변환은 (i) 인식된 인코딩 타입으로부터의 도메인 네임의 디지털 시퀀스를 범용 언어 인코딩 타입으로 변환, (ii) 범용 언어 인코딩 타입으로부터의 도메인 네임의 디지털 시퀀스를 DNS 프로토콜과 호환가능한 DNS 인코딩 타입으로 변환하는 두 가지 동작으로 발생한다.

본 발명은 특정 언어 인코딩 타입을 특정 디지털 시퀀스와 관련시키는 매핑 테이블(mapping table)을 제공한다. 상기 매핑 테이블은 각각이 (a) 디지털 방식으로 표현된 도메인 네임의 사전-설정부의 공지된 디지털 시퀀스, (b) 공지된 디지털 시퀀스와 관련되는 언어 인코딩 타입의 속성을 포함하는 다수의 레코드를 포함한다. 디지털 방식으로 표현된 도메인 네임의 사전-설정부는 도메인 네임의 루트 레벨 도메인의 디지털 시퀀스가 될 수 있다. 레코드는 레코드내의 언어 인코딩 타입의 최상위-레벨 도메인을 도출하는 데 신뢰할 수 있는 최상위-레벨 DNS 서버도 포함할 수 있다. 또한, 매핑 테이블은 비-DNS 인코딩 타입으로부터의 도메인 네임을 DNS를 따르는 인코딩 타입(예를들면, UTF-5)으로 변환하는 데 필요한 변환 타입을 지정할 수 있다.

본 발명은 (a) 하나 이상의 프로세서, (b) 하나 이상의 프로세서중 적어도 하나와 연결되는 메모리, 및 (c) 비-DNS 인코딩 타입의 도메인 네임을 포함하는 DNS 요구를 우선 수신하며, DNS 프로토콜과 호환가능한 DNS 인코딩 타입의 도메인 네임을 갖는 DNS 요구를 전송할 수 있는 하나 이상의 네트워크 인터페이스의 장치에 의해 특성화될 수 있는 장치에 관한 것이다. 하나 이상의 프로세서중 적어도하나는 비-DNS 인코딩 타입의 도메인 네임을 DNS 인코딩 타입의 도메인 네임으로 변환하도록 설계되거나 구성된다. 하나 이상의 네트워크 인터페이스는 장치가 비-DNS 인코딩 타입의 도메인 네임을 나타내는 클라이언트 DNS 요구를 수신하도록 하는 방식으로 네트워크에 연결되어야 한다. 또한, 하나 이상의 네트워크 인터페이스는 장치가 DNS 인코딩 타입의 도메인 네임을 나타내는 DNS 요구를 표준 DNS 서버에 전송하도록 하는 방식으로 네트워크에 연결되어야 한다.

또한, 상기 장치는 메모리상에 적어도 일부분이 존재하는 (상기된 것들 중의 하나와 가능한 한 유사한) 매핑 테이블을 포함하는 것이 바람직하다. 또한, 적어도 하나의 프로세서는 비-DNS 인코딩 타입으로부터의 도메인 네임을 DNS 인코딩 타입으로 변환하기 전에 도메인 네임의 비-DNS 인코딩 타입을 식별하도록 구성되거나 설계되어야 한다.

상기된 내용 및 그 외 장치 및 본 발명의 잇점은 도면을 참고하여 보다 상세히 후술될 것이다.

도 1은 DNS 서버와 클라이언트 사이에 위치한 iDNS 서버를 포함하는 네트워크 구조의 개념도.

도 2는 본 발명의 일실시예에 따라서, 비-DNS 인코딩 타입의 도메인 네임에 대한 DNS 요구의 도출을 예시하는 과정 흐름도.

도 3A는 비-DNS 인코딩 타입의 도메인 네임을 해당 DNS 인코딩 타입의 도메인 네임으로 변환시키기 위한 프로세스를 예시하는 과정 흐름도.

도 3B는 iDNS 시스템의 논리적 구성요소를 도시하고 있다.

도 4는 도메인 네임의 인코딩 타입을 결정하기 위한 과정을 예시하는 과정 흐름도.

도 5는 본 발명의 일실시예에 따라서 도메인 네임의 인코딩 타입을 식별하는 데 사용되는 논리적 매핑 테이블을 도시하고 있다.

도 6은 중국어 인코딩의 계층을 예시하는 "트리" 다이어그램.

도 7은 본 발명의 iDNS 기능을 수행하는 데 채용될 수 있는 범용 컴퓨터 시스템의 블럭 다이어그램.

- 도면중 주요 부분에 대한 부호의 설명 -

12: 클라이언트 16: 국제 도메인 네임 시스템(iDNS) 서버

18: DNS 서버

1. DNS 및 유니코드

본 발명은 다언어 다중스크립트 이름을 DNS(예를들면, 1999년의 RFC1035에 기술되어 있는 DNS)에 따르는 형태로 변환한다. 이후에 이러한 변환된 이름은 통상적인 DNS 서버에 DNS 질의(query)로서 중계될 수 있다. 지역 도메인 네임이 숫자로 된 IP 주소로 어떻게 도출되는 지의 예시적인 처리가 후술되는 도 1에 의해 도시된다. 하지만, 도 1이 기술되기 이전에, 기초가 되는 약간의 원리 및 용어가기술될 것이다.

프로그램은 이진 네트워크 주소에 의해 호스트 및 기타 자원을 참조하지 않는다. 이진수 대신에, www.pobox.org.sg와 같은 ASCII 문자열을 사용한다. 그럼에도 불구하고, 네트워크는 이진 주소만을 인식하며, 그래서 어떤 장치는 ASCII 문자열을 네트워크 주소로 전환하는 것이 요구된다. 이러한 장치는 도메인 네임 시스템에 의해 제공된다.

DNS의 요소에는 계층적, 도메인-기초 네이밍 기구(domain-based naming scheme) 및 이러한 네이밍 기구를 실행하기 위한 분산 데이터베이스 시스템이 있다. 그것은 주로 호스트 이름 및 전자우편 수신지를 IP 주소에 매핑하는 데 사용되지만, 그 이외의 목적에도 사용될 수 있다. 상기한 바와 같이, DNS는 RFC 1034 및 1035에 규정되어 있다.

간단히 말해서, DNS가 사용되는 방식은 다음과 같다. 도메인 네임을 IP 주소에 매핑하기 위해서, 응용 프로그램은 "리졸버(resolver)"라 불리는 라이브러리 프로시저를 호출하여, 그것에 파라미터로서 상기 이름을 통과시킨다. 상기 리졸버는 UDP 패킷을 지역 DNS 서버에 전송하고, 상기 이름을 조사하여 IP 주소를 리졸버에 반환하고, IP 주소를 호출자에게 회신한다. IP 주소를 가지고, 상기 프로그램은 수신지에 TCP 연결을 설정하거나 UDP 패킷을 전송할 수 있다.

개념적으로, 각각의 도메인이 많은 호스트를 포함하는 경우, 인터넷은 많은 최상위-레벨 "도메인"으로 분할된다. 각각의 도메인은 서브-도메인으로 분할되며, 이러한 서브-도메인은 보다 더 분할된다. 이러한 모든 도메인은 트리에 의해 표시될 수 있다. 트리의 말단이란 서브-도메인을 갖지 않는 도메인을 나타낸다(하지만 장치는 물론 포함한다). 말단 도메인(leaf domain)은 단일 호스트를 포함하거나 수 천개의 호스트를 포함하는 회사를 나타낼 수 있다.

최상위-레벨 도메인에는 포괄(generic) 및 국가(country)의 2 가지 속성이 있다. 포괄 도메인에는 com(상용), edu(교육단체), gov(미국연방 정부단체), int(국제기구), mil(미국 3군), net(네트워크 제공자), 및 org(기관)이 있다. 국가 도메인은 ISO3166에 규정되어 있는 바와 같이, 매 국가당 하나의 엔트리(entry)를 포함한다. 각각의 도메인은 그것으로부터 지정되지 않은 루트로의 상향 경로에 의해서 명명된다. 각 구성요소는 점("도트"라고 발음함)에 의해 분리된다.

주로, 도메인은 2가지 다른 방식으로 트리에 삽입될 수 있다. 예를들면, cs.ucb.edu는 cs.ucb.ct.us와 같이 미국의 국가 도메인하에 동일하게 목록화될 수 있다. 하지만, 실제적으로 미국내의 거의 모든 기관은 포괄 도메인하에 존재하며, 미국외의 거의 모든 기관은 그들 국가의 도메인하에 존재한다. 2개의 최상위-레벨 도메인하에 등록하지 않을 수도 있지만, 그렇게 하는 것은 혼란을 야기해서, 그렇게 하는 기관은 거의 없다.

각 도메인은 2개의 최상위-레벨 도메인하에서 도메인을 할당하는 방법을 통제한다. 예를들면, 일본은 edu 및 com을 반영하는 ac.jp 및 co.jp 도메인을 갖는다. 새로운 도메인을 만들기 위해서는, 새로 만들어질 도메인이 포함될 도메인의 허가가 필요하다. 예를들면, 인공지능 그룹이 버클리에 소재한 캘리포니아 대학교(university of California ar Berkeley)에서 시작되어 ai.cs.ucb.edu로 알려지기를 원한다면, cs.ucb.edu를 관리하는 자들로부터의 허가가 필요하다. 유사하게, 신규 대학, 예를들면, 유니버시티 오브 레이크 태호가 설립되는 경우, edu 도메인의 관리자에게 ulth.edu를 할당해 주도록 요청해야 한다. 이런 식으로 해서, 이름 충돌을 피하게 되고 각각의 도메인은 그것의 모든 서브-도메인의 트랙을 유지할 수 있다. 새로운 도메인이 만들어지고 등록되면, 트리의 상위 독립체로부터 허가를 받지않고, cs.ulth.edu와 같은 그것에 속하는 서브-도메인을 만들 수 있다.

이론적으로, 적어도, 단일 이름 서버는 전체 DNS 데이터베이스를 포함하며, 그것에 관한 모든 질의에 반응할 수 있다. 실제적으로, 이러한 서버는 과부하되어 무용지물이 될 수 있다. 또한, 서버가 고장나는 경우, 전체 인터넷이 무력화된다. 정보의 단일 소스만을 갖는 것과 관련되는 문제를 피하기 위해서, DNS 이름 공간은 비-중첩 "영역(zone)"으로 분할된다. 각 영역은 트리의 일정 부분을 포함하고, 그 영역에 관한 믿을 만한 정보를 보유하는 이름 서버도 포함한다. 보통 한 영역은 서버 디스크 상의 화일로부터 정보를 얻는 하나의 주 이름서버(primary name server), 및 주 이름 서버로부터 정보를 얻는 하나 이상의 보조 이름서버(secondary name server)를 갖게 된다.

리졸버가 도메인 네임에 관한 질의를 받게 되면, 리졸버는 그 질의를 지역 이름서버들 중 하나로 보낸다. 그 도메인이 cs.ucb.edu하의 ai.cs.ucb.edu와 같이 상기 이름서버의 관할권 하에 있는 것으로 밝혀지면, 그것은 권한이 있는 자원 레코드로 복귀한다. 권한이 있는 레코드는 상기 레코드를 관리하는 권한으로부터 나오는 것으로, 항상 표준에 부합한다. 일정 이름서버는 구식이 될 수 있는 "캐쉬 레코드(cached records)"도 포함할 수 있다.

관심있는 도메인이 원격상에 있으며, 요구되는 도메인에 관한 정보가 지역적으로 이용할 수 없는 경우, 상기 이름서버는 요구되는 도메인에 대한 최상위-레벨 이름서버에 질의 메시지를 보낸다. 예를들면, ac.cs.ucb.edu에 대한 IP 주소를 검색하고 있는 지역 이름서버는 그것의 데이터베이스 내에서 주어지는 edu에 대한 서버인 edu-server.net에 UDP 패킷을 보낼 수 있다. 그가 속한 모든 자식(children) 이름서버를 알아야 하는데, 이러한 서버가 ac.cs.ucb.edu의 주소를 알면서, 아마 cs.ucb.edu를 모른다는 것은 있을 수 없으므로, 서버는 ucb.edu에 대한 이름서버에 요구를 전송한다. 교대로, 상기 이름서버는 권한이 있는 자원 레코드를 가져야만 하는 cs.ucb.edu에 요구를 전송한다. 각 요구는 클라이언트로부터 서버에 행해지기 때문에, 요구되는 권한이 있는 레코드는 ai.cs.ucb.edu에 대한 IP 주소를 요구하는 원래 이름서버에 복귀된다.

레코드가 원래 이름서버에 복귀되면, 그것이 이후에 필요하게 되는 경우 그것은 캐쉬에 들어가게 된다. 하지만, 이러한 정보는 cs.ucb.edu에서 행해지는 변화가 그것에 관해 알 수 있는 전세계의 모든 캐쉬에 전달되지 못하기 때문에 공인되지 않는다. 이러한 이유로 해서, 캐쉬 엔트리는 자주 제거되거나 갱신되어야 한다. 이것은 각 레코드에 포함되는 "살 수 있는 시간(time_to_live)"필드에서 수행될 수 있다.

도메인 네임을 도출하기 위한 방법의 상기 예는 재귀적 질의(recursivequerying)로 언급된다. 그 외의 기술들도 존재한다. DNS에 대한 보다 상세한 내용을 알고자 한다면, 상기 내용의 상당 부분이 채택된 뉴저지, 업퍼 새들 리버에 위치한 프렌티스 홀(Prentice Hall)에서 1996년에 편찬한 앤드류 에스. 태넨바움에 의한 "컴퓨터 네트워크" 3판을 참조하시오. 또한, 캘리포니아, 샌 프란시스코에 위치한 맥그로-힐(McGraw-Hill)에서 1998년에 편찬한 유.디. 블랙에 의한 "TCP/IP 및 관련 프로토콜" 3판을 참고하시오. 두 개의 이들 참고문헌은 여기에 참고로 도입되었다.

지적된 바와 같이, DNS 프로토콜은 현재 ASCII의 서브세트에 기초된 것으로, 라틴 알파벳에 제한된다. 그 외의 다수의 인코딩은 세상의 다른 문자 세트를 위한 디지털 표시를 제공한다. 예에는 한자 스크립트(통상적인 및 간략화된 한자에 대해) 용으로 BIG5 및 GB-2312, 일본 문자 스크립트용으로 Shift-JIS 및 EUC-JP, 한글 스크립트용으로 KSC-5601, 및 이를테면 프랑스 및 독일 문자용으로 확장 ASCII 문자가 포함된다.

이들 특정-언어 인코딩 타입을 넘어서, 세계의 문어에 사용되는 모든 문자를 인코딩할 수 있는 유니코드 표준("범용 언어 인코딩 타입")이 존재한다. 유니코드 표준은 65,000자 이상에 대한 코드 점(code point)을 제공하는 16-비트 인코딩을 사용한다. 유니코드 스크립트는 라틴, 그리스, 키릴, 마르메니아, 히브리, 아라비아, 데바나가리(Devanagari), 벵골, 구르무키(Gurmukhi), 오리야(Oriya), 타밀, 테루구(Telugu), 칸나다(Kannada), 말라야람, 티아, 라오, 그루지야, 티벳, 일본 가나, 현대 한글의 완성형, 및 중국/일본/한국(CJK) 한자의 통합형을 포함한다. 보다 많은 스크립트 및 문자에는 에티오피아, 캐나다, 실라빅(Syllabics), 체로키, 드룰게 추가되는 표의문자, 신하라(Sinhala), 시리아, 버마, 크메르 및 브라이유 점자가 곧 추가 될 예정이다.

단일 16-비트 수는 유니코드 표준에 의해 규정되는 각 코드 요소에 할당된다. 이들 16-비트 수 각각은 코드 값으로 불리며, 텍스트에서 언급될 경우, 접두어 "U"뒤에 16진수 형태로 나열된다. 예를들면, 코드값 U+0041은 16진수 0041(10진수 65와 동일함)이다. 유니코드 표준에서 문자 "A"를 나타낸다.

각 문자는 그것만을 지정하는 유일한 이름으로 할당된다. 예를들면, U+0041에는 "라틴 대문자 A"의 문자 이름이 할당된다. U+0A1B는 "구르무키 문자 CHA"의 문자 이름이 할당된다. 이들 유니코드 이름은 동일문자에 대한 ISO/IEC 10646 이름과 일치한다.

유니코드 표준은 코드 블럭내의 스크립트에 의해 문자를 서로 그룹별로 분류한다. 상기 표준은 가능한 소스 세트내의 문자 순서를 유지한다. 스크립트의 문자가 어떤 순서-알파벳 순서로 통상적으로 배열되는 경우, 예를들면 유니코드 표준은 가능한 한 언제라도 동일한 순서를 사용해서 코드공간에 그들을 배열한다. 코드블럭은 사이즈가 크게 변한다. 예를들면, CJK 코드블럭은 수 천개의 코드값의 범위를 갖는 반면, 키릴 코드블럭은 256 코드값을 초과하지 않는다.

코드요소는 "코드공간(codespace)"으로 불리는 코드값 범위를 통해 논리적으로 분류된다. 상기 코딩은 표준 ASCII 문자를 U+0000에서 시작하여, 그리스, 키릴, 히브리, 아라비아, 인도 및 그외 스크립트로, 이후 기호 및 구두점으로 계속된다. 상기 코드공간은 히라가나, 가타가나 및 보포모포(Bopomofo)로 계속된다. 코드값의 대용범위는 UTF-16으로 장래의 확장성을 확보하고 있다. 코드공간의 종단부는 개인적 이용을 위해 확보된 코드값의 범위이며, 이후 호환문자의 범위가 이어진다. 호환문자는 초기 표준 및 그들을 이용하는 이전 실행으로의 트랜스코딩 (transcoding) 할 수 있도록만 인코딩되는 변형문자이다.

문자 인코딩 표준은 각 문자 및 그 수치의 동일성 또는 코드위치 뿐만 아니라 이러한 값이 어떻게 비트로 표현되는 지를 규정한다. 유니코드 표준은 ISO 10646 변환포맷에 해당되는 적어도 ISO/IEC 10646 변환포맷 UTF-7, UTF-8 및 UTF-16은 인코딩을 실행시 사용되는 실제적인 비트로 변환시키는 근본적인 방법이다. UTF-16은 16-비트문자를 가정하여, 16-비트 문자쌍을 사용하여 추가적인 수 백만 문자에 접근하도록 어떤 문자의 범위에 대해 확장장치로서 사용되도록 한다. 1996년 애디슨 웨슬리 롱맨의 유니코드 표준, 버젼 2.0("유니코드 표준, 버젼 2.1로 업데이트 및 추가됨)은 ISO/IEC 10646에서 규정되는 본 변환포맷에 채용되었다. 이 참고문헌은 그 전체가 참고로 여기에 도입되었다.

제 2 변환포맷은 UTF-8로서 알려져 있다. 이것은 모든 유니코드 문자를 바이트의 가변길이 인코딩으로 변환하는 방식이다. 통상적인 ASCII 세트에 해당하는 유니코드 문자는 ASCII와 동일한 바이트 값을 갖도록 끝내고, UTF-8로 변환된 유니코드 문자는 광범위한 소프트웨어 수정없이 기존의 소프트웨어에서 사용될 수 있다는 잇점을 갖고 있다. 유니코드 협회도 유니코드 표준을 실행하는 방법으로서 UTF-8의 사용을 보증한다. 16-비트 UTF-16 형태로 표현되는 어떠한 유니코드 문자는 UTF-8 형태로 변환될 수 있으며, 정보의 손실없이 복귀될 수 있다. 유니코드 표준은 그것을 실시하는 규칙 및 인코딩 구조에 관하여 일치를 위한 명확한 요구사항을 지정한다. 순응실시(conforming implementation)는 최소 요구사항으로서 다음의 특성을 갖는다.

문자는 16-비트 단위이다.

문자는 유니코드 의미론으로 해석된다.

비할당 코드는 사용되지 않는다.

알려지지 않은 문자는 전와(corrupt)되지 않는다.

유니코드 표준의 UTF-8 실시는 유니코드 문자가 16-비트 단위에 해당하고, 유니코드 명세에 따라 문자를 해석하지 않는 경우 유니코드 표준의 UTF-8 실시가 유니코드 문자의 각각의 UTF-8 인코딩(바이트 순서)을 처리하는 한 순응한다. 완전 순응 요구사항은 참고로 도입된 1996년의 애디슨 웨슬리 롱맨의 유니코드 표준내에서 유효하다. UTF-7은 7비트 매체/전송에 실용적인 7비트 문자를 제공하도록 설계되었다. 예를들면, RFC 822에 지정되는 전자우편은 7비트 시스템이다. UTF-16은 16비트 매체/전송용으로 설계되었으며, UTF-8은 8비트 매체/전송용으로 설계되었다. 대부분의 인터넷은 8비트를 전송할 수 있으나, 7비트를 사용하는 유산 시스템(예를들면, DNS, SMTP 전자우편 등)도 존재한다.

2. 용어

여기에 사용되는 용어중 일부는 본 기술분야에서 통상적으로 사용되는 것이 아니다. 다른 용어는 본 기술분야에서 다수의 의미를 갖는다. 따라서, 아래의 정의는 후술되는 내용을 이해하는 데 도움이 되도록 제공된다. 청구항에서 기술되는 발명이 이들 정의에 제한되어서는 안된다.

언어 인코딩 타입(Linguistic encoding type) - 현재 공지되어 있거나 장래에 사용될 어떠한 문자 또는 그림문자 인코딩 타입(예를들면, ASCII 또는 BIG5).

범용 언어 인코딩 타입 - 현재 공지되어 있거나 장래에 개발될, 인코딩 내에 하나 이상의 문자 또는 그림문자를 포함하는 어떠한 언어 인코딩 타입. 유니코드는 한 예이다. 그 외에 BIG5, ISO-8859-11, 및 GB-2312가 있다.

디지털 방식으로 표현됨(Digitally represented) - 문자가 인코딩의 결과로 표현되는 방식(예를들면, 비트열, 16진수 포맷 등)

디지털 시퀀스(Digital sequence) - 1 과 0, 16진수 문자, 또는 그외 구성 요소들(디지털 방식으로 표현됨)로 이루어진 특정 시퀀스.

디지털 방식으로 표현된 도메인 네임중 "일부(Portion)" - 도메인 네임의 어느 부분 또는 전체; 예를들면, 최상위-레벨 도메인, 제 2레벨 도메인, 및 상위 및 제 2레벨 도메인.

"공지된(Known)" 디지털 시퀀스 - 특정 인코딩 타입(예를 들면, ".com"에 대한 BIG5디지털 시퀀스)으로 인코딩된 일반적으로 사용되는 몇 가지의 문자 조합(또는 도메인 네임의 그외 특성)과 연관된 것으로 알려진 디지털 시퀀스.

공지된 디지털 시퀀스의 "콜렉션(Collection)" - 다수의 공지된 디지털 시퀀스들의 배열 또는 다수의 공지된 디지털 시퀀스들 간의 연결. 통상적으로, 테이블(예를 들면, 여기서 기술되는 "매핑 테이블") 형식으로 저장됨.

DNS 인코딩 타입(DNS encoding type) - 네트워크 또는 인터넷의 DNS 프로토콜에 의해 제공되는 인코딩 타입으로 예를들면, RFC 1035에서 지정되는 ASCII의 한정 세트.

비-DNS 인코딩 타입(Non-DNS encoding type) - 고려되는 것 하에서의 DNS 프로토콜에 의해 제공되지 않는 인코딩 타입으로 예를들면, RFC 1035하에서의 BIG5.

3. iDNS의 실시예

도 1에 있어서, 본 발명의 실시예에 사용되는 네트워크(10)의 중요한 구성요소는 클라이언트(12), 상기 클라이언트(12)가 통신하고자 하는 해당 노드(14), iDNS 서버(16), 및 통상적인 DNS 서버(18)를 포함한다. 상기 iDNS 서버(16)는 폴 빅시(Paul Vixie)(http://www.isc.org/)에 의해 작성되어 널리 사용되는 DNS 서버인 버클리 인터넷 이름 도메인('BIND' 및 그의 실시가능 버젼인 'named')을 포함하는 통상적인 DNS 서버를 대신해서 다언어 도메인 네임 질의에 대한 DNS 포트(일반적으로 도메인 네임 포트(53)에 주소 지정되어 있음)를 주시한다.

이러한 장치들의 역할을 이해하기 위해서, 클라이언트(12)가 해당 노드(14)를 관리하는 홍콩 상사에 취업과 관련하여 알아보고자 하는 중국 학생에 의해 사용되고 있다고 가정한다. 학생은 상사와 이전에 연락하여 그 상사의 도메인 네임을 얻었다. 도메인 네임은 한자로 제공되었다. 클라이언트(12)는 한자를 타이핑할 수 있는 키보드가 준비되어 있고 인코딩된 한자를 인식할 수 있는 소프트웨어가 갖춰져 있으며 그것을 컴퓨터 스크린상에 정확히 표시한다.

그리고, 학생은 홍콩상사에 전송할 메시지를 작성하고 그녀의 이력서를 첨부하여 수신지에 해당하는 도메인 네임을 한자로 타이핑한다. 그녀는 클라이언트(12)가 상기 메시지를 해당 노드(14)에 전송하라고 명령할 때, 도 1에 도시된 시스템은 다음의 동작을 취한다. 우선, 해당 노드 도메인 네임은 모국어로 DNS 요구를 통해 iDNS 서버에 보내진다. iDNS 서버(16)는 도메인 네임이 통상적인 DNS 서버에 의해서 처리될 수 있는 포맷이 아닌 지를 인식한다. 따라서, iDNS 서버는 통상적인 DNS 서버가 중국어 도메인 네임을 통상적인 DNS 서버에서 사용될 수 포맷(ASCII 문자의 표준적 제한 세트)으로 변환한다. 이후에 iDNS 서버(16)는 변환된 해당 노드 도메인 네임를 갖는 DNS 요구를 재패키지하여, 상기 요구를 통상적인 DNS 서버(18)로 전송한다. 이로써 DNS 서버(18)는 정상적인 DNS 프로토콜을 이용하여 DNS 요구에서 수신된 도메인 네임에 해당되는 네트워크 주소를 얻는다. 결과 네트워크 주소는 해당 노드(14)의 네트워크 주소가 된다. DNS 서버(18)는 통상적인 DNS 프로토콜에 따른 네트워크 주소를 패키지하여 iDNS 서버(16)에 주소를 반환 전송한다. 이후에 iDNS 서버(16)는 요구되는 네트워크 주소를 학생의 메시지가 놓여있는 클라이언트(12)에 반환 전송한다. 상기 메시지는 해당 노드(14)의 수신지 네트워크 주소를 갖는 각각의 패킷으로 패킷화된다. 이후 클라이언트(12)는 노드(14)를 통해 인터넷상으로 메시지 패킷을 전송한다.

이러한 과정은 도 2의 대화식 처리 흐름도에 기술된 작동을 고려함으로써 보다 완전히 이해될 수 있다. 도 2에 도시된 바와 같이, 클라이언트(12)는 도면의 좌측에 수직선으로 표현되고, iDNS 서버(16)는 도면의 중앙의 수직선으로 표현되며, DNS 서버(18)는 도면의 우측의 수직선으로 표현된다.

우선, 도면부호 203에서 클라이언트(12) 상에서 실행중인 응용 프로그램은 네트워크 수신지로 보낼 메시지를 만든다. 상기 수신지에 대한 도메인 네임은 비-DNS 호환 텍스트 인코딩 포맷의 입력이다. 따라서, 상기 텍스트는 텍스트의 문자를 디지털 방식으로 표현하는 언어 인코딩 타입으로 인코딩된다. 언급된 바와 같이, ASCII는 단지 하나의 언어 인코딩 타입에 불과하다. 바람직한 실시예에 있어서, 본 발명은 광범위한 인코딩 타입을 처리한다. 광범위하게 사용되는 예에 는 GB2312, BIG5, Shift-JIS, EUC-JP, KSC5601, 확장 ASCII, 및 그 이외의 것들을 포함한다.

클라이언트 응용 프로그램이 203에서 메시지를 만든 후, 클라이언트 운영 시스템은 205에서 도메인 네임을 도출하기 위한 DNS 요구를 발생시킨다. 상기 DNS 요구는 대부분에 있어서 통상적인 DNS 요구와 유사하다. 하지만, 상기 요구에서 제공되는 도메인 네임은 비-DNS 인코딩 포맷으로 제공된다. 클라이언트 운영시스템은 207에서 그의 DNS 요구를 iDNS 서버(16)에 전송하도록 구성될 수 있음에 유의하라. 다시 말해서, 클라이언트(12)의 기본 DNS 서버는 iDNS 서버(12)이다.

iDNS 서버(16)는 DNS 요구로부터 인코딩된 도메인 네임을 추출하여 호환가능한 DNS 인코딩 포맷(현재 RFC1035에 규정된 간략화된 ASCII 세트)의 도메인 네임을 표시하는 변형된 DNS 요구를 발생시킨다(도면부호 '209'를 참조). 이후에 iDNS 서버(16)는 그의 DNS 요구를 통상적인 DNS 이름 서버(18)로 전송한다(도면부호 '211'을 참조). 이후에 상기 이름서버는 통상적인 DNS 서버를 이용하여 클라이언트의 통신에서 사용되는 도메인 네임의 IP 주소를 획득한다(도면부호 '213'을 참조).이후, 도면부호 215에서, 이름서버는 iDNS 서버에 요구된 IP 주소를 반환 전송한다. 마지막으로, 수중에 IP 주소를 획득한 클라이언트(12)는 지정된 수신지로 그의 통신을 전송한다(도면부호 '219'를 참조).

상기된 바와 같이, 도메인 네임은 비-DNS 인코딩 타입으로부터 호환가능한 DNS 인코딩 타입으로 변환되어야 한다. 상기 실시예에 있어서, 이러한 인코딩 타입의 변환은 프록시(proxy) iDNS 서버로 수행된다. 하지만, 이것은 변환에 필요한 기능성이 클라이언트 또는 통상적인 DNS 서버에서도 실시될 필요는 없다.

다른 실시예에 있어서, 프록시 iDNS 서버에 의해서 수행되는 기능은 클라이언트 상에서 및/또는 DNS 서버 상에서 전체적으로(또는 부분적으로) 수행된다. 일실시예에 있어서, 인코딩 타입을 검출하는 단계, 비-DNS 인코딩 도메인을 DNS 인코딩 도메인 네임으로 변환하는 단계 및 기본 이름서버 식별하는 단계를 포함하는 동작(후술되는 도3A의 흐름도의 305-311 동작)은 인터넷 응용 프로그램(예를들면, 다언어-가능 웹 브라우저) 상에서 실행된다. 이러한 실시예에 있어서, 코드검출 및 코드변환은 DNS 서버로 DNS 도출 요구를 디스패칭(dispatching)하기 전에 자동적으로 종료된다. 어떠한 실시예에 있어서, 응용 프로그램은 코드검출에 대한 요구를 방지하는 한정된 언어 인코딩을 수동으로 제공할 수 있다.

또 다른 실시예에 있어서, 동작(305-311)은 iDNS 서버 상에서 실시될 수 있다. 다른 실시예는 프록시 iDNS의 동작의 전부 또는 일부를 DNS 서버로 포개는 것을 포함한다. 예를들면, 어떠한 iDNS 기능에 대한 코드가 컴파일 가능한 모듈인 BIND 코드로 포개질 수 있다.

도 2에 있어서, 제 1언어 인코딩 타입으로부터 제 2언어 인코딩 타입(DNS와 호환가능)으로의 도메인 네임의 변환은 209에서 수행된다. 도 3A에 도시된 바와 같이, 본 발명의 바람직한 실시예에 따라서, 이러한 변환은 과정(301)을 통해서 발생한다. 상기 과정은 DNS 요구에서 도메인 네임의 인코딩 타입을 식별하는 시스템을 가지고 303에서 시작한다. 이것은 상기 시스템이 다수의 다른 인코딩 타입과 직면하게 되는 경우 필요하다. 인코딩 타입이 식별된 후, 다음에 시스템은 도메인 네임이 호환가능한 DNS 인코딩 타입으로 인코딩되었는 지의 여부를 305에서 결정한다. 일반적으로, 그것은 도메인 네임이 간략화된 ASCII 인코딩 타입으로 인코딩되었는 지의 여부를 결정하는 것을 필요로 한다. 만일 그렇다면, 추가 변환은 불필요하며 처리제어는 후술될 311로 연결된다.

관심있는 경우로, 도메인 네임이 비-DNS 포맷으로 인코딩되어 있다. 이러한 경우, 처리제어는 상기 시스템이 도메인 네임을 범용 인코딩 타입으로 변환하는 307로 연결된다. 바람직한 실시예에 있어서, 상기 범용 인코딩 타입은 유니코드이다. 이러한 경우, 본래의 인코딩 타입으로 식별된 문자는 유니코드 표준으로 식별되고 그러한 문자에 대한 유니코드 디지털 시퀀스로 변환된다.

최근 번역된 도메인 네임은 이후에 범용 인코딩 타입으로부터 호환가능한 DNS 인코딩 타입으로 추가 변환된다(도면부호 '309'를 참조). 따라서, 이러한 최종 인코딩 타입은 간략화된 ASCII 세트가 된다. DNS 비호환 포맷으로부터 DNS 호환포맷으로의 변환이 중간 범용 인코딩 타입을 통해 두 단계로 발생함을 유의하라. 이하, 이러한 두 단계 처리를 후술한다. 하지만, DNS 비호환 도메인 네임을 호환가능한 DNS 도메인 네임으로 한 단계로 직접 변환하는 것이 가능할 수 있음이 인지되어야 한다. 이것은 각 단계가 특정 인코딩 타입을 ASCII(또는 장래에 호환가능한 다른 DNS 인코딩 타입)로 변환하도록 설계된 것을 다수의 변환 알고리즘을 갖는 시스템에서 수행될 수 있다. 일실시예에 있어서, 이러한 알고리즘은 상기된 "듀르스트 알고리즘"에 따라서 모델링될 수 있다. 적절한 다수의 기타 알고리즘은 공지되어 있거나, 일상적인 노력으로 개발될 수 있다.

호환가능한 DNS 도메인 네임을 가진 상태에서, 시스템은 통상적인 DNS 이름 서버로 도메인 네임을 전송해야 하는 지를 결정하는 것만을 필요로 한다. 정상적인 DNS 프로토콜에 따라서, DNS 요구는 최상위-레벨 이름 서버로 전송될 수 있다. 보다 상세히 후술되는 바와 같이, 다른 루트 이름서버는 다른 언어 도메인으로 처리되도록 하는 것이 편리하다. 예를들면, 중국 정부는 중국어 도메인 네임에 대한 루트 이름 서버를 유지할 수 있고, 일본 정부 또는 일본 법인은 일본어 도메인 네임에 대한 루트 이름 서버를 유지할 수 있고, 인도 정부는 힌디어 도메인 네임에 대한 루트 이름 서버를 유지할 수 있다. 어떤 경우에 있어서, 시스템은 도 3A에 도시되어 있는 바와 같이, 311에서 적절한 도메인 서버를 인식해야 한다. 이것이 수행된 이후 변환과정은 완성되며, DNS 요구는 변환에 따라 처리되도록 DNS 시스템에 전송될 수 있다.

바람직하게, 도 3A에 도시된 과정은 iDNS 서버상에서만 수행된다. 하지만, 과정중 일부는 클라이언트 또는 통상적인 DNS 서버상에서 수행될 수 있다. 예를들면, 303 및 305는 클라이언트 상에서 수행되며 309는 통상적인 DNS 서버상에서 수행될 수 있다.

iDNS 기능(327)에 대한 노동의 바람직한 분할은 도 3B에 도시되어 있다. 도 3B에 도시된 바와 같이, iDNS 매퍼 서버(321)는 305-311 동작을 수행한다. 이 때문에, iDNS 매퍼 서버는 매핑 테이블(도 5와 관련하여 후술되는 예)을 포함하며 모든 언어 인코딩 타입을 유니코드(또는 다른 적절한 범용 인코딩 타입)로 변환할 수 있다. 이러한 실시예에 있어서, 클라이언트(325)는 동작(303)을 수행하고 통상적인 DNS 서버(323)는 표준 DNS 도출 프로토콜을 수행한다.

일실시예에 있어서, iDNS 매퍼 서버(321)는 지정 포트(예를들면, 포트 넘버 2000)상의 기계(예를들면, i2.i-dns.com에 의해 정의됨)상에서 실행된다. iDNS 매퍼 서버는 디지털 방식으로 표현된 어떠한 언어 인코딩 타입의 도메인 네임의 전부를 받아서 DNS 인코딩 타입(UTF-5)으로 변환된 디지털 방식으로 표현된 유니코드의 도메인 네임의 전부를 반환한다. 매핑 테이블 및 변환 프로그램 코드가 매우 커서(거기서 실시된다면) DNS 서버(323)의 사이즈를 몇 배로 증가시킬 수 있음을 유의하라. DNS 프로토콜로부터 동작(305-311)을 분리하여 개별적으로 그것을 실행시킴으로써, iDNS를 분산시키는 데 필요한 코드의 양은 감소하게 된다.

도 3A의 토의에 기술되어 있는 바와 같이, 시스템이 다수의 인코딩 타입을 처리해야 하는 경우, 시스템은 하나의 인코딩 타입을 다른 것과 구별할 수 있어야 한다. 이러한 과정은 블럭(303)에 도시되어 있으며 도 4에서 상세히 기술된다.

도 4에 도시되어 있는 바와 같이, 인코딩 타입을 식별하는 과정(401)은 도메인 네임의 최상위-레벨 도메인의 디지털 시퀀스를 식별하는 시스템을 갖는 403에서시작한다. 1999년 3월의 시스템에 있어서, 최상위-레벨 도메인은 .com, .edu, .gov, .mil, .org, .int, .net 및 두 글자의 다양한 국가 수신지(예를들면, .fr, .sg, .kr 등)를 포함한다.

최상위-레벨 도메인의 디지털 시퀀스가 인식된 후, 시스템은 다음에 상기 시퀀스를 특정 인코딩 타입과 매칭시킨다. 바람직한 실시예에 있어서, 이것은 405에서 매핑 테이블의 레코드에 대해 디지털 시퀀스를 매칭시키는 것을 포함한다. 예시적인 매핑 테이블은 보다 상세히 후술될 것이다. 현재 상기 테이블(또는 다른 논리구조)은 상기 시스템에 의해 처리되는 다양한 언어 인코딩 타입의 다양한 최상위-레벨 도메인에 대한 디지털 시퀀스를 포함한다. 각각의 개별 레코드는 또한 관련 인코딩 타입 식별자를 포함한다. 상기 시스템은 (2진 서치, 하쉬 테이블(hash table), 비(B)-트리 등과 같은 표준 데이터베이스 조사 절차를 사용하는) 매핑 테이블의 다양한 레코드내의 시퀀스에 대해 그것을 단순히 비교함으로써 디지털 시퀀스를 매칭시킨다. 이것은 통상적으로 단일 매치를 제공한다. 하지만, 다수의 엔트리가 (예를들면, 다른 언어에 신뢰할 수 있는)최상위-레벨 도메인을 유출하는 데 신뢰할 수 있다면, 다른 인코딩 포맷의 두 개의 최상위-레벨 도메인에 대한 디지털 시퀀스가 동일하게 될 수 있다.

이러한 가능성을 처리하기 위해서, 상기 시스템은 407에서 다수의 레코드가 디지털 시퀀스와 일치하는 지의 여부를 결정한다. 일치하지 않는 경우, 상기 과정은 단일 매칭 레코드에서 식별된 인코딩을 사용하여 결정하는 시스템을 갖는 413에서 완성된다. 한편, 두 개 이상의 레코드가 일치하는 경우, 시스템은 이러한 모호성을 해결해야 한다. 우선 하위-레벨 도메인(예를들면, 제 2레벨 도메인과 같은 하부 도메인) 디지털 시퀀스를 인식함으로써 모호성을 해결한다(도면부호 '409'를 참조). 다시 말해서, 모호성 해결을 위한 방법으로 도메인 네임은 하위 레벨 도메인과 관련되는 디지털 시퀀스를 갖는다. 확장 디지털 시퀀스는 매핑 테이블(405)에서 디지털 시퀀스에 대해 다시 매칭된다. 테이블의 어떠한 레코드가 최상위-레벨 도메인의 시퀀스의 잠재적 모호성을 해결하기 위해서 최상위-레벨 및 하위 레벨 도메인의 조합에 대한 디지털 시퀀스를 포함할 수 있다. 405에서 일치된 것으로 밝혀진 후, 과정은 상술한 바와 같이 407을 통해 진행한다.

다른 실시예에 있어서, 최상위-레벨 도메인에 대한 디지털 시퀀스 만이 매핑 테이블에서 유지된다. 모호성 해결을 위한 확장 시퀀스에 대한 규약은 없다. 이러한 경우, 407에서 긍정으로 응답(다수의 레코드가 일치)되는 경우, 시스템은 잠재적인 각각의 일치(후보 인코딩 타입(candidate encoding type))를 인식한다. 이후에 상기 시퀀스는 각각의 잠재적인 인코딩 타입을 사용해서 디코딩된다. 예를들면, 루트 도메인 디지털 시퀀스는 일본어 인코딩 타입들 중의 하나인 .net 및 중국어 인코딩 타입중 하나인 .com과 일치하는 것으로 밝혀질 수 있다.

디코딩된 문자열들 중 하나는 후보 인코딩 타입의 언어로 인지될 수 있어야 한다. 다른 것(들)은 인지되지 않는다. 따라서, 시스템은 제 2차 도메인의 최상의 디코딩을 제공하는 후보 인코딩 타입을 선택한다. 이후에, 과정은 선택된 인코딩 타입을 사용하는 시스템을 갖는 413에서 종결된다.

도 4의 토의중 405에서 기술되어 있는 바와 같이, iDNS 서버는 도메인 네임질의의 최상위-레벨 도메인에 대한 디지털 시퀀스를 다수의 인코딩 타입을 위한 공지된 디지털 시퀀스와 매치시킬 수 있다. 매핑 테이블은 공지된 디지털 시퀀스를 수납할 수 있다. 도 5는 본 발명의 일실시예에 따른 매핑 테이블(501)을 제공한다. 테이블(501)의 각 레코드는 특정 인코딩 타입(예를들면, BIG5에 대한 .com)에 대한 최소 코드 도출 문자열(예를들면, 최상위-레벨 도메인)을 규정한다.

도시된 바와 같이, 매핑 테이블(501)은 6개의 개별 필드를 포함한다. 이들 중 제 1필드는 엔트리 캐쉬가 만료되기 이전까지의 시간이 얼마인지를 규정하는 살 수 있는 시간(time to live)이다. 다음으로, 최소 코드 도출 문자열 필드는 도메인 네임중 일부의 디지털 시퀀스(예를들면, BIG5에서 .com에 해당하는 디지털 인코딩)를 식별한다. 최소 코드 도출 문자열은 통상적으로 8비트 2진 문자열로서 제공됨을 유의하라. 테이블(501)에서 최소 코드 도출 문자열의 엔트리 및 유지를 단순화하기 위해, 변환은 도시된 형태를 취하도록 2진 문자열로 적용될 수 있다.

최소 코드 도출 문자열이 종종 최상위-레벨 도메인이 될 수는 있지만, 이것이 필요한 것은 아니다. 어떠한 언어 인코딩에 있어서, 모호성 때문에 문자열의 인코딩 타입을 유일하게 도출하도록 제 2 또는 상위 레벨 도메인을 포함하는 것이 필요할 수 있다. 유사하게, 인코딩 타입을 유일한 것으로 결정하는 데 최상위-레벨 도메인 전체를 사용하는 것이 항상 필요한 것은 아니다. 이것은 매칭에 대한 조사의 속도를 빠르게 한다.

테이블에서 지정되는 "권한"은 레코드에서 지정되는 도메인 네임 상의 권한을 나타내는 엔티티(entity)이다. 이러한 권한은 그의 권한하에 하부-도메인을 등록할 수 있다. 예를들면, "i-dns" 엔티티가 BIG5의 .com상에서 주어진 권한인 경우, 그것은 BIG5의 .com하의 모든 하부-도메인의 허가를 내주는 권한을 가질 수 있다. 이것은 오직 하나의 도메인 네임만이 승인되는 것을 보증한다. 또한, 권한은 DNS 공간의 권한부 내의 도메인 네임에 대한 IP 주소를 제공하는 "권한이 있는" 레코드를 가진 이름서버(또는 서버들)상의 통제권을 갖는 엔티티를 나타낸다. 테이블(501)의 "인코딩"필드는 레코드와 일치하는 도메인 네임의 인코딩 타입을 지정한다. "변환"필드는 도메인 네임의 최종 인코딩을 지정한다. 예를들면, UTF-5는 유니코드(후술됨)에 적용되는 듀르스트 알고리즘이다. 마지막으로, "비고"필드는 도메인 네임중 무슨 부분이 최소 코드 도출 문자열에 해당하는 지를 식별하는 텍스트 문자열을 포함한다. 도 6은 한자 도메인 네임을 도출하기 위한 예시적인 도메인 네임 트리를 도시하고 있다. 한자 인코딩 타입을 검출하는 iDNS 서버는 도메인 네임을 도출하기 위한 기본 이름 서버로 구성될 수 있다. 도 6에 도시된 바와 같이, 루트 밑에 다수의 상위-레벨 도메인(예를들면, .com, .edu, .sg 등)들이 존재한다. 최상위-레벨 도메인 .sg 밑에는, edu.sg와 같은 다수의 한자 제 2레벨 도메인이 존재하고, edu.sg 밑에는 nus.edu.sg 및 기타의 것을 포함하는 다수의 도메인이 존재한다. 유사하게, 최상위-레벨 .com 밑에는, email.com과 같은 다수의 제 2레벨 한자 하부-도메인이 존재한다.

도 3A의 실시예의 토의에 기술한 바와 같이, iDNS 시스템은 도메인 네임의 범용 인코딩 타입(예를들면, 유니코드)을 DNS 인코딩 타입으로 변환하는 것이다. 바람직한 일실시예에 있어서, 이것은 앞에서 참고로 도입된 마틴 듀르스트에 의한"도메인 네임의 국제화"라는 인터넷 드래프트에 의해 정의된 변환 알고리즘을 사용해서 수행된다. 상기 알고리즘은 가변 길이 데이터 엔티티를 RFC를 따르는 ASCII 단일 케이스 알파벳 및 숫자만으로 구성된 형태로 변환시킨다. 아래의 표는 인터넷 드래프트에서 사용되는 변형 표를 도시하는 것이다.

니블 값	초기	후속
16진수	초기	후속	2진수
0	0000	G	0
1	0001	H	1
2	0010	I	2
3	0011	J	3
4	0100	K	4
5	0101	L	5
6	0110	M	6
7	0111	N	7
8	1000	O	8
9	1001	P	9
A	1010	Q	A
B	1011	R	B
C	1100	S	C
D	1101	T	D
E	1110	U	E
F	1111	V	F

마지막 두 열이 RFC1035를 따르는 ASCII 문자로 해석될 것인데 반해 상기 표의 처음 두 열은 2진수(또는 16진수) 값으로 해석된다. '초기' 및 '후속'은 각각 데이터 엔티티의 초기 니블(1/2 바이트) 및 데이터 엔티티의 나머지 부분을 의미한다. 데이터 엔티티가 2바이트 길이인 경우 (USC-2의 경우에서와 같이), 특정 데이터 엔티티는 4 니블이 된다.

상기된 바와 같이, 다언어 도메인 네임을 도출하기 위해, 클라이언트 응용 프로그램은 다언어 비-RFC를 따르는 질의를 iDNS 프록시 서버에 보낸다. 이후 이러한 프록시 서버는 상기 질의를 상기 변환 알고리즘을 사용해서 RFC를 따르는 포맷으로 변환하고, 상기 질의를 DNS 서버로 보낸다.

DNS 서버에서,

U4B8O7E7RBB4U7BDP1.U696R0E5OAA0U59DQ1 IN A 12.34.56.78

과 같은 유효한 IP 주소로 매핑하는 RFC를 따르는 질의에 대한 엔트리가 존재한다.

이후에 DNS 서버는 RFC1035에 따르는 상기 IP 주소를 iDNS 프록시 서버로 반환한다. 상기 프록시는 이후에 정확히 도출된 IP 주소를 포함하는 메시지를 클라이언트에 응답한다. 정상적으로 (ASCII 형태로) 변환된 도메인 네임이 통상적인 DNS 도메인 네임을 통제하고 허가를 내는 데 믿을 만한 권한을 가지고 등록되어야 한다.

본 발명의 실시예는 상술된 iDNS 운영을 수행하기 위한 장치에 관한 것이다. 이러한 장치는 요구되는 목적을 위해 구성(설계)되거나, 또는 컴퓨터 내에 저장된 컴퓨터 프로그램에 의해 선택적으로 활성화되거나 재구성되는 범용 컴퓨터가 될 수 있다. 여기서 기술되는 과정은 어떠한 특정 컴퓨터 또는 다른 장치와 고유하게 관계되는 것은 아니다. 특히, 다양한 범용장치는 여기에서의 가르침에 따라 작성된 프로그램을 가지고 사용되거나 또는 필요한 방법의 단계를 수행하는 데 보다 전문화된 장치를 구성하는 것이 보다 편리하게 될 수 있다. 이러한 다양한 장치를 위해 필요한 구조는 상기된 내용으로부터 분명하다.

또한, 본 발명의 실시예는 다양한 컴퓨터-구현 동작을 수행하기 위한 프로그램 명령을 포함하는 컴퓨터 판독가능 매체에 관한 것이다. 상기 매체는 프로그램 명령, 데이터 파일, 데이터 구조, 테이블 및 그와 같은 것을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체 및 프로그램 명령은 본 발명을 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에 공지되었고 사용가능한 것일 수 있다. 컴퓨터 판독가능 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체, CD-ROM 디스크와 같은 광학 매체; 플롭티컬 디스크와 같은 자기-광 매체; 및 읽기전용 기억장치(ROM) 및 임의접근 기억장치(RAM)와 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 상기 매체는 프로그램 명령, 데이터 구조 등을 지정하는 신호를 전송하는 수송파를 포함하는 광 또는 금속선, 도파관 등과 전송매체일 수 있다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐 만 아니라 해석기를 사용해서 컴퓨터에 의해서 실행될 수 있는 고급언어 코드를 포함하는 파일도 포함된다.

도 7은 본 발명의 실시예에 따른 통상적인 컴퓨터 시스템을 도시하고 있다. 컴퓨터 시스템(700)은 주기억장치(706)(통상적으로 임의접근 기억장치, 또는 "RAM"), 주기억장치(704)(통상적으로 읽기전용 기억장치, 또는 "ROM")을 포함하는 기억장치와 연결되는 수 개의 프로세서(702)(중앙처리장치, 또는 CPU로 불리기도 함)를 포함한다. 본 기술분야에 잘 알려져 있는 바와 같이, 주기억장치(704)는 데이터와 명령을 단방향성으로 CPU에 전달하는 역할을 하며, 주기억장치(706)는 통상적으로 데이터와 명령을 양방향성으로 전달하는 데 사용된다. 이들 두 가지 주기억장치는 상기된 컴퓨터-판독가능 매체의 어떠한 적절한 형태를 포함할 수 있다. 대용량 기억장치(708)로 양방향성으로 CPU(702)와 연결되어 추가적인 데이터 저장능력을 제공하며 상기된 컴퓨터-판독가능 매체 중 어떠한 것을 포함할 수 있다. 대용량 기억장치(708)는 프로그램, 데이터 및 그와 같은 것을 저장하는 데 사용되며, 통상적으로 주기억장치보다 속도가 느린 하드디스크와 같은 보조기억장치이다. 바람직한 경우에 있어서, 대용량 기억장치(708)내에서 유지되는 정보는 가상 기억장치로서 주기억장치(706)의 일부로서 표준형에 포함될 수 있는 것으로 평가된다. CD-ROM(714)과 같은 특정 대용량 기억장치도 데이터를 단방향으로 CPU에 보낼 수 있다.

CPU(702)는 비디오 모니터, 트랙볼, 마우스, 키보드, 마이크로폰, 터치민감형 디스플레이, 변환기 카드 판독기, 자기 또는 종이 테이프 판독기, 타블렛, 철필, 음성 또는 필기 인식기, 또는 물론 컴퓨터와 같은 기타 공지된 입력장치와 같은 하나 이상의 입/출력 장치를 포함하는 인터페이스(710)와 연결된다. 마지막으로, CPU(702)는 712로 도시된 네트워크 연결을 사용해서 컴퓨터 또는 무선통신 네트워크에 선택적으로 연결될 수 있다. 그러한 네트워크 연결에 따라, CPU가 네트워크로부터 정보를 수신하거나, 상기된 방법의 절차를 수행하여 네트워크에 정보를 보낼 수 있음이 예상된다. 상기된 장치 및 도구는 컴퓨터 하드웨어 및 소프트웨어 기술분야의 당업자에게 잘 알려져 있다.

상기된 하드웨어 장치는 본 발명의 동작을 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 (통상적으로 일시적으로) 구성될 수 있다. 예를들면, 인코딩 타입을 검출하고, 상기 인코딩 타입을 변환 및 기본 이름서버를 식별하기 위한 명령은 주기억장치(706)와 관련하여 대용량 기억장치(708 또는 714)상에 저장되고 CPU(708)상에서 실행된다.

상기한 본 발명이 이해의 명확성을 위해 상세히 기술된 것으로, 본 발명은어떠한 변화 및 변경이 첨부된 청구항의 범위이내에서 실시될 수 있음이 분명하다.

따라서, 본 발명에 의하면, 비-유니코드 및 비-ASCII 인코딩 방식의 도메인 네임을 사용하여 다언어 도메인 네임 시스템을 실행하는 시스템 및 방법을 제공한다.

Claims

장치에서 구현되는, 디지털 방식으로 표현된 도메인 네임의 언어 인코딩 타입을 검출하는 방법에 있어서,

상기 디지털 방식으로 표현된 도메인 네임의 사전-설정부의 디지털 시퀀스를 수신하는 단계;

상기 도메인 네임으로부터의 디지털 시퀀스와 공지된 디지털 시퀀스의 콜렉션으로부터의 공지된 디지털 시퀀스를 매칭하는 단계; 및

상기 도메인 네임으로부터의 디지털 시퀀스와 매칭된 공지된 디지털 시퀀스와 연관된 인코딩 타입을 식별하는 단계를 포함하고,

상기 공지된 디지털 시퀀스의 각각은 특정 언어 인코딩 타입과 연관되고, 상기 콜렉션은 적어도 2가지의 다른 언어 인코딩 타입에 대해 공지된 디지털 시퀀스를 포함하는 방법.
제 1 항에 있어서, 상기 디지털 방식으로 표현된 도메인 네임을 포함하는 DNS 요구를 수신하는 단계를 더 포함하는 방법.
제 1 항에 있어서, 상기 디지털 방식으로 표현된 도메인 네임의 사전-설정부가 상기 도메인 네임의 최소 코드 도출 문자열인 방법.
제 1 항에 있어서, 상기 디지털 방식으로 표현된 도메인 네임의 디지털 시퀀스의 포맷을 상기 디지털 시퀀스를 매치시키기 이전에 변환시키는 단계를 더 포함하는 방법.
제 1 항에 있어서, 상기 공지된 디지털 시퀀스의 콜렉션이 공지된 디지털 시퀀스 및 인코딩 타입을 포함하는 속성을 갖는 레코드를 포함하는 테이블로 제공되는 방법.
제 5 항에 있어서, 상기 테이블이 적어도 이하 인코딩 타입들:'ASCII', 'BIG5', 'GB2312', 'shift-JIS', 'EUC-JP', 'KSC5601' 및 '확장 ASCII'를 갖는 레코드를 포함하는 방법.
제 5 항에 있어서, 인코딩 타입을 식별하는 상기 단계는 상기 매칭된 공지된 디지털 시퀀스를 갖는 레코드의 인코딩 타입을 식별하는 단계를 포함하는 방법.
제 1 항에 있어서, 적어도 두 개의 공지된 디지털 시퀀스가 상기 도메인 네임으로부터의 디지털 시퀀스와 매칭되고,

상기 디지털 방식으로 표현된 도메인 네임의 제 2 부분의 디지털 시퀀스를 수신하는 단계; 및

상기 제 2 부분의 디지털 시퀀스를 상기 공지된 디지털 시퀀스의 콜렉션으로부터의 공지된 디지털 시퀀스와 매치시키는 단계

를 더 포함하는 방법.
제 2 항에 있어서,

식별된 인코딩 타입의 루트 레벨 도메인을 도출하는 것을 신뢰할 수 있는 루트 레벨 DNS 서버를 식별하는 단계; 및

상기 DNS 요구를 상기 루트 레벨 DNS 서버에 전송하는 단계

를 더 포함하는 방법.
제 9 항에 있어서, 상기 DNS 요구를 전송하기 이전에, 상기 식별된 인코딩 타입으로부터의 도메인 네임의 디지털 시퀀스를 DNS 프로토콜과 호환가능한 DNS 인코딩 타입으로 변환시키는 단계를 더 포함하는 방법.
제 10 항에 있어서, 상기 DNS 인코딩 타입이 ASCII 또는 범용 언어 인코딩 타입인 방법.
제 10 항에 있어서, 도메인 네임의 디지털 시퀀스를 변환시키는 상기 단계는,

상기 식별된 인코딩 타입으로부터의 도메인 네임의 디지털 시퀀스를 범용 언어 인코딩 타입으로 변환하는 단계; 및

상기 범용 언어 인코딩 타입으로부터의 도메인 네임의 디지털 시퀀스를 DNS 프로토콜과 호환가능한 DNS 인코딩 타입으로 변환하는 단계

를 포함하는 방법.
디지털 방식으로 표현된 도메인 네임의 언어 인코딩 타입을 검출하는 방법을 이행하기 위한 프로그램 명령이 제공되는 기계 판독가능 매체를 포함하는 컴퓨터 프로그램을 기록한 기록매체에 있어서,

상기 방법은,

상기 디지털 방식으로 표현된 도메인 네임의 사전-설정부의 디지털 시퀀스를 수신하는 단계;

상기 도메인 네임으로부터의 디지털 시퀀스와 공지된 디지털 시퀀스의 콜렉션으로부터의 공지된 디지털 시퀀스를 매칭하는 단계; 및

상기 도메인 네임으로부터의 디지털 시퀀스와 매칭된 공지된 디지털 시퀀스와 연관된 인코딩 타입을 식별하는 단계를 포함하고,

상기 공지된 디지털 시퀀스의 각각은 특정 언어 인코딩 타입과 연관되고, 상기 콜렉션은 적어도 2가지의 다른 언어 인코딩 타입에 대해 공지된 디지털 시퀀스를 포함하는 컴퓨터 프로그램을 기록한 기록매체.
제 13 항에 있어서, 상기 공지된 디지털 시퀀스의 콜렉션이 공지된 디지털 시퀀스 및 인코딩 타입을 포함하는 속성을 갖는 레코드를 포함하는 테이블로 제공되는 컴퓨터 프로그램을 기록한 기록매체.
제 13 항에 있어서,

상기 디지털 방식으로 표현된 도메인 네임을 포함하는 DNS 요구를 수신하는 단계;

상기 식별된 인코딩 타입의 루트 레벨 도메인을 도출하는 루트 레벨 DNS 서버를 식별하는 단계; 및

상기 DNS 요구를 상기 루트 레벨 DNS 서버에 전송하는 단계

에 대한 프로그램 명령을 더 포함하는 컴퓨터 프로그램을 기록한 기록매체.
제 15 항에 있어서, 상기 DNS 요구를 전송하기 이전에, 상기 식별된 인코딩타입으로부터의 도메인 네임의 디지털 시퀀스를 DNS 프로토콜과 호환가능한 DNS 인코딩 타입으로 변환시키는 단계에 대한 프로그램 명령을 더 포함하는 컴퓨터 프로그램을 기록한 기록매체.
기계- 판독가능한 매체상에서, 특정 언어 인코딩 타입을 특정 디지털 시퀀스와 연관시키는 다수의 레코드를 포함하는 언어 인코딩 타입 매핑 테이블을 기록한 기록매체에 있어서,

상기 레코드의 각각은,

디지털 방식으로 표현된 도메인 네임의 사전-설정부의 공지된 디지털 시퀀스; 및

상기 공지된 디지털 시퀀스와 연관된 언어 인코딩 타입

을 포함하고,

상기 레코드 중 적어도 2가지는 서로 다른 언어 인코딩 타입을 포함하는 매핑 테이블을 기록한 기록매체.
제 17 항에 있어서, 상기 디지털 방식으로 표현된 도메인 네임의 사전-설정부는 상기 도메인 네임의 최상위-레벨 도메인의 디지털 시퀀스인 매핑 테이블을 기록한 기록매체.
제 17 항에 있어서, 상기 매핑 테이블의 레코드가 적어도 이하 언어 인코딩 타입들: 'ASCII', 'BIG5', 'GB2312', 'shift-JIS', 'EUC-JP', 'KSC5601' 및 '확장 ASCII'를 포함하는 매핑 테이블을 기록한 기록매체.
제 17 항에 있어서, 상기 레코드는 상기 레코드에서 언어 인코딩 타입의 루트 레벨 도메인을 도출하는 최상위-레벨 DNS 서버를 더 포함하는 매핑 테이블을 기록한 기록매체.
제 17 항에 있어서, 상기 레코드는 인코딩 타입을 DNS를 따르는 인코딩 타입으로 변환하는 변환부를 더 포함하는 매핑 테이블을 기록한 기록매체.
제 17 항에 있어서, 상기 레코드는 존속시간 필드(time to live field)를 더 포함하는 매핑 테이블을 기록한 기록매체.
제 21 항에 있어서, 상기 DNS를 따르는 인코딩 타입은 ASCII 또는 범용 언어 인코딩 타입인 매핑 테이블을 기록한 기록매체.
하나 이상의 프로세서;

상기 하나 이상의 프로세서 중 적어도 하나에 연결된 메모리; 및

비-DNS 인코딩 타입의 도메인 네임을 포함하는 DNS 요구를 수신하고 DNS 프로토콜과 호환가능한 DNS 인코딩 타입의 도메인 네임을 갖는 DNS 요구를 전송할 수 있는 하나 이상의 네트워크 인터페이스

를 포함하고,

상기 하나 이상의 프로세서 중 적어도 하나는,

다수의 인코딩 타입을 위한 공지된 디지털 시퀀스의 콜렉션을 이용하여 다른 비-DNS 인코딩 타입과 구별되는 비-DNS 인코딩 타입을 검출하고, 상기 비-DNS 인코딩 타입의 도메인 네임을 DNS 인코딩 타입의 도메인 네임으로 변환하도록 설계되거나 구성된 장치.
제 24 항에 있어서, 상기 하나 이상의 네트워크 인터페이스는 비-DNS 인코딩 타입의 도메인 네임을 제공하는 클라이언트 DNS 요구를 수신하도록 하는 방식으로 네트워크에 연결되는 장치.
제 24 항에 있어서, 상기 하나 이상의 네트워크 인터페이스는 DNS 인코딩 타입의 도메인 네임을 제공하는 DNS 요구를 표준 DNS 서버에 전송하도록 하는 방식으로 네트워크에 연결되는 장치.
제 24 항에 있어서, 메모리상에 적어도 일부로 존재하는, 특정 언어 인코딩 타입을 디지털 방식으로 인코딩된 도메인 네임의 특정 디지털 시퀀스(digital sequence)와 연관시키는 매핑 테이블을 기록한 기록매체를 더 포함하는 장치.
제 24 항에 있어서, 상기 적어도 하나의 프로세서가 비-DNS 인코딩 타입으로부터 도메인 네임을 DNS 인코딩 타입으로 변환시키기 이전에 도메인 네임의 비-DNS 인코딩 타입을 식별하도록 구성되거나 또는 설계되는 장치.