/* the tucows developer blog */

XCP Commands via XML Over HTTPS POST

The Preferred Way

A yak, shaving.After having a discussion with Grant Spradling, our Product Manager for Platypus and Enablers, it was decided that we’d promote the XML over HTTPS POST method as the preferred way for client code to connect to OpenSRS.

It’s much closer to the way most web services work these days, and it’s simpler than the original method, which required you to get your paws on a Blowfish library and do some extra programming or use a library like OpenSRS-PHP. As I like to put it, connecting to OpenSRS using the XML over HTTPS POST method involves “a lot less yak shaving“: It’s the method that requires the least setting up, it uses libraries that are very likely to be in the default installation of your favorite programming language and it minimizes the amount of code you have to write.

What Does This Mean?

Project Ash: Wrapper Functions for Tucows APIsIf you’ve been following the Project Ash series of articles, you’re probably wondering what this change means.

First, any example code I’ve shown and any code you’ve written based on those examples will still work. We have too many customers whose client code connects to the OpenSRS the old way to invalidate it. If you want to, you’ll still be able to connect to OpenSRS the old way; we just think that connecting using XML over HTTPS POST is the better way.

Second, you might be wondering if this change invalidates any of the existing Project Ash articles. The answer is “no, for the most part”:

  • The API calls will remain the same. What changes is the way in which those commands are sent.
  • The XML for API calls will remain the same. Once again, ti’s not the commands that have changed, but the way in which they’re sent.
  • The PHP example code will still work. It’s just that we think there’s a better way, and I’ll be writing new PHP examples in the coming days to reflect it.

What This Article Will Cover

In this article, I’m going to:

  • Look at the makeup of an API message sent via HTTPS POST
  • Go over code examples in PHP and Ruby. In follow-up articles, I’ll provide code examples in other programming languages.

Sending API Commands Via HTTPS POST

HTTP POST: A Quick Refresher

HTTPS isn’t really a protocol separate from HTTP, but HTTP over a secure connection, either Secure Sockets Layer (SSL) or Transport Layer Security (TLS). The protocol itself is the same, whether it’s HTTP or HTTPS.

The two most common “verbs” in the HTTP protocol are GET and POST.


GET is dirt simple — everything is specified in the URL and headers. Here’s an example GET request that results from a login form at the root of where the user entered a username of chunkylover53 and the password donuts and clicked a submit button labelled OK:

GET /?username=chunkylover53&password=donuts&submit=OK HTTP/1.1
User-Agent: Mozilla/5.0

Note that in a GET request, information specific to the application (in this case, the username, login and peripherally, the text on the “submit” button) is embedded in the URL. Although there’s no technical limit to the length of an URL, URL length is limited by the browser; a long-time general rule is not to make URLs longer than 1K characters.


POST is only a little more complex. A POST request still has an URL and headers, but also has additional information. Here’s the same form request as the one shown in the GET example above, but in POST form:

User-Agent: Mozilla/5.0
Content-Length: 48
Content-Type: application/x-www-form-urlencoded


In a POST request, information specific to the application is not in the URL; rather, it comes after the headers and is separated from the headers by a blank line. Note that you have to provide the length (in bytes) of the information you embed in the request in the Content-Length: header.

If the POST request was generated by a form, the information is typically in “URL-encoded form” format, like this:


There’s no reason that the information embedded in a POST request can’t be in other forms. This flexibility gave rise to sending XML in HTTP POST requests, which in turn gave us AJAX — and XML over HTTPS POST.

One more thing: in the case of sending messages to OpenSRS, it’s done on port 55443.

Headers for an XCP Command Sent via HTTPS POST

Let’s get the hard stuff out of the way first. The table below shows what the headers for an XCP command sent via HTTPS POST should be.

Header Value
Wooden pegs-and-holes toy
Since we’re sending an XML message inside the POST request, you should set this to text/xml.
'Hello my name is...' sticker
Set this to your Tucows API username.
Pen and signature
Set this to the message digest, a value calculated using the XCP API message you want to send and your private key.

Here’s a diagram that shows how to generate the message digest:

Diagram showing how to generate a message digest

In PHP, the implementation looks like this:

$signature = md5(md5($apiCommand . OPENSRS_PRIVATE_KEY) . $OPENSRS_PRIVATE_KEY);

Here’s the same thing in Ruby:

signature = Digest::MD5.hexdigest(
	Digest::MD5.hexdigest(api_command + OPENSRS_PRIVATE_KEY) +
Tape measure
Set this to the length (in bytes) of XCP API command that you’re sending:
  • In PHP, use the strlen() function to get the length of your XCP API command.
  • In Ruby, use the length or size method to get the length of your XCP API command.

Body for an XCP Command Sent via HTTPS POST

Message in a bottleThe message body is easy: it’s just the XML that makes up the API command.

For example, if you wanted to run the lookup command on the domain, the body would simply be:

<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<!DOCTYPE OPS_envelope SYSTEM 'ops.dtd'>
       <item key="protocol">xcp</item>
       <item key="action">lookup</item>
       <item key="object">domain</item>
       <item key="attributes">
           <item key="domain"></item>

Let’s Code!

And finally, I’ll finish by showing you some code. Here’s the code for a simple application that runs the lookup command on the domain, in both PHP and Ruby. Tune in next week, when I’ll post code in other programming languages.



$xml = '<?xml version='1.0' encoding="UTF-8" standalone="no" ?>
<!DOCTYPE OPS_envelope SYSTEM "ops.dtd">
    <item key="object">DOMAIN</item>
    <item key="action">LOOKUP</item>
    <item key="protocol">XCP</item>
    <item key="attributes">
      <item key="domain"></item>

$signature = md5(md5($xml.$private_key).$private_key);
$host = ""; # Set this to if you
                                 # want to connect to the test server instead.
$port = 55443;
$url = "/";
$header = "";
$header .= "POST $url HTTP/1.0rn";
$header .= "Content-Type: text/xmlrn";
$header .= "X-Username: " . $username . "rn";
$header .= "X-Signature: " . $signature . "rn";
$header .= "Content-Length: " . strlen($xml) . "rnrn";
# ssl:// requires OpenSSL to be installed
$fp = fsockopen ("ssl://$host", $port, $errno, $errstr, 30); 

echo "<pre>"; 

if (!$fp) {
  print "HTTP ERROR!";
} else {
  # post the data to the server
  fputs ($fp, $header . $xml);
  while (!feof($fp)) {
    $res = fgets ($fp, 1024);
    echo htmlEntities($res);
  fclose ($fp);

echo "</pre>";


#! /usr/bin/env ruby

require 'net/https'
require 'digest/md5'
require 'rexml/document'
include REXML

OPENSRS_SERVER = '' # Set this to if you
                                         # want to connect to the test server instead.

domain = ARGV[0]

requestXml = <<-END
<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<!DOCTYPE OPS_envelope SYSTEM 'ops.dtd'>
       <item key="protocol">xcp</item>
       <item key="action">lookup</item>
       <item key="object">domain</item>
       <item key="attributes">
           <item key="domain"></item>

message_digest = Digest::MD5.hexdigest(
                   Digest::MD5.hexdigest(requestXml + OPENSRS_PRIVATE_KEY) +


  http.use_ssl = true
  req ='/')
  req['Content-Type'] = 'text/xml'
  req['X-Username'] = OPENSRS_USERNAME
  req['X-Signature'] = message_digest
  req['Content-Length'] = requestXml.size.to_s

  response = http.request(req, requestXml)

  http.finish if http.started?


puts response.body

Comment +0

ICANN에서는 영문으로된 도메인뿐만 아니라 각 국가별 언어에 맞는 도메인 서비스를 제공하고 있다.
일반적으로 한글도메인 하면 넷피아를 떠올리는 사람들이 있는데 넷피아에서 제공하는 서비스는 한글 도메인이 아니라 한글검색어 서비스일 뿐이다.
즉, 한글로된 검색어를 입력하면 넷피아의 컴포넌트를 이용하여 해당 검색어를 서버의 아이피로 연결시켜주는 그런 서비스가 되는것이다.

머.. 넷피아도 KT랑 이런저런 일때문에 쫑나면서 더이상 서비스가 안되지만 말이지..

위에서 말한 한글 도메인은 "테터툴즈.com" 이나 "네이버.net" 과 같이 한글로 이루어진 도메인명과 gTLD를 붙여서 생성하게 되며, 해당 도메인들은 최상위등록기관(Registry)인 Verisign에서 2000년 11월에 한글.kr의 경우에는 KRNIC(한국 인터넷진흥원) 주관으로 2003년 8월부터 서비스를 시작했다. 물론 한글 도메인은 다국어 도메인 중의 하나일뿐...

그럼 한글로 등록한 도메인을 해외에서 알아 볼 수 있느냐?

한글 도메인들은 Verisign에서 제공하는 한글 도메인명을 Puny 코드 변경 컴포넌트를 설치하지 않으면, 사용 할 수 없다. 물론 국내에서도 마찬가지로 해당 컴포넌트를 설치해야 한다.

해당 컴포넌트는 아래 주소를 통하여 받을 수 있다.


그럼 이와 같은 한글도메인들은 네임서버나 웹서버에 셋팅할때 어떻게 셋팅하여야 하는가?
그냥 한글로 등록하면 되는가?

물론 아니다... 해당 한글 도메인들은 한글도메인명을 Puny 코드로 변경하여 네임서버 및 웹서버에 등록해야 하며, 위에서 이야기 했다시피 실제 도메인을 찾는 주소는 Puny코드이기 때문에 이를 착각하여 한글도메인을 네임서버나 웹서버에 셋팅하면 안되겠다.

Puny코드로 변경하는 방법은 한국 인터넷 진흥원에서 제공하는 웹컨버터와 모듈 프로그램을 구축하여 변경 할 수 있다.

Web :
모듈 : < - 참조

Comment +0

* 네임서버호스트 등록 개략

- 네임서버의 호스트 등록은 도메인을 등록한 업체(Ex : Onlinenic, Tocows 등)를 통하여 등록 할 수 있으며, 도메인 등록 대행자는 이에 대한 정보를 GTLD DNS에 업데이트 하여 최상위 기관에서 조회 할 수 있도록 하게 됩니다.

- HOST에 대한 의미는 다양하게 존재합니다. 일반적으로 www, mail, ns와 같은 Subdomain을 HOST라고 명명하며, 서버의 의미도 가지고 있습니다. 우리가 도메인을 등록 한 후 등록한 도메인을 이용하여 네임서버를 운영하고자 한다면, 해당 도메인을 도메인 등록업체의 절차에 따라 호스트 등록을 해주어야 합니다.

- 여기서 말하는 호스트 등록은 해당 도메인을 네임서버의 주소로 사용하기 위하여, 최상위기관(Root DNS Server)에 등록한 후 그에 대한 정보들을 추적 할 수 있도록 하는 것을 말합니다. 그에 대한 예로 아래 DNS 추적결과를 참조하여 주시기 바랍니다.

* DNS 쿼리과정 

사용자 삽입 이미지

<이미지 출처 : 한국인터넷진흥원>

* DNS 추적결과

[root@7strike work]# dig +trace

; <<>> DiG 9.2.4 <<>> +trace
;; global options:  printcmd
.                       466892  IN      NS      C.ROOT-SERVERS.NET.
.                       466892  IN      NS      G.ROOT-SERVERS.NET.
.                       466892  IN      NS      F.ROOT-SERVERS.NET.
.                       466892  IN      NS      B.ROOT-SERVERS.NET.
.                       466892  IN      NS      J.ROOT-SERVERS.NET.
.                       466892  IN      NS      K.ROOT-SERVERS.NET.
.                       466892  IN      NS      L.ROOT-SERVERS.NET.
.                       466892  IN      NS      M.ROOT-SERVERS.NET.
.                       466892  IN      NS      I.ROOT-SERVERS.NET.
.                       466892  IN      NS      E.ROOT-SERVERS.NET.
.                       466892  IN      NS      D.ROOT-SERVERS.NET.
.                       466892  IN      NS      A.ROOT-SERVERS.NET.
.                       466892  IN      NS      H.ROOT-SERVERS.NET.
;; Received 436 bytes from in 7 ms

com.                    172800  IN      NS      A.GTLD-SERVERS.NET.
com.                    172800  IN      NS      B.GTLD-SERVERS.NET.
com.                    172800  IN      NS      C.GTLD-SERVERS.NET.
com.                    172800  IN      NS      D.GTLD-SERVERS.NET.
com.                    172800  IN      NS      E.GTLD-SERVERS.NET.
com.                    172800  IN      NS      F.GTLD-SERVERS.NET.
com.                    172800  IN      NS      G.GTLD-SERVERS.NET.
com.                    172800  IN      NS      H.GTLD-SERVERS.NET.
com.                    172800  IN      NS      I.GTLD-SERVERS.NET.
com.                    172800  IN      NS      J.GTLD-SERVERS.NET.
com.                    172800  IN      NS      K.GTLD-SERVERS.NET.
com.                    172800  IN      NS      L.GTLD-SERVERS.NET.
com.                    172800  IN      NS      M.GTLD-SERVERS.NET.
;; Received 489 bytes from in 203 ms            172800  IN      NS            172800  IN      NS
;; Received 103 bytes from in 203 ms            3600    IN      A            3600    IN      NS            3600    IN      NS
;; Received 119 bytes from in 3 ms

간단한 예로 7strike.com의 조회시 NS에 대한 정보를 찾는 과정을 나열한 것입니다.

이렇게 최상위서버인 Root Server에 해당 네임서버의 정보를 등록함으로써 도메인을 조회했을때 순차적으로 검색하여 그에 따른 IP값을 찾아낼 수 있습니다.

* 참조 : Root_DNS_Server

개인적으로 위키에 있던 내용을 정리하느라 조금 애 먹었습니다. ㅋ;;;

Comment +0

ICANN과 인터넷거버넌스 동향

한국인터넷진흥원 대외협력팀장 권  현 준

現 ICANN GAC advisor; 現 ICANN ASO Address Councilor;
現 NRO Number Councilor; 現 APNG Internet History Museum Committee Chair;

한국ITU연구위원회 연구위원

우리의 일상이 정보통신기술과 접목되면서 많은 생활의 변화가 야기되고 있고, 특히 인터넷은 이 시대를 살아가는 인류에게 물과 공기와 같은 필수적인 환경적 요소로 자리잡아가고 있다. 인터넷과 관련된 기술과 정책은 지금 이 순간에도 끊임없이 변화하고 있으며, 이 같은 환경의 변화를 야기하는 배경과 주요 이슈에 대한 동향을 분석하고 그 변화의 방향을 파악하는 것이 IT 강국으로서의 역량을 강화하고 제고해나가는 밑거름이 될 것이다.

인터넷거버넌스는 인터넷과 거버넌스의 합성어로, 1990년대 중반 하버드 법과대학 버크만센터의 ‘하버드 정보기반 프로젝트’(Harvard Information Infrastructure Project) 연구원들에 의해 루트서버 운영, 인터넷프로토콜 주소할당 및 DNS(Domain Name System) 운영 등 인터넷 핵심자원과 관련된 운영에 대한 기능을 의미하는 것으로 처음 사용되기 시작하였다 Wolfgang Kleinwächter. 2004. Internet Co-Governance: Towards a Multialyer Multiplayer Mechanism of Consultation, Coordination and Cooperation(M3C3)
. 그 후 인터넷거버넌스라는 개념이 2003년 12월에 스위스 제네바에서 개최된 제1차 정보사회정상회의(WSIS, World Summit on Information Society) 준비위원회 논의과정에서 쟁점이슈로 부각되면서 인터넷주소자원 및 스팸, 접속비용 등 인터넷 관련 공공정책들을 포함하는 넓은 개념으로서 2003 WSIS 선언문에 공식적으로 등장하게 되었다. 이러한 주요 인터넷관련 정책을 형성하는 국제적 인터넷거버넌스 매커니즘을 확립하기에 앞서 먼저 국제적으로 합의된 정의도출이 필요했고, 이를 위해 유엔 사무총장 코피 아난의 지휘아래 ‘인터넷거버넌스워킹그룹’ (WGIG, Working Group on Internet Governance)을 구성하기에 이르렀다. 인터넷거버넌스가 무엇인지 정의도 내리기 전에 인터넷거버넌스에 대한 워킹그룹을 구성한 것이 아이러니한 것은 사실이나, 이는 인터넷거버넌스의 개념 정의가 국제정보사회에서 그만큼 중요한 의미를 지니고 있음을 보여주는 것이다. WGIG가 논의하는 과정 중에 인터넷거버넌스의 정의에 대하여 ITU-T의장을 비롯하여 많은 학자와 전문가가 의견을 제시하였고, 이를 토대로 2005년 7월 15일 WGIG의 최종 보고서는 “인터넷거버넌스는 정부, 민간부문, 및 시민사회가 각자의 역할을 가지고 인터넷의 발전과 사용을 구체화한 공통된 원칙, 규범, 규칙, 의사결정절차 및 프로그램을 개발하고 적용하는 것이다.”라고 정의를 발표하였다. 그리고 인터넷거버넌스가 거론될 때마다 국제인터넷주소자원관리기관인 ICANN(The Internet Corporation for Assigned Names and Numbers)은 항상 그 논의의 중심에 서 있었다.

본장에서는 인터넷의 핵심 인프라로서 기능하는 인터넷 주소자원 즉, IP 주소, 도메인이름 및 DNS 등을 관리하는 ICANN이라는 기관이 2차에 걸친 WSIS에서 핫이슈인 ‘인터넷거버넌스’와 어떤 관련성을 갖고 있는지 살펴보고자 한다. 이에 우선 ICANN이라는 조직의 성격을 알아보고  ICANN을 둘러싼 국제인터넷거버넌스의 흐름을 파악함과 동시에 변화하는 인터넷거버넌스 패러다임 속에서 우리의 입장은 어떤 것이 있을 수가 있는지 살펴보고자 한다.


1. ICANN의 생성

1998년 미국 캘리포니아주에 설립된 비영리법인 ICANN은 세계 인터넷주소자원의 운영을 관장하는 행정조정기구로서 미상무성으로부터 인터넷과 관련된 기술적인 문제를 처리하는 것을 기본임무로 위임받았다. 미상무부와 ICANN간의 양해각서에 따라, ICANN은  인터넷의 보편적인 접속유지를 위한 기술적 파라메터의 할당의 조정, 인터넷 IP 주소자원의 조정에 관한 기능수행 및 감독, DNS 루트 시스템에 추가될 새로운 TLD의 환경에 대한 정책을 비롯한 인터넷 도메인이름 시스템의 조정에 관한 기능수행 및 감독, DNS 루트서버 시스템에 대한 감독 등의 업무를 수행하고 있다. ICANN Bylaws(2005.4.8)의 Article I Section 1 참조.

ICANN 생성의 연혁을 알고자 한다면, 먼저 도메인이름 등 주소자원의 관리의 역사를 살펴보아야 할 것이다. 초기의 주소자원의 관리는 University of Southern California에 소재하고 있는 Information Sciences Institutes(USC-ISI)에서 Jon Postel이 군 관련기관인 ARPA(The Advanced Research Project Agency)의 지원을 받아 수행하고 있었으며, 이 활동은 흔히 IANA(Internet Assigned Numbers Authority) 업무로 불려져 왔다. 존 포스텔이 15년 동안 수행해오던 이 임무는 1987년 Stanford Research Institute Network Information Center(SRI-NIC)로 위탁되었고 다시 1991년에 도메인이름등록권한이 Government System Inc.(GSI)로 이전되었다. 이 등록업무는 1993년 1월 1일부터 National Science Foundation(NSF)와 Network Solutions Inc.(NSI)간의 협정으로 GSI에서 NSI로 다시 이전되어 수행되었다.

NSI는 .com, .net, .org를 선접수 선취득의 원칙에 따라 레지스트리 기능과 레지스트라 기능을 동시에 수행했는데, 그 독점적 운영형태는 도메인시장에서 상당한 불만을 초래하게 된다. 등록초기인 1994년에는 미국정부의 1백만달러의 지원을 받아 무료등록업무를 수행하고 있었으나, 도메인이름의 폭발적 증가에 따른 업무의 효율성 등을 근거로 하여 1995년 7월부터 도메인이름사용자에게 요금을 부과하기 시작했다. 결국 도메인이름등록사업을 수행한 NSI는 수백만달러의 수입을 올리며 성공적으로 상업화되었다. 이러한 NSI의 시장 독점적 운영형태를 우려한 존 포스텔 등 여러 저명한 인터넷 기술자들이 NSI의 독점적 사업을 종결시키기 위한 운동에 앞장서게 되었고, 도메인이름 등록을 비롯한 IANA 업무를 정부와의 계약을 통하여 민간으로 이양할 것을 시도하였고, 1996년 10월 International Ad Hoc Committee(IAHC)를 통해 이러한 시도는 더욱 구체화되었다.

IAHC는 IANA, ISOC(Internet Society), IAB(Internet Architecture Board), ITU(International Telecommunication Union), WIPO(World Intellectual Property Organization), INTA(International Trademark Association)의 연합체로서 이들은 1997년 5월 2일 gTLD MOU(Memorandum of Understanding on generic Top Level Domains)를 체결하였다. 그 주요 내용은 도메인이름의 관리에 관한 최종정책을 결정하는 POC(Policy Oversight Committee)의 구성, 7개의 신규일반최상위도메인이름(.arts, .firm, .info, .nom, .re, .shop, .web)의 생성, 28개의 등록대행사업자(Registrar)의 허가, A 루트서버를 미국에서 스위스 제네바로 옮기는 것이었다. ITU 사무총장 Pekka Tarjanne는 이 MOU 체결은 새로운 글로벌 인터넷 정책의 시작이고  국제법에서 하나의 전환점이라며 반기는 입장이었으나, 미국정부는 이에 대해 깊은 반감을 표명하기에 이르렀다. 당시 미국 국무장관이었던 Madeleine Albright는 ITU 회원국과의 협의 없이 ITU가 MOU를 체결한 것을 비난했고, NSI는 자신의 독점적 지위에 대한 도전을 막기 위해 미 의회에 강력한 로비를 벌이며 민영화움직임에 첨예하게 대립하기 시작하였고, MOU 체결에 참여하지 않은 국가최상위도메인(ccTLD, country-code Top Level Domain) 등록기관들도 반대의견을 제시하였다.

그로부터 두 달 이후 DNS에 대한 외부의 달갑지 않은 관심을 느낀 미국 정부는 서둘러 DNS의 민영화 계획을 발표하기에 이른다. 1997년 7월 1일, 백악관은 DNS 민영화를 제안하는 ‘A Framework for Global Electronic Commerce'를 발표하였는데, 물론 이 문서 어디에도 IAHC의 gTLD MOU에 대한 언급은 없었다. 이어 미상무성은 국제화된 민간의 DNS 관리기구인 일명 'NewCo'(現 ICANN)의 설립을 추진하는 계획을 1998년 초에 녹서(Green Paper)를 발표하였다. 녹서가 발표되자, 유럽공동체위원회(EC, European Commission)는 미국의 지배를 비난하며, 미래의 인터넷거버넌스를 위한 글로벌 참여에 기반한 기구의 필요성을 제기하였다. 이러한 유럽의 비난에 대하여 미국 클린턴 대통령의 인터넷 보좌관이었던 Ira Magaziner는 미상무성이 제안한 것은 DNS의 기술적 관리를 향상시키기 위한 것이지 미국 단독의 지배를 위한 것은 아니며, 문제가 되고 있는 글로벌 참여를 보장하기 위해 'NewCo'의 이사들은 인터넷의 기능적, 지역적 다양성을 고려하여 구성될 것이라고 밝혔다. 미상무성은 녹서를 좀 더 수정하여 그해 6월에 백서(White Paper)를 발표하였다. 백서는 NewCo의 설립원칙으로 인터넷의 안정성, 도메인이름 시장의 경쟁, 민간의 상향식 정책조율, 글로벌 대표성을 제시하면서 ICANN의 설립근거를 마련하였다. 한편, 1998년 10월 미네아폴리스에서 개최된 ITU 전권회의에서 미국은 ITU가 개최하려던 정보사회에 대한 국제 컨퍼런스를 반대하던 입장을 철회하는 대신에 ITU로부터 미국이 추진하는 DNS 관리에서의 민간의 리더십을 인정받는 전형적인 외교적 협상을 성사시킴으로써 ICANN을 국제사회에서 인정받는 기반을 마련하였고, ITU는 WSIS 개최를 미국의 지지를 받으면서 추진하게 된 것이다.

드디어 1998년 11월 25일, 미상무성은 ICANN을 NewCo로 인정하는 MOU를 체결하였고, 이에 따라 ICANN은 국제 인터넷주소자원관리기구로서의 역할을 수행하게 된다. ICANN은 인터넷주소자원에 대한 전반적인 관리업무를 수행하는 한편, 미상무성은 ICANN을 감독하는 역할을 수행하게 되는데, 설립에 관여했던 Ira Magaziner는 미국중심의 관리체계에 대한 국제사회의 우려를 인식하고, 2년의 경과기간을 거쳐 미상무성의 감독기능을 중단이 가능할 것이라고 언급하였으나, 2005년 6월 30일 'U.S. Principles on Internet's Domain Name and Addressing System'
을 통해 미국정부는 앞으로도 계속 DNS를 관리해 갈 것임을 명백히 밝히고 있다.

2. 2002 ICANN 개혁안 등장

1998년 설립된 이래 2002년까지 운영되었던 ICANN의 기본 임무는 인터넷을 상호 안정적으로 운영하는 것과 인터넷의 주소, 프로토콜, 그리고 도메인 관련 업무를 관장하는 것, 그리고 도메인네임 루트 서버의 안정적인 운영을 관장하는 것 등으로 되어있었다. ICANN은 업무관련 주요정책결정에 있어서 많은 인터넷이용자의 참여를 유도하여 의사결정의 대표성을 확보하고 원활한 업무수행을 위한 자금원의 확보를 위해 노력해왔다. 하지만 인터넷 사용이 전세계로 확산되면서 각 국가의 최상위도메인인 ccTLD(country code Top Level Domain)의 관리자들과 ICANN의 관계는 그다지 원활하지 못하여 대부분의 ccTLD와 계약을 맺지 못한 상태여서 자발적인 기부금의 형태로 밖에 운영할 수밖에 없는 상황이다.  특히 ccTLD와의 계약을 추진하는 과정에서 “Best Practices for ccTLD Managers”라는 문서를 공표하였는데 이 문서가 각국의 ccTLD 관리자들에게 지나치게 제한적이라는 이유로 캐나다, 일본, 호주 등 12개 국가를 제외하고는 ICANN과의 계약을 맺지 않은 상태이고 이에 따라 ICANN의 운영에 적신호가 켜진 것이었다.

2002년 2월에 ICANN의 사장인 Stuart Lynn은 1998년 설립된 이래 ICANN이라는 조직이 겪어왔던 여러 가지 문제점들을 지적하면서 전격적인 구조 조정을 해야한다는 개혁안 “ICANN: A Case for Reform”을 발표한 것이다. 이 개혁안에 대해 3월 ICANN 가나 정례회의 등 1년여에 걸쳐 이에 대한 논의가 있었고, 12월 15일에 정관을 새로이 개정함으로써 그 개혁논의를 일단락 지었다. 다만, ccTLD 관련사항은 나라마다의 다양한 이해관계를 조율하지 못하여 이에 대한 내용은 제외되었다가 ccTLD그룹 지원조직인 ccNSO에 관하여 2003년 6월 26일에서 정관을 개정하였다.

3. ICANN의 주요조직

가. 이사회
ICANN의 최고 의결기관으로 대륙별 5개 지역(아태, 북미, 남미, 유럽, 아프리카)에서 최대 5명까지 이사를 선출할 수 있으며, CEO를 제외한 이사의 임기는 3년이며, 3회를 초과하여 연임할 수 없도록 하고 있다. 이사회는 의결권을 가진 15명의 이사와 다른 ICANN 내부조직과의 연락을 담당하는 6명의 Liaison으로 구성되어 있다. 의결권을 가지는 이사는 ccNSO(Country-Code Names Supporting Organization, 국가최상위도메인이름지원조직), ASO(Address Supporting Organization, 주소지원조직), GNSO(Generic Names Supporting Organization, 일반최상위도메인이름지원조직), Nominating Committee 등 ICANN 내부의 주요조직들에 의하여 선임되는데, ccNSO, ASO, GNSO에서 각 2명, 그리고 Nominating Committee에서 8명의 이사를 선출할 수 있어, CEO를 포함하여 총 15명의 이사가 이사회를 구성하게 되는 것이다. 이사회는 주요 6개 기관별로 1명의 리에종(Liaison)을 두고 있는데, 그 기관을 살펴보면 다음과 같다. TLG(Technical Liaison Group), IETF(Internet Engineering Task Force), RSSAC(Root Server System Advisory Committee), SAC(Security and Stability Advisory Committee), GAC(Governmental Advisory Committee), ALAC(At Large Advisory Committee)

(그림1 : ICANN 조직도)

나. Supporting Organizations

ICANN은 주소자원관련 주요정책개발을 위해서 전문성과 이해관계 등을 살펴 ccTLD를 위한 ccNSO, gTLD를 위한 GNSO, IP를 위한 ASO 등 세 개의 지원조직을 구성하고 있다.

● ccNSO

ccTLD 커뮤니티의 합의된 의견을 도출하고 ccTLD 관련 주요정책을 개발하여 이사회에 권고하는 역할을 수행하는 기관으로 ICANN내부에서 ccTLD의 목소리를 이사회에 전달하는 임무를 수행하고 있다. 이전 정관에서는 DNSO(Domain Name Supporting Organization) 하부의 일곱 개의 constituency중의 하나인 ccTLD constituency로 활동해왔으나, 2003년 6월 26일 개정된 정관에서 별도의 지원조직으로 격상되었다. ccTLD의 중요성이 인터넷거버넌스 이슈와 맞물려 널리 인식되기 시작하면서 이러한 별도의 지원조직으로의 탄생은 이미 예견된 사항이다.

이미 ccTLD 관리자들은 유럽의 CENTR나 아시아의 APTLD, 그리고 전체 ccTLD 회의를 통해 의견을 취합하는 등 ICANN과는 별도의 활동을 활발하게 진행시키고 있었다. 특히 ICANN에 자신들의 의견이 제대로 반영되기 위해서는 ICANN의 도메인네임지원기구(DNSO)를 일반최상위도메인과 국가최상위도메인으로 분리하여 운영해야 한다는 입장을 일찍부터 표명하고 있었다. ccTLD 측에서는 2001년 6월의 Stockholm회의에서 논의하기 시작, 2001년 9월의 Montevideo회의에서 공식 결의문을 채택하였고 이후 ICANN내에 정식으로 국가코드 지원조직인 ccSO(country code Supporting Organization)를 설립하기 위한 노력을 진행시켜왔다.

사실 ICANN은 설립 초기부터 대표성과 정당성을 증진시키기 위해 일반이용자들의 참여를 유도하고 이들이 선출한 이사진을 선정하는 등의 노력을 기울여 왔으나, 미국 정부 주도로 조직된 기관이라는 점에서 초기부터 다른 국가들의 도메인 관리자들과의 진통이 예상되었던 것이 사실이다. 이러한 다양한 정황을 반영하여 2002년 2월에 발표되었던 Stuart Lynn의 개혁안에는 국가 도메인 관리자들과의 원활하지 못한 관계를 회복시키기 위한 목적으로 각 국의 정부가 적극적으로 개입해 줄 것을 요청하는 내용을 담고 있는 것이다. Stuart Lynn의 문서는 우선 ICANN 운영의 여러 가지 문제점을 지적하면서 개혁의 필요성 및 당위성을 논하고 있는데, 이를 타개하기 위해 각 기관들, 특히 ccTLD들이나 국가들의 역할이 증진되어야 할 필요성을 언급하였다. 이 문건은 이제까지 ICANN에 쏟아졌던 비판 및 요구를 잠식시키고 그 동안 운영상 겪었던 문제들을 해결하는 한편 나름대로 재원 확보를 위한 방안을 강구한 것으로 풀이된다.

ccNSO의 가입은 회원가입을 서면으로 동의한 ‘ccTLD 매니저’들로 구성이 되고 주요정책결정은 회원 ccTLD 매니저들의 18명의 대표로 구성된 Council(평의회)를 두어 담당하게 된다. ICANN 정관은 ccTLD 매니저를 ISO(국제표준화기구, International Organization for Standardization) 3166을 따르는 국가최상위도메인이름을 관리하고 IANA D/B상에 ‘Sponsoring Organization'으로 지칭되는 기구나 단체라고 정의하고 있다. 현재 .KR을 비롯하여 45개국이 가입하고 있다. ccNSO가 생성되기 위해서는 최소 30개국이상이 참여하여야 하고, 또한 ICANN이 정의한 5개 대륙(유럽, 아태, 북미, 남미, 아프리카)별로 최소한 4개국이 참여하고 있어야 한다. 현재 아태지역 10개국, 북미지역 4개국, 남미지역 13개국, 아프리카 14개국, 유럽 4개국이 참여하고 있다. ccTLD라는 도메인이 특성상 세계 각 국가들의 주권, 정책 및 제도 등과 깊은 이해관계가 얽혀있는 관계로, ICANN의 많은 내부조직들 가운데, 이사회, 정부자문위원회(GAC)와 더불어 ccNSO는 개별국가의 이익이 반영되는 고도의 정치성이 복합적으로 내재되어 있다.

ccNSO는 GNSO와 마찬가지로 정책개발절차(PDP, Policy Development Process)를 두어 ccTLD에 관한 정책을 개발하고 채택된 정책은 ICANN 이사회의 의결을 통해 모든 회원국들에 그 정책이 적용될 예정이다. 그러나, 그 적용을 위해서는 채택된 정책이 각 나라의 법과 제도에 충돌되지 않아야 하며, 관습·종교·공공정책 등 각 나라 고유의 사정에 반하는 경우 DNS운영상의 안정성을 해하지 않는 범위내에서 해당정책의 적용을 배제할 수가 있도록 하고 있다.


ASO는 ICANN과 RIR(대륙별인터넷주소관리기관)들이 체결한 양해각서에 의해 설립된 조직으로 인터넷주소의 운영, 배정 및 관리에 관한 정책문제에 대해 이사회에 자문을 제공함과 동시에 이사 2명의 선출할 수 있는 인사권을 가진다. RIRs는 대륙별 IP 관리기관들인데 아태지역은 APNIC(Asia Pacific Network Information Centre), 북미지역은 ARIN(American Registry for Internet Numbers), 유럽은 RIPE NCC(Réseaux IP Européens Network Coordination Centre), 남미는 LACNIC(Latin American and Caribbean Internet Addresses Registry), 아프리카는 AfriNIC 등 5개의 RIR들로 구성되어 있으며, 각 대륙별로 3명의 위원을 선임하여 총 15명의 ASO 위원이 활동하고 있다. ASO는 매년 최소 1회 이상의 정기회의를 갖고 있는데, 현재 한국은 한국인터넷진흥원의 권현준 대외협력팀장이 APNIC 대표로 ASO위원으로 선출되어 2006년까지 활동할 예정이다. ASO는 조직도상으로 ICANN 내부의 Supporting Organization으로 구성되어 있으나, 그 활동은 도메인이름관련 지원조직들에 비하여 상당히 독립적이다.


GNSO는 .com, .net 등 일반최상위도메인이름 관련정책을 개발하여 이를 이사회에 개진하는 역할을 수행한다. ccTLD와 달리 gTLD는 국가별 구분을 갖지 않고 있어, GNSO는 gTLD 이용자들을 gTLD 레지스트리, gTLD 레지스트라, ISP(Internet Service Provider), 상업 및 기업사용자, 지적재산권 관련자, 비상업사용자 등 6개의 그룹으로 구분하여 각 그룹에서 3명, 그리고 Nominating Committee에서 6명을 선출하여 GNSO 평의회를 구성하여 주요 gTLD 관련정책을 심의 및 개발토록 하고 있다. ccNSO와 마찬가지로 내부의 PDP절차를 거쳐 채택된 정책은 최종적으로 ICANN 이사회의 의결을 거치게 된다. ccTLD가 국가적 이해관계가 강하여 공공의 이익을 우선시하는 반면, gTLD는 다소 상업적 측면이 강한 측면에서 그 정책 참여자들의 성격이 다른 것이다.

다. 기타 조직

● Nominating Committee

ICANN의 주요의사결정에 있어서 다양한 이해관계자들의 참여를 증진하기 위하여 2002년 12월 정관개정이후 새로이 등장한 Nominating Committee는 그 구성과 역할에 있어서 다양성을 추구하고 있다. 먼저 그 구성을 살펴보면, Nominating Committee는 총 17명의 의결권 있는 위원과 5명의 무의결권 위원으로 구성되어 있는데, 의결권 있는 위원의 경우에는 ALAC에서 5명을 선출하고 GNSO대기업사용자, GNSO소기업사용자, GNSO gTLD 레지스트리, GNSO gTLD 레지스트라, GNSO ISPs, GNSO.지적재산권, GNSO 비상업이용자에서 선정한 소비자시민단체등의 그룹, ccNSO 평의회, ASO 평의회, IETF, TLG, 이사회 등이 각 1명씩 선출하고 있다. 한편, 무의결권 위원은 이사회에서 임명하는 의장, Nominating Committee 전임의장인 고문,  RSSAC(Root Server System Advisory Committee), GAC(Governmental Advisory Committee), SAC(Security and Stability Advisory Committee)에서 각 1명씩의 Liaison(리에종)을 선출하고 있다. 이렇게 구성된 Nominating Committee는 이사회를 비롯한 정관상 규정하고 있는 ICANN의 주요기관 인사들(의결권 있는 이사 8명, ccNSO, GNSO 평의회위원 각 3명, ALAC(At-Large Advisory Committee)위원 5명)의 선출을 주 업무로 하고 있다.

그 동안 ICANN은 그 의사결정이 과연 전세계 인터넷이용자들의 의견을 잘 반영하고 있는가 등 그 대표성 여부가 많은 논란의 대상이 되어왔다. 이를 인식한 ICANN이 자구적 차원에서 다양한 분야에 있는 인사의 참여를 꾀함과 동시에 대표성의 문제점을 보완하기 위한 개혁적 노력으로 Nominating Committee를 신설하였다.

● 정부자문위원회(GAC, Governmental Advisory Committee)

ICANN 활동 중 정부측 관심사항 즉, ICANN의 정책과 정부법률, 국제협약 및 공공정책과의 상호관계에 대해 검토 및 자문을 수행하고 이와 관련한 새로운 정책개발 또는 기존의 정책 수정 등의 의견개진을 이사회에 직접 할 수가 있다. 회원자격은 모든 국가정부에 개방되어 있고, EU와 같이 국제사회에서 인정되는 독립경제단위, 다국적정부기구 및 조약기구는 GAC의 초청으로 옵서버로 가입될 수가 있는데, 현재 WIPO, EU, ITU 등이 가입되어 있다.  GAC은 단순한 자문기구의 역할이외에도 이사진에 투표권이 없는 리에종(liaison)으로 참석하도록 되어있고, ICANN이 제시하는 정책 및 활동에 대한 보고를 받도록 되어있다. 또한 ccTLD의 위임 및 재위임에 관한 원칙을 문건화하는 GAC 내부문서를 작성하는 등 ccTLD의 관리 및 운영에 대하여 정부의 입지를 넓혀나가고 있다. 그러나 이러한 GAC의 적극적 움직임에 대해 ccNSO측에서는 그 동안 자율적으로 민간에서 운영해왔던 각 국의 도메인 관리 기관들에 대한 견제로 이해하는 우려의 목소리가 없지 아니하다.  물론 국가 도메인이니 만큼 각 국 정부의 입장을 고려해야 할 필요성에 대하여는 공감을 하지만 지나친 정부의 간섭은 민간 자율적 성격을 지닌 인터넷 도메인 관리 기능을 경직시킬 수 있다는 우려를 나타내고 있는 것이다.

● 정책결정의 투명성 보장제도

ICANN은 그 운영의 투명성과 그 책임을 보완하기위해 옴부즈맨사무국(Office of Ombudsman), 재심의정책(Reconsideration Policy), 독립심사정책(Independent Review Policy) 등 다양한 제도를 두고 있는데, 옴부즈맨사무국은 ICANN직원, 이사회, 또는 그 구성기관에 의한 부당한 행정처리에 대한 민원사항을 처리하는 ICANN 내부의 독립적인 기관이다. 옴부즈만은 공정성의 객관적 중재자로서 ‘shuttle diplomacy' 방식을 사용하여 공정한 해결을 이끌어낸다. 옴부즈만은 이사회에서 선임되며, 임기는 2년으로 재심의정책, 독립심사정책과 함께 ICANN의 업무수행관련 민원 등에 대한 분쟁해결의 역할을 수행한다. 재심의정책은 ICANN의 정책과 어긋나는 임직원의 활동으로 인하여 중대한 영향을 받은 개인 또는 기관이 관련 활동에 대한 재검토를 요청하는 제도로서 ICANN의 업무수행에 대한 투명성과 공정성을 제고하기 위한 제도적 장치이다. 이러한 민원이 제기되면 이사회는 3명이상의 이사로 구성되는 재심위원회(Reconsideration Committee)를 구성하여 문제되는 사안을 재검토하게 된다. 한편, 재심의절차가 ICANN 스스로 자신의 업무활동에 대한 재검토절차라면, 외부의 중립기관에 의한 ICANN 정책을 재심의 하는 절차가 바로 독립심사정책이다. 이는 ICANN이 지정하는 외부의 중립기관에서 ICANN 활동관련 민원에 대한 해결을 위임하는 제도이다.

ICANN은 위에서 살펴본 내부조직 외에도 일반인터넷이용자의 권익에 관한 사항을 이사회에 자문하는 인터넷이용자그룹자문위원회(ALAC, At Large Advisory Committee), 루트서버의 운영에 관한 자문을 하는 루트서버시스템자문위원회(RSSAC, Root Server System Advisory Committee), DNS의 보안과 안정성에 관해 자문을 하는 SAC(Security and Stability Advisory Committee) 등을 두고 있다.

2절. ICANN과 인터넷거버넌스

인터넷은 컴퓨터간의 통신을 가능하게 하는 인터넷주소 네트워크로서 도메인이름시스템(DNS)에 기초하고 있는 까닭에, 도메인이름시스템을 누가 통제하느냐 하는 것은 결국 인터넷을 누가 통제하고 관리할 수 있는가를 의미한다. 오프라인상의 제일 중요한 석유자원을 얻기 위해 미국, 중국 등 강대국들이 힘겨루기를 하고 있는 것처럼 온라인상의 가장 핵심기반인 인터넷주소 관리체계를 중심으로 이루어지는 미국과 중국간의 정책적 대립이 국제사회에서 전개되고 있다.

도메인이름시스템은 인터넷프로토콜(IP) 숫자와 도메인이름을 기본 구성요소로 하여 일반사용자가 입력한 도메인이름을 고유의 IP 숫자로 변환해 주는 시스템으로 정의될 수가 있다. 모든 컴퓨터는 각각 유일한 IP 숫자를 가지고 있으며, 도메인이름은 이런 IP 숫자에 일 대 일로 지정되어 주소로서의 유일성을 확보하게 되고 우리는 이러한 도메인이름을 통하여 사이버세계의 풍요로움을 누릴 수 있게 되는 것이다. 일반 인터넷이용자측면에서는 인터넷을 빠르고 편하게 이용할 수 있다는 사실에 만족하지만, 인터넷거버넌스 측면에서는 국가간 이해관계와 밀접한 관련을 가진다.

1. 루트서버의 일방적 관리

국제사회에서 개도국을 포함한 상당수의 국가들이 ICANN 중심의 국제인터넷주소자원관리체계에 대해 많은 정보를 가지고 있지 않으며, 나아가 자국의 ccTLD의 생성, 위임 등이 해당 국가 정부의 통제 하에 있지 아니하고 미국 상무성(DOC, Department of Commerce)의 영향력 아래에 있음을 인식하지 못하고 있다.

현 도메인이름체계는 루트를 정점으로 한 계층적 구조로, 전 세계에 배치된 13개 루트서버 운영자들은 일반최상위도메인(gTLD, generic Top Level Domain) 및 ccTLD 등 모든 258개의 TLD가 포함된 루트존파일을 관리하고 있다.  루트서버는 전 세계에는 13개가 배치되어 있고, 그중에 10개의 루트서버가 미국 내에 위치하고 있다 전 세계에 배치된 루트서버 운영현황 (출처 :
Dulles, VA, US
Marina del Rey, CA, US
Herndon, VA, US
College Park, MD, US
Mt View, CA, US
Palo Alto, CA, US
Vienna, VA, US
Aberdeen, MD, US
Stockholm, Sweden
Dulles, VA, US
London, UK
Marina del Rey, CA, US
Tokyo, Seoul

. 이러한 미국편중적인 루트서버의 배치는 인터넷이 미국에서 개발되었다는 역사적인 배경과 기술적 요소 등 현실적인 이유에서 기인한다고 하더라도, 지나치게 불평등하다는 다소 불만어린 목소리가 제기되기 시작했었고, 이러한 지역적 불균형적인 배치를 해소하기 위하여 2003년부터 22개국에 루트서버의 복사본("cloned" root server)을 배치하는 ‘anycast' 방식이 실행되었다. 그러나 이러한 형식적인 분산배치조치는 루트서버의 통제권을 여전히 미상무성이 갖고 있다는 관리실상을 인식하고 있는 측면에서 본다면 그리 만족스러운 사항은 아닐 것이다.

루트서버시스템은 하나의 상위서버인 A와 나머지 B~M까지의 하위서버로 구성되어져 있고 상위 네임서버의 최초 이름 : ns.internic.net에서 후에 a.Root-servers.net으로 변경
  여러 개의 하위 네임서버의 이름: 다양한 이름에서 후에 ~ m.Root-servers.net으로 변경
, A 루트서버만이 원본을 가지고 있었으나, 2002년 말 이후에는 테러방지 등을 이유로 히든상위서버(Hidden Primary Server)를 중심으로 하고 A를 포함한 13개의 루트서버를 하위서버로 두는 체계 현 루트서버시스템 구조도
Distribution Master(Hidden Primary)
Zone-File Generation

... ... ... ... ... ... ...

로 변환하였다. 인터넷은 인터넷주소를 기반으로 이루어지고 있고, 이러한 인터넷주소를 관리하는 도메인이름시스템을 통제한다는 것은 전 세계 인터넷을 통제하는 것임을 상기한다면, 2002년 이전에는 A루트서버를, 그 이후에는 히든상위서버를 미국상무성이 통제하고 있는 것이 얼마나 중요한 현실인지를 깨달을 수가 있을 것이다. 즉, 미국상무성은 다른 어떤 나라의 ccTLD도 인터넷에서 사라지게 할 수 있는 능력을 가지고 있으며, 인터넷 의존도가 점점 높아지고 있는 현실을 감안할 때, 미국이 갖는 인터넷관련 국제적 협상력은 일반 인터넷이용자들의 상상을 초월하는 것일 것이다. 바로 이러한 점이 많은 국가들로 하여금 현 미국중심의 ICANN체제를 재고하게 만드는 까닭일 것이다. 

2. 미 상무성의 TLD 위임에 대한 최종 결정권

.kr이 한국정부의 소유가 아니고, .kr의 관리기관을 선정함에 최종결정권을 한국정부가 아닌 미국정부가 가지고 있다고 말한다면 일반인들은 그냥 그것은 하나의 가정일 것이라고 여길 것이다. 하지만 사실 이것은 아무생각 없이 내뱉은 말이 아니라 현재 전 세계의 도메인이름이 관리되고 있는 현실인 것이다. 미상무성은 ICANN과 전 세계 주소자원의 관리를 위한 계약을 체결하고 있는데, 이에 따르면 ICANN은 미상무성의 허가 없이는 ‘TLD의 위임 TLD의 위임이란 해당 TLD를 누가 관리할 것인가를 정하는 것으로, ICANN은 상무성의 통제아래 gTLD와 ccTLD들의 관리자를 지정해왔는데, 과거에는 IANA D/B상의 Administration Contact에 지정된 자연인을 관리자로 보는 경향이 있었으나, 현 ICANN 정관은 TLD의 관리자를 IANA D/B에 Sponsoring Organization으로 지정된 관리기관으로 정의하고 있음,(참조 ICANN 정관 IX Section 4.1)
및 재위임과 관련한 존파일 정보의 수정, 첨가, 삭제 등’을 수행할 수가 없다.
물론 여기서 말하는 TLD에는 .com, .net 등의 gTLD와 전 세계 모든 나라의 ccTLD가 다 포함되어 있다. 다시 말하면, 미국상무성은 gTLD는 물론 전 세계 국가최상위도메인인 ccTLD의 위임 등에 대한 최종결정권을 가지고 있음을 의미한다. 많은 정부들은 자국의 ccTLD를 공공자산으로 인식하고 있고, 자신들이 통제할 수 있는 것으로 인식하고 있으나 현 도메인이름시스템을 고려해 볼 때 그것은 기술상 불가능하고 이러한 현실을 인식한 많은 국가들은 현 도메인이름시스템에 자신의 주권이 미치지 않는 영역이라는 사실을 불편해하고 있다. 그리고 상당수의 ccTLD 위임의 경우, 관련정부가 인식하기 이전에 ccTLD 관리자가 지정되기도 하여 현재의 정부가 직접 관리를 원하거나 다른 적당한 관리자에게 이전하려는 경우에 기존의 관리자와의 분쟁이 발생하기도 한다. 또한 TLD의 관리자로 위임받은 자는 TLD의 관리책임을 맡은 위탁관리자에 불과한데, 위임받은 자는 자신의 소유인 것으로 착각하는 사례도 적지 않았다. 이러한 미국이라는 한 나라의 독단으로 좌지우지되는 현 국제인터넷주소관리체계는 정책적 중립성을 보장할 수가 어렵다는 인식이 확대되고 있고, 이러한 이유가 중심이 되어 2003년 제1차 정보사회정상회의(WSIS회의)에서 중국, 아랍국들, 아프리카 등 많은 개발도상국들이 반대적 입장을 표명하고, 특히 ccTLD의 경우에는 국가의 주권적 이해관계가 분명히 있는 공공자원임을 강조하고 있고, ICANN이라는 민간기구보다는 ITU와 같은 UN산하의 보다 중립적인 정부간조직(Intergovernmental Organization)에 의해 관리되어져야 한다고 주장하고 있는 것이다.  

3. IP 주소의 국제적 불평등 배정

IP 주소는 인터넷에 연결된 컴퓨터 단말기에 유일하게 할당되어 사용되는 인터넷주소로서 현 IPv4 주소체계는 42억 개 정도의 한정된 주소자원을 보유하고 있으며, 이는 미래 인터넷이용을 감안할 때 충분한 수량이 아님을 누구나 짐작할 수 있을 것이고 이를 대비하여 현재 새로운 숫자주소체계인 IPv6가 점차적으로 도입되고 있다. 2003년 12월의 정보사회정상회의(WSIS)에서는, IPv4 주소의 80%가 북미지역에 편중 배정·할당되어 있음을 지적하면서 많은 비판이 제기되었었다. 인터넷이용초기에 초기 인터넷관련 프로젝트에 관여했던 IT 장비업체, ISP업체, 대학교 및 연구소에 배정되었으며 이 당시에 배정된 IP주소는 전체 IPv4주소의 약 55%에 달하였다. 이러한 불균형을 해소하기 위하여 대륙별 주소배정시스템이 1990년 초에 도입이 되었는데, 이것이 바로 대륙별주소관리기구들(RIRs, Regional Internet Registries) ICANN은 정책수립 시 의견수렴을 위해 전 세계를 통상 5대륙(북미, 남미, 아·태, 유럽, 아프리카)으로 구분해 오고 있다. 현재 유럽-RIPENCC, 아태-APNIC, 북미-ARIN, 남미-LACNIC, 아프리카-AfriNIC이 설립되어 있다.
의 생성배경인 것이다. 1999년 이후 배정된 IPv4 주소를 대륙별로 살펴보면, APNIC(32%), RIPE NCC(29%), ARIN(37%), LACNIC(2%)에 달하고 있어, 아·태, 유럽, 북미지역 등에 고르게 편중된 듯이 보이나, 1995년 이전에 북미대륙에 편중되어 배정된 IP 주소를 회수하여 타 대륙에 재배정하는 문제는 현재 RIR들이 함께 노력해야할 국제적 과제일 것이다.
IP주소의 배정 및 할당 관련하여 RIR들은 ICANN과의 정책적 연계관계를 가지고 있다. RIR들은 ICANN 구조 내에 ASO(Address Supporting Organization)를 구성하고 ICANN 이사진중 일부를 선임하여 IP주소의 배정에 대한 글로벌정책이슈에 대한 정책적 영향력을 행사하고 있다. 최근에는 RIR들이 숫자자원기구(NRO, Number Resource Organization)를 설립(2003. 10. 24)하였는데, NRO의 설립취지를 살펴보면, 현재 ICANN 존립자체가 정보사회정상회의에서 이슈로 논의되는 등 불안정한 상황이 제기되고 있어서 보다 안정적인 숫자자원의 수급을 위한 조직이 필요하기 때문이라고 주장하고 있으나, 실질적으로 RIR들은 ICANN에 의한 직·간접적인 정책개발 과정을 견제하고, 그 영향력에서 벗어나고자 하는 의도가 내재되어 있다고 보여 진다. 이러한 NRO의 등장과 역할에 대해 우려를 갖고 있는 시각이 없는 것은 아니다. ICANN 내 각국 정부의 인터넷정책 관련부처 공무원으로 구성된 정부자문위원회(GAC, Governmental Advisory Committee)의 경우, NRO의 등장에 대하여 우려의 목소리를 내고 있다. 지금까지 GAC은 ICANN의 제반 정책수립과정에 자국의 입장을 전달하여 도메인이름은 물론 IP 주소정책에까지 어느 정도 영향력을 행사하고 있었으나, IP 주소 관련정책에 관한 사항이 NRO로 이전되는 경우, 이는 ICANN의 영향력아래에서 제외되는 것일 뿐만 아니라 GAC의 영향력에서도 제외됨을 의미하는 것이기 때문이다. 많은 국가들이 도메인이름과 IP 주소를 중요한 국가자원으로 인식하고 있는 상황 하에서 자국의 영향력이 배제된 신생조직이 중요한 IP 주소자원의 주요정책결정권을 가진다는 사실에 대해 GAC 회원들은 반가와 할 까닭이 없는 것이다.

4. DOC/ICANN 관리체제 vs. 정부간국제기구 관리체제

지금까지 ICANN과 미상무성(DOC) 중심의 인터넷주소 관리체계의 문제점들을 살펴보았듯이 정보사회정상회의(WSIS)에서도 인터넷주소자원을 둘러싼 거버넌스는 주요 쟁점이슈이다. 많은 국가들이 현재의 인터넷거버넌스 메커니즘에 대해 회의적인 입장을 표명하고 있으며, ITU와 같은 UN산하의 국제기구에서 관리되어 진다면, 인터넷주소자원에 대한 글로벌 정책의 형평성과 중립성을 보장받을 수 있을 것이라고 의견을 제시하고 있다. 이처럼 인터넷주소자원에 대한 거버넌스 매커니즘에 대한 입장은 현 체제를 지지하는 견해와 새로운 정부간국제기구 중심의 관리체계를 대안으로 제시하는 견해로 대별될 수가 있다.

먼저 미국, 호주, 일본 등 IT 선진강국들은 기존의 미상무성과 ICANN 중심의 관리체제를 지지하고 있으며, 인터넷은 역사적으로 민간의 자율규제를 통해 성공적으로 발전해왔으며, 이러한 발전은 정부의 간섭이 배제된 민간의 영역에 맡겨둘 때 효율적인 관리가 이루어진다는 입장을 지지하고 있다. 이들은 인터넷의 발전을 위해 민간기구들, 특히 ICANN은 그 책무를 성실히 수행해왔고, 지금도 신뢰할 만한 단체임을 지지하고 있는 것이다. 그러나 ICANN이 민간비영리법인이기는 하나, 미상무성과의 계약에 의해 주요정책사안은 통제를 받고 있으며, 실례로 2005년 8월 .xxx의 생성이 ICANN에 의해 승인되었으나, 미상무성에 의해 보류되었다. 이러한 상황을 고려해 볼 때, 과연 ICANN이 진정한 민간에 속하는 조직인지에 대해 많은 회의적 의견이 도출되고 있으며, DNS에 대한 미국의 이러한 영향력에 대해 많은 국가들은 현 거버넌스 체제에 대한 반대 입장으로 옮겨가고 있다.

한편, 중국, 유럽연합, 남아공화국, 브라질, 아랍국가들 등 상당수의 개발도상국들은 DNS 등 인터넷 주소자원 관련 글로벌 정책을 수립은 국제적 협치를 통해 논의되어야 할 사안임에도 불구하고 어떤 한나라에 의해 주도된다는 사실은 납득하기 어렵다는 입장을 견지하고 있다. 따라서 UN산하의 정부간국제기구에 의해 많은 이해당사국이 참여하여 중립적이고 개방적인 정책개발절차가 보장되어야 한다는 이들의 주장은 미국정부의 이해관계와 정면으로 배치되고 있는 실정이다. 그리고 지금까지는 인터넷이 그 탄생 초기에는 규모와 정치, 사회, 경제적 영향력이 크지 않았고 전문적인 기술측면이 강조되어 민간전문가가 주도적으로 활동하여왔고, 큰 문제가 없었다고 볼 수 있으나, 이제는 도메인이름, IP 주소, DNS 등 인터넷주소 자원이 미치는 인간사회 전반에 엄청난 영향을 미치는 글로벌 공공자원임을 고려해 볼 때 더 이상 한 국가에 의해서 관리되어지기 보다는 모든 정부들이 함께 그 책임을 나누고 서로 협의하여 관리되어져야 한다는 사실을 강조하고 있다.

5. 결어

인터넷은 미국이 군사적 목적으로 정부주도하에 몇몇 민간 전문가들과 함께 추진한 미국 연방정부 프로젝트의 산출물인 까닭에 아직도 미국 내에서는 인터넷을 국가안보차원에서 바라보는 시각이 없지 아니하며, 미국의 국익과 밀접한 관련을 가지는 것으로 인정하고 있음을 ICANN의 생성과 미상무성과의 관계 등에서 찾아볼 수가 있다. 물론 미국 내에서도 이러한 미국의 일방적 DNS 관리가 향후 사설 DNS의 등장을 야기하고 나아가 인터넷의 분열을 초래할 수 있음을 경고하는 목소리 또한 존재하고 있다.

지금까지 살펴본 현재의 DOC/ICANN 중심의 거버넌스 메커니즘에 대한 문제점들은 지난 2005년 11월에 개최된 제2차 정보사회정상회의(WSIS)에서 다루어 졌었는데, 유럽연합, 중국, 브라질, 남아공화국, 이란, 사우디아라비아 등 상당수의 국가들은 현 체제에 대한 개선안을 제시하며 미국에 대한 공세를 펼쳤으나, 미국을 지원한 국가들과 시민단체들의 반대에 부딪히며 끝내 합의에 이르지 못하고 현 체제가 유지되는 방향으로 매듭지어졌다. 그 외에 WSIS에서 합의된 주요사항을 살펴보면, 먼저 인터넷 거버넌스 포럼(IGF, Internet Governance Forum)의 등장을 들 수 있을 것이다. IGF는 유엔 사무총장의 주도하에 설립 추진이 개시될 예정이며, 주관기관은 수년 동안 WSIS를 준비해온 전문성을 인정받아 ITU가 맡을 가능성이 가장 크다. 앞으로 5년에 걸쳐 운영될 IGF는 인터넷 거버넌스에 대한 관리감독기능을 가지지 않는 단순한 자문기구의 역할만을 가진 한계 때문에 그 실효성에 대해서는 의문을 제기하는 의견이 많지만, 인터넷 주요 공공정책 이슈에 대해서 정부, 민간, 시민사회 등이 함께 모여 국제적으로 논의할 수 있는 장이 마련되었다는 점에서 그 의의를 찾을 수 있을 것이다. 이번 WSIS에서의 또 다른 주목할 만한 합의사항으로는 ‘ccTLD의 관련 결정에 대해 해당 국가이외 다른 국가가 관여해서는 아니 된다’를 들 수 있다. 현재는 미국 상무성이 ccTLD 위임에 관하여 최종 결정권을 가지고 있지만 앞으로 이에 관한 미국의 권한행사를 제한하는 절차가 마련되어져야 할 것이다. 또한 ICANN 관련하여 그간의 WSIS 논의과정에서 거론된 정부의 역할 강조 및 인터넷 정책형성과정상에서의 투명성과 민주성의 보장 등의 외부의 요구를 충족시켜주기 위하여 ICANN 내부에서 개혁의 움직임이 있을 것으로 예상된다. 현재 ICANN 내부에 있는 정부자문위원회의 역할에 무게를 더 하는 방향으로 개선 움직임이 있을 수 있으며, 다른 국가들의 의구심을 해소하기 위하여 현재 미상무성이 가지는 ICANN에 대한 영향력은 어느 정도는 약화되지 않을까 하는 추측도 가능하다. 그리고 미국이 관리하는 현 DNS 체제를 반대하는 국가와 기업들을 중심으로 이미 진행되고 있는 별도의 사설 DNS 운영관련 활동이 힘을 받을 것으로 전망되고 있다.

우리는 이렇게 급변하는 인터넷 거버넌스 패러다임의 변화 속에서 우리 인터넷이용자들과 국가의 이익을 보전하기 위하여 ITU, IGF, ICANN 등에 대한 인터넷 거버넌스관련 국제정책동향에 대한 명확한 분석 및 지속적 연구 활동이 필요하며, ICANN은 물론 앞으로 형성될 IGF에 적극 참여하여 인터넷 강국으로서 국제정책형성과정에 선도적 위치를 점하기 위해 노력해야 할 것이다. 앞으로의 인터넷 거버넌스에 대한 국제적 논의는 정부뿐만이 아니라 민간부문의 참여가 중요하며, 이에 필요한 우리 민간의 국제적 역량을 신장하기 위해 정부는 장기적인 관점에서 많은 지원을 감당해야 할 것이다. 또한, 현 DNS의 기술적 문제점을 인식하여 불안한 외부환경에 좌우되지 않는 안정적이면서도 자주적이고 고도화된 인터넷 사용기반을 마련하기 위한 기술연구와 인프라 구축이 뒤따라야 함은 다언을 요하지 아니할 것이다. <- 이곳에서 퍼왔습니다.

사내 교육용 자료를 찾던도중 관심이 가는 부분이라. 생각지도 못하게 퍼왔네요.

Comment +0

Index by TLD Code



























.ac  –  Ascension Island
.ad  –  Andorra
.ae  –  United Arab Emirates
.af  –  Afghanistan
.ag  –  Antigua and Barbuda
.ai  –  Anguilla
.al  –  Albania
.am  –  Armenia
.an  –  Netherlands Antilles
.ao  –  Angola
.aq  –  Antarctica
.ar  –  Argentina
.as  –  American Samoa
.at  –  Austria
.au  –  Australia
.aw  –  Aruba
.az  –  Azerbaijan
.ax  –  Aland Islands
.ba  –  Bosnia and Herzegovina
.bb  –  Barbados
.bd  –  Bangladesh
.be  –  Belgium
.bf  –  Burkina Faso
.bg  –  Bulgaria
.bh  –  Bahrain
.bi  –  Burundi
.bj  –  Benin
.bm  –  Bermuda
.bn  –  Brunei Darussalam
.bo  –  Bolivia
.br  –  Brazil
.bs  –  Bahamas
.bt  –  Bhutan
.bv  –  Bouvet Island
.bw  –  Botswana
.by  –  Belarus
.bz  –  Belize
.ca  –  Canada
.cc  –  Cocos (Keeling) Islands
.cd  –  Congo, The Democratic Republic of the
.cf  –  Central African Republic
.cg  –  Congo, Republic of
.ch  –  Switzerland
.ci  –  Cote d'Ivoire
.ck  –  Cook Islands
.cl  –  Chile
.cm  –  Cameroon
.cn  –  China
.co  –  Colombia
.cr  –  Costa Rica
.cs  –  Serbia and Montenegro
.cu  –  Cuba
.cv  –  Cape Verde
.cx  –  Christmas Island
.cy  –  Cyprus
.cz  –  Czech Republic
.de  –  Germany
.dj  –  Djibouti
.dk  –  Denmark
.dm  –  Dominica
.do  –  Dominican Republic
.dz  –  Algeria
.ec  –  Ecuador
.ee  –  Estonia
.eg  –  Egypt
.eh  –  Western Sahara
.er  –  Eritrea
.es  –  Spain
.et  –  Ethiopia
.eu  –  European Union
.fi  –  Finland
.fj  –  Fiji
.fk  –  Falkland Islands (Malvinas)
.fm  –  Micronesia, Federal State of
.fo  –  Faroe Islands
.fr  –  France
.ga  –  Gabon
.gb  –  United Kingdom
.gd  –  Grenada
.ge  –  Georgia
.gf  –  French Guiana
.gg  –  Guernsey
.gh  –  Ghana
.gi  –  Gibraltar
.gl  –  Greenland
.gm  –  Gambia
.gn  –  Guinea
.gp  –  Guadeloupe
.gq  –  Equatorial Guinea
.gr  –  Greece
.gs  –  South Georgia and the South Sandwich Islands
.gt  –  Guatemala
.gu  –  Guam
.gw  –  Guinea-Bissau
.gy  –  Guyana
.hk  –  Hong Kong
.hm  –  Heard and McDonald Islands
.hn  –  Honduras
.hr  –  Croatia/Hrvatska
.ht  –  Haiti
.hu  –  Hungary
.id  –  Indonesia
.ie  –  Ireland
.il  –  Israel
.im  –  Isle of Man
.in  –  India
.io  –  British Indian Ocean Territory
.iq  –  Iraq
.ir  –  Iran, Islamic Republic of
.is  –  Iceland
.it  –  Italy
.je  –  Jersey
.jm  –  Jamaica
.jo  –  Jordan
.jp  –  Japan
.ke  –  Kenya
.kg  –  Kyrgyzstan
.kh  –  Cambodia
.ki  –  Kiribati
.km  –  Comoros
.kn  –  Saint Kitts and Nevis
.kp  –  Korea, Democratic People's Republic
.kr  –  Korea, Republic of
.kw  –  Kuwait
.ky  –  Cayman Islands
.kz  –  Kazakhstan
.la  –  Lao People's Democratic Republic
.lb  –  Lebanon
.lc  –  Saint Lucia
.li  –  Liechtenstein
.lk  –  Sri Lanka
.lr  –  Liberia
.ls  –  Lesotho
.lt  –  Lithuania
.lu  –  Luxembourg
.lv  –  Latvia
.ly  –  Libyan Arab Jamahiriya
.ma  –  Morocco
.mc  –  Monaco
.md  –  Moldova, Republic of
.mg  –  Madagascar
.mh  –  Marshall Islands
.mk  –  Macedonia, The Former Yugoslav Republic of
.ml  –  Mali
.mm  –  Myanmar
.mn  –  Mongolia
.mo  –  Macau
.mp  –  Northern Mariana Islands
.mq  –  Martinique
.mr  –  Mauritania
.ms  –  Montserrat
.mt  –  Malta
.mu  –  Mauritius
.mv  –  Maldives
.mw  –  Malawi
.mx  –  Mexico
.my  –  Malaysia
.mz  –  Mozambique
.na  –  Namibia
.nc  –  New Caledonia
.ne  –  Niger
.nf  –  Norfolk Island
.ng  –  Nigeria
.ni  –  Nicaragua
.nl  –  Netherlands
.no  –  Norway
.np  –  Nepal
.nr  –  Nauru
.nu  –  Niue
.nz  –  New Zealand
.om  –  Oman
.pa  –  Panama
.pe  –  Peru
.pf  –  French Polynesia
.pg  –  Papua New Guinea
.ph  –  Philippines
.pk  –  Pakistan
.pl  –  Poland
.pm  –  Saint Pierre and Miquelon
.pn  –  Pitcairn Island
.pr  –  Puerto Rico
.ps  –  Palestinian Territories
.pt  –  Portugal
.pw  –  Palau
.py  –  Paraguay
.qa  –  Qatar
.re  –  Reunion Island
.ro  –  Romania
.ru  –  Russian Federation
.rw  –  Rwanda
.sa  –  Saudi Arabia
.sb  –  Solomon Islands
.sc  –  Seychelles
.sd  –  Sudan
.se  –  Sweden
.sg  –  Singapore
.sh  –  Saint Helena
.si  –  Slovenia
.sj  –  Svalbard and Jan Mayen Islands
.sk  –  Slovak Republic
.sl  –  Sierra Leone
.sm  –  San Marino
.sn  –  Senegal
.so  –  Somalia
.sr  –  Suriname
.st  –  Sao Tome and Principe
.sv  –  El Salvador
.sy  –  Syrian Arab Republic
.sz  –  Swaziland
.tc  –  Turks and Caicos Islands
.td  –  Chad
.tf  –  French Southern Territories
.tg  –  Togo
.th  –  Thailand
.tj  –  Tajikistan
.tk  –  Tokelau
.tl  –  Timor-Leste
.tm  –  Turkmenistan
.tn  –  Tunisia
.to  –  Tonga
.tp  –  East Timor
.tr  –  Turkey
.tt  –  Trinidad and Tobago
.tv  –  Tuvalu
.tw  –  Taiwan
.tz  –  Tanzania
.ua  –  Ukraine
.ug  –  Uganda
.uk  –  United Kingdom
.um  –  United States Minor Outlying Islands
.us  –  United States
.uy  –  Uruguay
.uz  –  Uzbekistan
.va  –  Holy See (Vatican City State)
.vc  –  Saint Vincent and the Grenadines
.ve  –  Venezuela
.vg  –  Virgin Islands, British
.vi  –  Virgin Islands, U.S.
.vn  –  Vietnam
.vu  –  Vanuatu
.wf  –  Wallis and Futuna Islands
.ws  –  Samoa
.ye  –  Yemen
.yt  –  Mayotte
.yu  –  Yugoslavia
.za  –  South Africa
.zm  –  Zambia
.zw  –  Zimbabwe

Comment +0

< 서론 >
1탄에서 ICANN이 하는 역활과 그에 대한 내용을 간략하게 확인 하였습니다. 그럼 거기서 나온 TLD라는게 궁금해 질 것입니다. 1탄의 참조에 간략하게 적어놓은것 처럼 최상위 도메인을 나타냅니다. 단순히 최상위 도메인이라고만 알고 넘어가면 너무 간단하겠지만, 최상위 도메인은 다시 2개의 구성으로 쪼갤 수 있습니다. 그에 대한 내용을 아래에서 확인 할 수 있습니다.

< 본론 >
최상위 도메인(TLD : Top Level Domain)은 gTLD와 nTLD로 구분됩니다.
일반 최상위 도메인(gTLD : generic Top Level Domain)은 인터넷 초창기 부터 사용되어온 7개의 도메인을 지칭합니다.

- com : 영리를 목적으로 하는 기업이나 회사
- edu : 학위를 수여하는 교육 기관
- net : 네트워크에 관련된 기관
- org : 비영리 목적의 기관이나 단체
- int : 유엔등의 국제기관
- gov : 미국연방정부 관련 기관
- mil : 미국연방정부 군사기관

gov, mil, edu은 미국내에 있는 기관만이 등록하여 사용 가능하며, int는 유엔 등 국제기구가 등록하여 사용하게 됩니다.

초기에 사용된 7개의 도메인에 2000년 10월 17일 ICANN에서 7개의 도메인을 새로이 추가하였습니다.

- biz : 기업
- name : 개인들이 사용
- info : 종합적으로 사용
- pro : 전문가
- museum : 박물관
- coop : 협회나 조합
- aero : 항공사 전용

현재 운영되고 있는 일반 최상위 도메인(gTLD)는 총 14개 이며, 차후 ICANN에서 일반 최상위 도메인이 포화가 된다면 2000년에 발표한 것과 같이 새로운 일반 최상위 도메인을 발표 할 것입니다.

국가 최상위 도메인(nTLD : national Top Level Domain)은 gTLD와 함께 TLD의 2개 분류에 속합니다. 다른지칭으로 국가 코드 최상위 도메인(ccTLD : country code Top Level Domain)이라고 불리기도 합니다. 한국의 경우에는 .KR, 일본의 경우에는 .JP입니다.
국가 최상위 도메인(이하 국가도메인)은 .KR이나 .JP와 같이 각 국가를 구분하는 1단계와 co(기업 기관), ac(교육기관), go(정부기관), or(비영리기관과 단체), ne(네트워크), pe(개인) 등과 같이 해당 도메인의 성격으로 구분한 2단계 그리고 상호명 또는 상표명을 자유롭게 표현한 3단계로 구분됩니다.

예를 들어을 보면 Direct는 해당 회사의 상호 또는 상표명으로 3단계이며, co는 해당 도메인이 기업의 성격을 띄고 있음을 알려주는 2단계, KR은 해당 도메인이 대한민국에서 운영되고 있는 도메인임을 알려주게 됩니다.

현재 .KR의 경우 한국인터넷진흥원(NIDA)에서 관리를 하고 있으며, 등록업체는 20개 기업에서 등록을 할 수 있으며, 2단계 KR 도메인 등록을 약 7월 말에서 8월사이에 시행할 예정입니다.  따라서 이후부터는 '상호명 또는 상표명.KR' 도메인을 등록해서 사용 할 수 있습니다.

< 참조 > 의 도메인 안내(RFC문서 및 ICANN과의 계약 관계에 대한 가이드라인 등)

Comment +0

< 서론 >
도메인 서비스에 대해서 관심을 갖게 되면서 국제도메인을 등록하려면 ICANN에 자격을 갖춘Registrar로 등록되어야 한다는 말을 자주 듣는다. 그 말들을 들으면서 ICANN이 뭘까 하면서 무의식 중에 한국인터넷진흥원(NIDA)와 비슷한 역활을 하는 국제도메인 등록 최상위 기관이구나 하고 이해하고 넘어갔다. 하지만 이제 이 기관이 무슨 역활을 하는지 짚고 넘어가야 겠다.

< 본론 >
ICANN = The Internet Corporation for Assigned Names and Numbers의 약자이다.

영어로는 ICANN (The Internet Corporation for Assigned Names and Numbers)으로 표기한다. 1998년 6월 미국 정부에서 발간한 《인터넷의 주소의 운영에 관한 백서》에 의해 그해 11월 탄생한 비영리 국제기구이다. 인터넷상에서의 도메인 이름과 IP주소, 프로토콜의 범주와 포트번호를 할당하는 업무를 담당한다. 또한 유명 상표권에 대한 도용 분쟁을 해결하고, 새로운 최상위도메인을 인가하기도 한다. 업무수행을 위해 19명의 이사로 구성된 이사회가 있으며, 그 산하에 도메인보조기구(DNSO; Domain Name Supporting Organization), 주소보조기구(ASO; Address Supporting Organization), 프로토콜보조기구(PSO; Protocol Supporting Organization)를 두고 있다. 2000년에 일반회원으로 구성된 위원회(At Large Membership)를 승인하였다.

이중 이사회는 출발 당시 각 보조기구에서 3인씩 추천을 받은 9인과 그외 5인 등 14인으로 구성되었지만 2000년 11월 일반회원의 선거로 선출된 일반회원 이사 5인이 추가되어 19인으로 구성되어 있다. 도메인보조기구는 인터넷 컴퓨터에 어떤 범위의 숫자를 할당할 것인가를 결정짓는 기구이며, 프로토콜보조기구는 인터넷에 통용되는 기술적 표준들에 대한 업무를 관장하는 기구로, 각 표준 간의 호환성이 가장 큰 관심거리이다. 한편 주소보조기구는 인터넷 도메인네임의 할당 및 관리를 담당하는 기구로, 도메인 자원의 경제적 및 정치적 중요성이 증가되면서 그 역할도 증대되어 핵심기구로 부상하고 있다.

이 기구의 또 하나 중요한 임무는 루트서버(root server)의 안정적 운영을 보장하는 것이다. 루트서버란 .com·.net·.kr·.jp 등과 같은 최상위도메인(Top Level Domain, TLD)을 관리하고 있는 서버가 어디에 있는지에 대한 정보를 저장해 놓고 있는 서버로, 인터넷의 모든 주소찾기가 시작되는 서버이다. 이 서버가 제대로 관리되고 이 서버에 저장되어 있는 지역정보 파일에 오류가 없어야 인터넷 상에서 각 도메인으로 제대로 연결될 수 있다.

< 결론 >
국내에서 운영되고 있는 .kr 마저도 ICANN의 아래에 있음을 확인 할 수 있다. 즉, 도메인을 이용하려거든 ICANN은 필수적인 요소인 것이다. 이러한 ICANN에 대한 자세한 정보가 궁금하다면 아래 사이트를 참조하면 된다.

ICANN 홈페이지 :

< 참조 >
TLD : Top Level Domain의 약자로 최상위 도메인 즉, .COM/.NET/.EDU와 같은 최상위 도메인을 총칭할때 사용된다.
RootServer :  Tree 구조로 되어 있는 인터넷 도메인 네임시스템(DNS: Domain Name System) 계층의 최상위 위치에 있는 DNS 서버이다. 이 서버는 .COM/.NET/.EDU와 같은 최상위 도메인의 공식적인 원본 데이터를 보관하고 있으며, 각 서버들은 미국에 10개, 일본,스톡홀롬,런던에 각각 1개씩 하여 총 13개의 서버로 구성되어 있다. 즉, 어떠한 도메인이든 RootServer를 통하지 않고서는 서버에 연결이 되지 않는 것이다.
- RootServer 정보
  J.ROOT-SERVERS.NET.     330507  IN      A
  K.ROOT-SERVERS.NET.     330507  IN      A
  L.ROOT-SERVERS.NET.     330507  IN      A
  M.ROOT-SERVERS.NET.     330507  IN      A
  A.ROOT-SERVERS.NET.     330507  IN      A
  B.ROOT-SERVERS.NET.     330507  IN      A
  C.ROOT-SERVERS.NET.     330507  IN      A
  D.ROOT-SERVERS.NET.     330507  IN      A
  E.ROOT-SERVERS.NET.     330507  IN      A
  F.ROOT-SERVERS.NET.     330507  IN      A
  G.ROOT-SERVERS.NET.     330507  IN      A
  H.ROOT-SERVERS.NET.     330507  IN      A
  I.ROOT-SERVERS.NET.     330507  IN      A

Comment +0