상위 질문
타임라인
채팅
관점

후이즈

위키백과, 무료 백과사전

Remove ads

후이즈(WHOIS)는 인터넷 자원 등록 사용자 또는 할당자의 데이터베이스를 조회하는 데 사용되는 통신 프로토콜이다. 이러한 자원에는 도메인 네임, IP 주소 블록 및 자율 시스템이 포함되지만, 더 광범위한 다른 정보에도 사용된다. 이 프로토콜은 데이터베이스 내용을 사람이 읽을 수 있는 형식으로 저장하고 전달한다.[1] 후이즈 프로토콜의 현재 버전은 인터넷 협회에서 초안을 작성했으며 RFC 3912에 문서화되어 있다.

후이즈는 대부분의 유닉스 시스템에서 후이즈 프로토콜 쿼리를 수행하는 데 사용되는 명령줄 유틸리티의 이름이기도 하다.[2] 또한 후이즈에는 Referral Whois(RWhois)라는 자매 프로토콜이 있다.

역사

요약
관점

엘리자베스 파인러와 그녀의 팀(아파넷의 자원 디렉터리를 만들었던)은 1970년대 초에 최초의 후이즈 디렉터리를 만든 책임이 있었다.[3] 파인러는 스탠퍼드 대학교의 네트워크 정보 센터(NIC)에 서버를 설치하여 사람이나 단체에 대한 관련 정보를 검색할 수 있는 디렉터리 역할을 하도록 했다.[4] 그녀와 팀은 도메인을 만들었으며, 파인러는 컴퓨터의 물리적 주소를 기반으로 도메인을 범주로 나누자고 제안했다.[5]

등록 절차는 RFC 920에 명시되었다. 후이즈는 도메인, 사람 및 도메인 및 숫자 등록과 관련된 기타 자원을 찾기 위해 1980년대 초에 표준화되었다. 당시 모든 등록은 하나의 조직에 의해 이루어졌으므로, 후이즈 쿼리에는 하나의 중앙 집중식 서버가 사용되었다. 이로 인해 이러한 정보를 찾는 것이 매우 쉬워졌다.

아파넷에서 인터넷이 등장할 당시, 모든 도메인 등록을 처리하던 유일한 조직은 미국 정부의 방위고등연구계획국(DARPA, 1958년 창설[6])이었다. 1980년대에 아파넷이 인터넷으로 전환되면서 도메인 등록 책임은 DARPA에 남아 있었다. UUNET은 도메인 등록 서비스를 제공하기 시작했지만, 단순히 서류 작업을 처리하여 DARPA 네트워크 정보 센터(NIC)로 전달했다. 이후 미국 국립과학재단은 상업적인 제3자 기관이 인터넷 도메인 등록 관리를 담당하도록 지시했다. InterNIC은 1993년에 NSF와의 계약에 따라 네트워크 솔루션, 제너럴 아토믹스 및 AT&T로 구성되어 설립되었다. 제너럴 아토믹스 계약은 몇 년 후 성능 문제로 인해 취소되었다.

20세기 후이즈 서버는 매우 허용적이어서 와일드카드 검색을 허용했다. 사람의 성을 후이즈로 쿼리하면 해당 성을 가진 모든 개인이 반환되었다. 특정 키워드로 쿼리하면 해당 키워드가 포함된 모든 등록 도메인이 반환되었다. 특정 관리 연락처로 쿼리하면 관리자가 연결된 모든 도메인이 반환되었다. 상업 인터넷의 출현 이후 여러 등록 대행자와 비윤리적인 스팸 발송자가 등장하면서 이러한 허용적인 검색은 더 이상 사용할 수 없다.

1999년 12월 1일, 최상위 도메인(TLD)인 com, net, org의 관리는 ICANN에 할당되었다. 이때 이 TLD들은 씬 후이즈 모델로 전환되었다. 기존 후이즈 클라이언트는 이때부터 작동을 멈췄다. 한 달 후, 자체 감지 공용 게이트웨이 인터페이스 지원이 추가되어 동일한 프로그램으로 웹 기반 후이즈 조회를 운영할 수 있게 되었고, 요청의 TLD를 기반으로 여러 후이즈 서버를 지원하는 외부 TLD 테이블도 추가되었다. 이것이 결국 현대 후이즈 클라이언트의 모델이 되었다.

2005년까지는 1980년대 초보다 훨씬 더 많은 일반 최상위 도메인이 존재했다. 또한 훨씬 더 많은 국가 코드 최상위 도메인이 있다. 이로 인해 특히 인터넷 인프라 관리가 더 국제화됨에 따라 도메인 네임 등록 대행자 및 등록 대행자 협회의 복잡한 네트워크가 형성되었다. 따라서 도메인에 대한 후이즈 쿼리를 수행하려면 사용해야 할 올바른 권한 있는 후이즈 서버를 알아야 한다. 후이즈 도메인 검색 도구는 보편화되었으며 IONOS 및 Namecheap과 같은 제공업체에서 제공된다.[7]

CRISP와 IRIS

2003년, 국제 인터넷 표준화 기구 위원회는 도메인 이름 및 네트워크 번호에 대한 정보를 조회하기 위한 새로운 표준인 CRISP(Cross Registry Information Service Protocol)를 만들기 위해 구성되었다.[8] 2005년 1월부터 2006년 7월까지 이 제안된 새 표준의 작업 이름은 인터넷 레지스트리 정보 서비스(IRIS)였다.[9][10] IRIS에 대한 초기 IETF 제안 표준 RFC는 이 문서의 "더 읽어보기" 섹션에서 찾을 수 있다.

이 그룹이 작업한 RFC 상태는 다음에서 확인할 수 있다.

March 2009년 기준 CRISP IETF 워킹 그룹은 그룹에서 최종 RFC 5144가 발행된 후[11] 종료되었다.[12]

참고: IETF CRISP 워킹 그룹은 Number Resource Organization(NRO)의 같은 이름의 팀인 "Consolidated RIR IANA Stewardship Proposal Team"(CRISP 팀)과 혼동해서는 안 된다.[13]

WEIRDS와 RDAP

 이 부분의 본문은 등록 데이터 접근 프로토콜입니다.

2013년, IETF는 IRIS가 후이즈의 성공적인 대체재가 아니었음을 인정했다. 그 주된 기술적 이유는 IRIS의 복잡성으로 보였다. 또한, 비기술적 이유는 IETF가 판단하지 않는 영역에 있다고 여겨졌다. 한편, ARIN과 RIPE NCC는 RESTful 웹 서비스를 통해 후이즈 데이터를 제공하는 데 성공했다. 2012년 2월에 작성된 헌장은 먼저 숫자 레지스트리에 대한 별도의 사양을 제공하고, 이어서 이름 레지스트리에 대한 사양을 제공했다.[14] 이 워킹 그룹은 5개의 제안 표준 문서와 1개의 정보 문서를 작성했다.

Remove ads

프로토콜

요약
관점

후이즈 프로토콜은 ARPANET NICNAME 프로토콜에서 시작되었으며 RFC 742(1977)에 설명된 NAME/FINGER 프로토콜을 기반으로 했다. NICNAME/WHOIS 프로토콜은 SRI 인터내셔널의 네트워크 정보 센터의 켄 해런스타인과 빅 화이트에 의해 1982년 RFC 812에 처음 설명되었다.

후이즈는 원래 네트워크 제어 프로토콜(NCP)에서 구현되었지만, TCP/IP 스위트가 아파넷과 이후 인터넷 전반에 걸쳐 표준화되면서 주요 용도를 찾았다.

프로토콜 사양은 다음과 같다 (원본 인용문):[15]

서비스 호스트에 연결
   TCP: 서비스 포트 43 10진수
   NCP: 소켓 43 10진수로 ICP, 두 개의 8비트 연결 설정
<CRLF>로 끝나는 단일 "명령줄"을 보낸다.
명령줄에 대한 응답으로 정보를 받는다. 서버는
출력이 완료되는 즉시 연결을 닫는다.

명령줄 서버 쿼리는 일반적으로 단일 이름 사양, 즉 리소스의 이름이다. 그러나 서버는 허용 가능한 명령줄 형식에 대한 설명을 반환하기 위해 물음표(?)로만 구성된 쿼리를 허용한다. 와일드카드 형식도 존재한다. 예를 들어 쿼리 이름에 마침표(.)를 추가하면 쿼리 이름으로 시작하는 모든 항목이 반환된다.

현대 인터넷에서 후이즈 서비스는 일반적으로 전송 제어 프로토콜(TCP)을 사용하여 통신된다. 서버는 잘 알려진 포트 번호 43에서 요청을 수신한다. 클라이언트는 서버에 통신 채널을 설정하고, 쿼리할 리소스의 이름이 포함된 텍스트 레코드를 전송하고, 데이터베이스에서 찾은 일련의 텍스트 레코드 형식으로 응답을 기다리는 간단한 응용 프로그램이다. 프로토콜의 이러한 단순성 덕분에 응용 프로그램과 명령줄 인터페이스 사용자는 텔넷 프로토콜을 사용하여 후이즈 서버를 쿼리할 수 있다.

확장

2014년 6월 ICANN은 상태 코드에 대한 권장 사항인 "확장 가능 프로비저닝 프로토콜(EPP) 도메인 상태 코드"를 발표했다.[16]

자세한 정보 상태 코드, 설명 ...
Remove ads

구현

요약
관점

후이즈 조회는 전통적으로 명령줄 인터페이스 애플리케이션으로 수행되었지만, 현재는 많은 대체 웹 기반 도구가 존재한다.

후이즈 데이터베이스는 각 리소스에 대한 일련의 텍스트 레코드로 구성된다. 이 텍스트 레코드는 리소스 자체에 대한 다양한 정보 항목과 할당자, 등록자, 생성 및 만료일과 같은 관련 관리 정보로 구성된다.

후이즈 데이터베이스에 리소스 정보를 저장하기 위한 두 가지 데이터 모델, 즉 씬 모델과 틱 모델이 존재한다.

씬 및 틱 조회

후이즈 정보는 씬(Thin) 또는 틱(Thick) 데이터 모델에 따라 저장되고 조회될 수 있다.

틱(Thick)
틱 후이즈 서버는 특정 데이터 세트에 대한 모든 등록 대행자의 완전한 후이즈 정보를 저장한다(예: 하나의 후이즈 서버가 모든 .org 도메인에 대한 후이즈 정보로 응답할 수 있음).
씬(Thin)
씬 후이즈 서버는 도메인 등록 대행자의 후이즈 서버 이름만 저장하며, 등록 대행자 서버가 조회되는 데이터에 대한 전체 세부 정보(예: .com 후이즈 서버는 후이즈 쿼리를 도메인이 등록된 등록 대행자에게 전달함)를 가지고 있다.

틱 모델은 일반적으로 일관된 데이터와 약간 더 빠른 쿼리를 보장하며, 하나의 후이즈 서버만 연결하면 된다. 등록 대행자가 파산하더라도 틱 레지스트리는 모든 중요한 정보(등록자가 정확한 데이터를 입력하고 개인 정보 보호 기능이 데이터를 가리지 않는 경우)를 포함하며 등록 정보는 유지될 수 있다. 그러나 씬 레지스트리의 경우 연락처 정보를 사용할 수 없으며, 합법적인 등록자가 도메인 제어권을 유지하기 어려울 수 있다.[17]

후이즈 클라이언트가 이 상황을 처리하는 방법을 이해하지 못하면 등록 대행자의 전체 정보를 표시할 것이다. 후이즈 프로토콜은 씬 모델과 틱 모델을 구별하는 표준이 없다.

저장되는 레코드의 특정 세부 정보는 도메인 네임 레지스트리마다 다르다. com 및 net을 포함한 일부 최상위 도메인은 씬 후이즈를 운영하여 도메인 등록 대행자가 자체 고객 데이터를 유지하도록 요구한다. org를 포함한 다른 글로벌 최상위 레지스트리는 틱 모델을 운영한다.[18] 각 국가 코드 최상위 레지스트리에는 자체 국가 규칙이 있다.

소프트웨어

간략 정보 개발자, 안정화 버전 ...

후이즈 정보 시스템을 위해 작성된 최초의 애플리케이션은 유닉스 및 유닉스 계열 운영 체제(즉, 솔라리스, 리눅스 등)를 위한 명령줄 인터페이스 도구였다. 후이즈 클라이언트 및 서버 소프트웨어는 오픈 소스 소프트웨어로 배포되며 모든 유닉스 계열 시스템에 바이너리 배포판이 포함되어 있다. 다양한 상업용 유닉스 구현은 독점 구현(예: 솔라리스 7)을 사용할 수 있다.

후이즈 명령줄 클라이언트는 인수로 주어진 구문을 후이즈 서버에 직접 전달한다. 다양한 자유 오픈 소스 예제는 sourceforge.net과 같은 사이트에서 여전히 찾을 수 있다. 그러나 대부분의 현대 후이즈 도구는 특정 서버 호스트에 접근하기 위한 -h 옵션과 같은 명령줄 플래그 또는 옵션을 구현하지만, 기본 서버는 사전 구성되어 있다. 추가 옵션은 연결할 포트 번호 제어, 추가 디버깅 데이터 표시 또는 재귀/참조 동작 변경을 허용할 수 있다.

대부분의 TCP/IP 클라이언트 서버 애플리케이션과 마찬가지로 후이즈 클라이언트는 사용자 입력을 받아 대상 서버에 인터넷 소켓을 연다. 후이즈 프로토콜은 쿼리 전송 및 결과 수신을 관리한다.

웹

월드 와이드 웹의 등장, 특히 네트워크 솔루션 독점 완화로 인해 웹을 통한 후이즈 정보 조회가 상당히 보편화되었다. 현재 인기 있는 웹 기반 후이즈 쿼리는 아린,[21] RIPE[22] 및 APNIC에서 수행할 수 있다.[23] 대부분의 초기 웹 기반 후이즈 클라이언트는 단순히 명령줄 클라이언트의 프론트엔드였으며, 결과 출력은 거의 정리나 서식 없이 웹 페이지에 표시될 뿐이었다.

현재 웹 기반 후이즈 클라이언트는 일반적으로 후이즈 쿼리를 직접 수행한 다음 결과를 표시하도록 서식을 지정한다. 이러한 클라이언트 중 다수는 독점적이며 도메인 이름 등록 대행자가 작성한다.

웹 기반 클라이언트의 필요성은 명령줄 후이즈 클라이언트가 주로 유닉스 및 대규모 컴퓨팅 환경에만 존재한다는 사실에서 비롯되었다. 마이크로소프트 윈도우 및 매킨토시 컴퓨터에는 기본적으로 후이즈 클라이언트가 설치되어 있지 않았으므로, 등록 대행자는 잠재 고객에게 후이즈 데이터에 접근할 수 있는 방법을 제공해야 했다. 대부분의 최종 사용자는 여전히 이러한 클라이언트에 의존하고 있으며, 현재는 대부분의 가정용 PC 플랫폼에 명령줄 및 그래픽 클라이언트가 존재한다. 마이크로소프트는 시스인터널스 스위트를 제공하며, 여기에는 후이즈 클라이언트가 무료로 포함되어 있다.

CPAN에는 후이즈 서버와 함께 작동하는 여러 펄 모듈이 있다. 이 중 많은 모듈이 최신 버전이 아니며 현재(2005년) 후이즈 서버 인프라와 완전히 작동하지 않는다. 그러나 AS 번호 및 등록 대행자 연락처를 조회하는 것을 포함하여 여전히 유용한 많은 기능을 도출할 수 있다.

Remove ads

서버

후이즈 서비스는 주로 등록 대행자 및 레지스트리에 의해 운영된다. 예를 들어, 퍼블릭 인터넷 레지스트리 (PIR)는 .ORG 레지스트리 및 관련 후이즈 서비스를 유지 관리한다.[24]

대륙별 인터넷 레지스트리

Thumb
대륙별 인터넷 레지스트리

대륙별 인터넷 레지스트리(RIR)에서 운영하는 후이즈 서버는 특정 리소스에 대한 인터넷 서비스 제공자를 확인하기 위해 직접 쿼리할 수 있다.

이러한 각 레지스트리의 기록은 상호 참조되어, ARIN에 대한 쿼리가 RIPE에 속하는 기록에 대해 RIPE 후이즈 서버를 가리키는 플레이스홀더를 반환하도록 한다. 이를 통해 쿼리를 수행하는 후이즈 사용자는 상세 정보가 RIPE 서버에 있음을 알 수 있다. RIR 서버 외에도 라우팅 자산 데이터베이스와 같은 상업적 서비스가 존재하며, 일부 대규모 네트워크(예: 여러 RIR 지역에서 다른 ISP를 인수한 대규모 인터넷 제공업체)에서 사용한다.

서버 검색

현재 DNS 도메인에 대한 책임 있는 후이즈 서버를 결정하는 널리 확장된 방법은 없지만, 최상위 도메인(TLD)에 일반적으로 사용되는 여러 가지 방법이 있다. 일부 레지스트리는 DNS SRV 레코드(RFC 2782[25]에 정의됨)를 사용하여 클라이언트가 후이즈 서버 주소를 검색할 수 있도록 한다.[26] 일부 후이즈 조회는 도메인 소유자 세부 정보를 표시하기 위해 조달 도메인 등록 대행자를 검색해야 한다.

Remove ads

쿼리 예제

요약
관점

일반적으로 리소스 할당자의 연락처 정보가 반환된다. 그러나 일부 등록 기관은 사설 등록을 제공하며, 이 경우 등록 기관의 연락처 정보가 대신 표시된다.

일부 레지스트리 운영자는 도매업체이며, 이는 일반적으로 많은 수의 소매 등록 기관에 도메인 이름 서비스를 제공하고, 이 소매 등록 기관은 다시 소비자에게 서비스를 제공한다는 의미이다. 사설 등록의 경우 도매 등록 기관의 신원만 반환될 수 있다. 이 경우 개인의 신원뿐만 아니라 소매 등록 기관의 신원도 숨겨질 수 있다.

아래는 개별 리소스 소유자에 대해 반환된 후이즈 데이터의 예시이다. 이는 Example.com에 대한 후이즈 쿼리 결과이다.

> whois example.com
[Querying whois.verisign-grs.com]
[Redirected to whois.iana.org]
[Querying whois.iana.org]
[whois.iana.org]
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object
domain:       EXAMPLE.COM
organisation: Internet Assigned Numbers Authority
created:      1992-01-01
source:       IANA

다음은 파이널 판타지 XIV 웹사이트에 대한 후이즈 쿼리 결과로, 레지스트리, 등록 대행자, 도메인 상태, 네임 서버 및 DNSSEC 정보가 포함된 일반적인 .com 후이즈를 보여준다.

> whois finalfantasyxiv.com
[Querying whois.verisign-grs.com]
Domain Name: FINALFANTASYXIV.COM
Registry Domain ID: 19576356_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.markmonitor.com
Registrar URL: http://www.markmonitor.com
Updated Date: 2024-02-09T05:41:13Z
Creation Date: 2000-02-10T15:58:28Z
Registry Expiry Date: 2026-02-10T15:58:28Z
Registrar: MarkMonitor Inc.
Registrar IANA ID: 292
Registrar Abuse Contact Email: abusecomplaints@markmonitor.com
Registrar Abuse Contact Phone: +1.2086851750
Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
Name Server: A1-211.AKAM.NET
Name Server: A13-66.AKAM.NET
Name Server: A2-67.AKAM.NET
Name Server: A22-64.AKAM.NET
Name Server: A24-65.AKAM.NET
Name Server: A3-66.AKAM.NET
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/

Remove ads

Referral Whois

Referral Whois (RWhois)는 원래 후이즈 프로토콜 및 서비스의 확장이다. RWhois는 확장 가능하고 계층적인 방식으로 후이즈의 개념을 확장하여 잠재적으로 트리와 같은 아키텍처를 가진 시스템을 생성한다. 쿼리는 계층적 레이블을 기반으로 서버로 결정적으로 라우팅되어, 기본 정보 저장소로의 쿼리를 줄인다.[27]

IP 주소 할당 조회는 종종 더 큰 CIDR 블록(예: /24, /22, /16)으로 제한되는데, 일반적으로 대륙별 인터넷 레지스트리(RIR)와 도메인 등록 대행자만이 RWhois 또는 후이즈 서버를 운영하기 때문이다. 그러나 RWhois는 IP 주소 할당에 대한 더 세밀한 정보를 제공하기 위해 더 작은 지역 인터넷 레지스트리에서도 운영될 수 있도록 의도되었다.

RWhois는 후이즈를 대체하여, 어떤 RWhois 서버에 연결하더라도 조회를 요청하고 자동으로 올바른 서버(들)로 리디렉션되는 조직적인 계층 구조의 참조 서비스를 제공하는 것을 목표로 한다. 그러나 기술적 기능은 갖추어져 있지만, RWhois 표준 채택은 미미했다.

RWhois 서비스는 일반적으로 전송 제어 프로토콜(TCP)을 사용하여 통신된다. 서버는 잘 알려진 포트 번호 4321에서 요청을 수신한다.

Rwhois는 1994년에 네트워크 솔루션에 의해 RFC 1714에서 처음 명시되었으나[27], 1997년에 RFC 2167에 의해 사양이 대체되었다.[28]

RWhois의 참조 기능은 RWhois도 구현하는 다른 서버로 응답을 참조하는 후이즈 서버의 기능과는 다르다.

Remove ads

비판

요약
관점

후이즈에 대한 비판 중 하나는 데이터에 대한 완전한 접근이 부족하다는 점이다.[29][30] 소수의 당사자만이 완전한 데이터베이스에 실시간으로 접근할 수 있다.

다른 이들은 도메인 프라이버시라는 상충되는 목표를 비판으로 삼지만, 이 문제는 도메인 프라이버시 서비스에 의해 크게 완화된다. 현재 ICANN은 도메인 이름을 소유하거나 관리하는 사람들의 우편 주소, 전화 번호 및 이메일 주소를 "후이즈" 디렉터리를 통해 공개적으로 이용할 수 있도록 광범위하게 요구한다. 등록자(도메인 소유자)의 주소 및 전화 번호와 같은 연락처 정보는 후이즈 서버를 쿼리하는 누구나 쉽게 접근할 수 있다. 그러나 이 정책은 스팸 발송자, 직접 마케터, 신원 도용자 또는 기타 공격자가 이러한 사람들의 개인 정보를 디렉터리에서 빼내도록 허용한다. ICANN은 더 큰 프라이버시를 가능하게 하기 위해 후이즈를 변경하는 방안을 모색해왔지만, 주요 이해 관계자들 사이에서 어떤 종류의 변경이 이루어져야 하는지에 대한 합의가 부족하다.[31] 일부 도메인 등록 대행자는 개인 등록(도메인 프라이버시라고도 함)을 제공하는데, 이를 통해 고객 정보 대신 등록 대행자의 연락처 정보가 표시된다. 많은 등록 대행자가 개인 등록을 제공함으로써 일부 위험이 완화되었다.[32]

연구에 따르면 스팸 발송자는 후이즈 서버에서 일반 텍스트 이메일 주소를 수집할 수 있으며 실제로 그렇게 한다.[33][34] 이러한 이유로 일부 후이즈 서버와 후이즈 쿼리를 제공하는 웹사이트는 웹 기반 CAPTCHA 및 사용자 IP 주소당 제한된 검색 쿼리량과 같은 속도 제한 시스템을 구현했다.[32]

후이즈 요구 사항은 2018년 5월 25일부터 유럽 연합에서 시행되는 일반 데이터 보호 규칙(GDPR)과 충돌하며, GDPR은 개인 식별 정보의 처리 및 공개에 엄격한 규제를 부과한다. ICANN은 2017년 11월에 등록 대행사가 규칙 준수를 위한 대체 솔루션을 제공하는 경우 "등록 데이터 처리와 관련된 계약 의무 불이행"에 대해 징계하지 않을 것이라고 밝혔다. 이는 후이즈 요구 사항이 GDPR을 고려하여 업데이트될 때까지이다.[32][35]

후이즈 프로토콜은 국제적인 사용자를 염두에 두고 작성되지 않았다. 후이즈 서버 및 클라이언트는 쿼리 또는 데이터베이스 콘텐츠에 적용되는 텍스트 인코딩을 결정할 수 없다. 많은 서버는 원래 미국 ASCII를 사용했으며 국제화 문제는 훨씬 나중에 고려되었다.[36] 이는 미국 이외의 국가에서 후이즈 프로토콜의 유용성 또는 활용도에 영향을 미칠 수 있다.[1] 국제화 도메인 네임의 경우, 도메인 이름을 해당 원어 스크립트와 퓨니코드로 된 DNS 이름 간에 번역하는 것은 클라이언트 애플리케이션의 책임이다.

Remove ads

정보의 정확성

등록자(도메인 소유자)의 신원이 공개된 경우, 누구나 후이즈를 통해 도메인의 상태를 쉽게 확인할 수 있다.

사설 등록의 경우, 등록 정보를 확인하는 것이 더 어려울 수 있다. 도메인 이름을 취득한 등록자가 등록 대행자가 등록 절차를 완료했는지 확인하려면 다음 세 단계가 필요할 수 있다.

  1. 후이즈를 수행하여 리소스가 최소한 ICANN에 등록되었는지 확인한다.
  2. 도매 등록 대행자의 이름을 확인한다.
  3. 도매업체에 연락하여 소매 등록 대행자의 이름을 얻는다.

이것은 소매업체가 실제로 이름을 등록했음을 어느 정도 확신하게 해준다. 그러나 2007년 RegisterFly의 실패와 같이 등록 대행자가 파산할 경우, 개인 정보 보호가 적용된 등록을 가진 합법적인 도메인 소유자는 도메인 이름의 관리를 되찾는 데 어려움을 겪을 수 있다.[17] "사설 등록"을 사용하는 등록자는 고객 데이터를 제3자와 에스크로에 보관하는 등록 대행사를 사용하여 자신을 보호할 수 있다.

ICANN은 도메인 이름의 모든 등록자에게 도메인과 관련된 부정확한 연락처 데이터를 수정할 기회를 부여해야 한다. 이러한 이유로 등록 대행자는 확인을 위해 기록된 연락처 정보를 소유자에게 주기적으로 보내야 하지만, 등록자가 부정확한 정보를 제공한 경우 정보의 정확성에 대한 어떠한 보장도 제공하지 않는다.

Remove ads

법과 정책

후이즈는 미국 연방 정부에서 정책적 문제를 야기했다. 위에서 언급했듯이 후이즈는 프라이버시 문제를 야기하며, 이는 자유 발언 및 익명과도 연결되어 있다. 그러나 후이즈는 스팸 및 피싱과 같은 위반을 조사하는 법 집행관이 도메인 이름 소유자를 추적하는 데 중요한 도구이다. 결과적으로 법 집행 기관은 후이즈 기록을 공개하고 검증되도록 노력했다.[37]

  • 연방거래위원회는 부정확한 후이즈 기록이 수사를 방해하는 방식에 대해 증언했다.[38]
  • 2001년, 2002년, 2006년에 후이즈의 중요성에 대한 의회 청문회가 열렸다.[39]
  • 온라인 신원 사기 제재법(Fraudulent Online Identity Sanctions Act)[40]은 "상표권 또는 저작권 침해와 관련하여 사용된 도메인 이름의 등록을 생성, 유지 또는 갱신할 때 고의로 중대한 허위 연락처 정보를 제공하거나 제공하도록 한 경우" 상표권 및 저작권법 위반으로 규정한다.[41] 여기서 후자는 상표권 또는 저작권법의 이전 위반을 의미한다. 이 법은 허위 후이즈 데이터 제출 자체를 불법으로 규정하지 않고, 해당 도메인 이름을 사용하여 저지른 범죄에 대한 기소로부터 자신을 보호하기 위해 사용된 경우에만 불법으로 규정한다.

ICANN의 후이즈 폐지 제안

ICANN의 전문가 실무 그룹(EWG)은 2013년 6월 24일에 후이즈를 폐기해야 한다고 권고했다. EWG는 후이즈를 대부분의 인터넷 사용자에게 정보를 숨기고 "허용된 목적"을 위해서만 정보를 공개하는 시스템으로 대체할 것을 권고한다.[42] ICANN이 제시한 허용된 목적 목록에는 도메인 이름 연구, 도메인 이름 판매 및 구매, 규제 집행, 개인 데이터 보호, 법적 조치, 악용 완화가 포함된다.[43] 후이즈는 특정 정보가 인터넷에서 누구에 의해 유포되었는지 판단하는 데 언론인에게 핵심적인 도구였지만,[44] 언론의 후이즈 사용은 ICANN이 제안한 허용된 목적 목록에 포함되어 있지 않다.

EWG는 2013년 9월 13일까지 초기 보고서에 대한 대중의 의견을 수렴했다. 최종 보고서는 2014년 6월 6일에 발행되었으며, 권고 사항에 의미 있는 변경은 없었다.[45] 2015년 March월 기준, ICANN은 "ICANN 후이즈 베타" 작업을 통해 "후이즈를 재창조"하는 과정에 있다.[46][47]

2023년 1월 19일, ICANN은 모든 레지스트리 및 등록 대행사 계약에 대한 글로벌 수정안에 대한 투표를 시작했다. 이 수정안은 이 수정안의 효력 발생일로부터 180일간의 RDAP 강화 기간을 정의했다. 이 기간 후 360일은 후이즈 서비스 일몰 날짜로 정의되었으며, 그 이후에는 레지스트리 및 등록 대행사가 후이즈 서비스를 제공할 필요가 없고 대신 RDAP 서비스만 요구된다. 모든 투표 기준이 60일의 투표 기간 내에 충족되었으며, 이 수정안은 ICANN 이사회에서 승인되었다. 후이즈는 gTLD에 대해 2025년 1월 28일에 공식적으로 일몰되었다.[48]

Remove ads

표준 문서

  • RFC 812 – NICNAME/WHOIS (1982, 폐기됨)
  • RFC 954 – NICNAME/WHOIS (1985, 폐기됨)
  • RFC 3912 – WHOIS 프로토콜 사양 (2004, 현재)

같이 보기

각주

더 읽어보기

외부 링크

Loading related searches...

Wikiwand - on

Seamless Wikipedia browsing. On steroids.

Remove ads
Remove ads