누가

WHOIS
이 문서는 도메인 이름의 소유권에 대한 정보를 확인하는 방법에 대한 것입니다.WHOIS 라고 하는 IRC 커맨드에 대해서는, 「Internet Relay Chat 커맨드」의 「WHOIS」를 참조해 주세요.

WHOIS(who is 문구로 발음)는 도메인 이름, IP 주소 블록 또는 자율 시스템과 같은 인터넷 리소스의 등록된 사용자 또는 할당자를 저장하는 데이터베이스 쿼리에 널리 사용되는 쿼리 및 응답 프로토콜이지만, 더 광범위한 다른 정보에도 사용됩니다.프로토콜은 사람이 읽을 수 있는 [1]형식으로 데이터베이스 내용을 저장하고 전달합니다.WHOIS 프로토콜의 현재 반복은 Internet Society에 의해 초안되었으며, 에서 문서화되어 있습니다. RFC3912.

Whois는 또한 WHOIS 프로토콜 [2]쿼리를 만드는 데 사용되는 대부분의 UNIX 시스템에서 명령줄 유틸리티의 이름입니다.또한 WHOIS에는 Reference Whois(RWhois)라는 자매 프로토콜이 있습니다.

역사

Elizabeth Feinler와 그의 팀은 1970년대 [3]초에 최초의 WHOIS 디렉토리를 작성했습니다.Feinler는 스탠포드 네트워크 정보 센터(NIC)에 서버를 셋업하여 사람 또는 실체에 [4]관한 관련 정보를 취득할 수 있는 디렉토리 역할을 했습니다.그녀와 팀은 컴퓨터의 [5]물리적 주소에 따라 도메인을 카테고리로 나누자는 파인러의 제안으로 도메인을 만들었습니다.

등록 프로세스는 RFC 920으로 확립되어 있습니다.WHOIS는 도메인, 사용자 및 도메인 및 번호 등록과 관련된 기타 리소스를 검색하기 위해 1980년대 초에 표준화되었습니다.당시 모든 등록이 한 조직에 의해 이루어졌기 때문에 WHOIS 쿼리에 한 대의 중앙 서버가 사용되었습니다.이것에 의해, 그러한 정보를 매우 간단하게 검색할 수 있게 되었습니다.

ARPANET에서 인터넷이 등장할 당시 모든 도메인 등록을 처리하는 유일한 조직은 미국 정부의 국방고급연구계획국(DARPA)이었다(1958년 창설).[6]도메인 등록의 책임은 1980년대에 ARPANET이 인터넷이 되면서 DARPA에 있었다.UUNET는 도메인 등록 서비스를 제공하기 시작했지만 DARPA Network Information Center(NIC; 네트워크 정보 센터)에 전송한 서류는 간단히 처리했습니다.그 후 미국 국립과학재단은 인터넷 도메인 등록 관리를 상업적 제3자에 의해 처리하도록 지시하였다.InterNIC는 1993년 NSF와의 계약에 따라 설립되었으며 Network Solutions, Inc., General Atomics 및 AT&T로 구성되어 있습니다.제너럴 아토믹스는 성능 문제로 몇 년 만에 계약이 취소됐다.

20세기 WHOIS 서버는 매우 관대했고 와일드카드 검색을 허용했다.한 사람의 성을 WHOIS에서 조회하면 그 이름을 가진 모든 사람이 표시됩니다.지정된 키워드를 가진 쿼리는 해당 키워드를 포함하는 모든 등록 도메인을 반환했습니다.특정 관리 연락처에 대한 쿼리가 관리자가 관련되어 있는 모든 도메인을 반환했습니다.상용화된 인터넷, 다수의 등록자, 비윤리적인 스팸 발송자의 출현 이후, 이러한 관대한 검색은 더 이상 이용할 수 없게 되었다.

1999년 12월 1일 최상위 도메인(TLD) 관리com, net 및 org가 ICANN에 할당되었습니다.그때 이들 TLD는 씬 WHOIS 모델로 변환되었습니다.기존 WHOIS 클라이언트는 그 시점에서 동작을 정지했습니다.한 달 후에는 같은 프로그램이 웹 기반 WHOIS 검색을 실행할 수 있도록 Common Gateway Interface 자가검출 지원 및 요청의 TLD를 기반으로 여러 WHOIS 서버를 지원하는 외부 TLD 테이블이 제공되었습니다.이것은 결국 현대의 WHOIS 클라이언트의 모델이 되었습니다.

2005년에는 1980년대 초반보다 더 많은 일반 최상위 도메인이 있었다.또한 국가 코드 최상위 도메인이 더 많이 있습니다.이로 인해 특히 인터넷 인프라스트럭처의 관리가 국제화됨에 따라 도메인 네임 레지스트라 및 레지스트라 어소시에이션의 복잡한 네트워크가 생겨났습니다.따라서 도메인에서 WHOIS 쿼리를 실행하려면 사용하는 올바른 WHOIS 서버를 알아야 합니다.WHOIS 도메인 검색을 실시하는 툴은, IONOS나 Namechap등의 프로바이더에 의해서 제공되고 있습니다.[7]

바삭바삭한 아이리스

2003년 IETF 위원회는 도메인 이름 및 네트워크 번호에 대한 정보를 검색하기 위한 새로운 표준인 [8]CRISP(Cross Registry Information Service Protocol)를 작성하기 위해 구성되었습니다.2005년 1월부터2006년 7월 사이에 이 새로운 표준의 기능명은 Internet Registry Information Service(IRIS; 인터넷레지스트리 정보 서비스)입니다.IRIS의 최초 IETF 제안 표준 RFC는 다음과 같습니다.

이 그룹이 작업한 RFC의 상태는 IETF Tools [11]사이트에서 확인할 수 있습니다.

2009년 3월 현재 CRISP IETF 워킹 그룹은 Newton, Andrew; Sanz, Marcos (February 2008). A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS). IETF. doi:10.17487/RFC5144. RFC 5144. Retrieved 1 June 2015.최종 RFC 5144가 그룹에 의해 발표된 후 결론을 [12]내렸습니다.

주의: IETF CRISP 작업 그룹은 "Consolidated RIR IANA Studdship Proposal Team"(CRISP 팀)[14]이라는 이름의 NRO(Number Resource Organization) 팀과 혼동하지 마십시오.

WEERDS 및 RDAP

주요 기사:등록 데이터 액세스 프로토콜

2013년에 IETF는 IRIS가 WHOIS를 성공적으로 대체하지 못했다는 것을 인정했다.그 주된 기술적 이유는 IRIS의 복잡성인 것으로 보인다.게다가 비기술적인 이유는 IETF가 판단을 내리지 않는 영역에 있는 것으로 간주되었다.한편 ARIN과 RIPE NCC는 RESTful 웹 서비스를 통해 WHOIS 데이터를 제공할 수 있었습니다.정관(2012년 2월 초안)은 번호 등록부를 우선으로 하고 명칭 등록부를 [15]따르도록 별도의 사양을 규정했다.작업 그룹은 제안된 표준 문서 5개를 작성했다.

및 정보 문서:

프로토콜

WHOIS 프로토콜은 ARPANET NICNAME 프로토콜에서 유래되었으며 RFC 742(1977)에 기술된 NAME/FINGER 프로토콜에 기반했습니다.NICNAME/WHOIS 프로토콜은 1982년 SRI International 네트워크 정보 센터의 Ken Harrentien과 Vic White에 의해 RFC 812에 처음 기술되었습니다.

WHOIS는 원래 Network Control Protocol(NCP)에 구현되었지만 TCP/IP 스위트가 ARPANET 및 이후 인터넷을 통해 표준화되었을 때 주로 사용되었습니다.

프로토콜 사양은 다음과 같습니다(원래 따옴표).[16] 

서비스 호스트 TCP: 서비스 포트 43 10진수 NCP: ICP에서 소켓43 10진수, 2개의 8비트 연결 확립 <CRLF>로 끝나는 단일 "명령줄"을 전송합니다.명령줄에 대한 응답으로 정보를 수신합니다.서버는 출력이 종료되는 즉시 접속을 종료합니다.

명령줄 서버 쿼리는 일반적으로 단일 이름 지정(예: 리소스 이름)단, 서버는 허용 가능한 명령줄 형식의 설명을 반환하기 위한 물음표(?)로만 구성된 쿼리를 받아들입니다.대체 또는 와일드카드 형식도 존재합니다.예를 들어 쿼리 이름에 풀스톱( 마침표)을 추가하면 쿼리 이름으로 시작하는 모든 엔트리가 반환됩니다.

현대의 인터넷에서는 일반적으로 WHOIS 서비스는 Transmission Control Protocol(TCP)을 사용하여 통신됩니다.서버는 well-known 포트 번호43에서 요구를 리슨합니다.클라이언트는 서버에 대한 통신채널을 확립하고 쿼리 대상 자원의 이름을 포함한 텍스트레코드를 전송하여 데이터베이스 내의 일련의 텍스트레코드의 형태로 응답을 기다리는 단순한 어플리케이션입니다.이러한 프로토콜의 단순성으로 인해 응용 프로그램 및 명령줄 인터페이스 사용자가 Telnet 프로토콜을 사용하여 WHOIS 서버를 쿼리할 수도 있습니다.

증강

2014년 6월 ICANN은 상태 코드에 대한 권장 사항인 "Extensible Provisioning EPPProtocol() 도메인 상태 코드"[17]를 발표했습니다.

상태 코드 묘사
add Period(기간 추가) 이 유예기간은 도메인 이름을 처음 등록한 후에 제공됩니다.등록관이 이 기간 내에 도메인명을 삭제했을 경우, 등록관은 등록비용에 대해 등록관에게 크레딧을 제공할 수 있다.
자동 갱신 기간 이 유예기간은 도메인 이름 등록 기간이 만료된 후 제공되며 레지스트리에 의해 자동으로 연장(갱신)됩니다.이 기간 동안 레지스트라가 도메인 이름을 삭제하면 레지스트리는 갱신 비용에 대한 크레딧을 레지스트라에 제공합니다.
활발하지 않은 이 상태 코드는 위임 정보(네임 서버)가 도메인에 연결되지 않았음을 나타냅니다.도메인이 DNS에서 활성화되지 않아 해결되지 않습니다.
네 알겠습니다 이것은 도메인의 표준 상태이며, 보류 중인 작업이나 금지 사항이 없음을 의미합니다.
작성 보류 중 이 상태 코드는 도메인 생성 요청이 수신되어 처리 중임을 나타냅니다.
삭제 보류 중 이 상태 코드는 redemptionPeriod 또는 pendingRestore와 혼재할 수 있습니다.이 경우 도메인 이름으로 설정된 상태에 따라 (다른 상태와 결합되지 않음) pendingDelete 상태 코드는 도메인이 30일 동안 redemptionPeriod 상태이며 복원되지 않았음을 나타냅니다.도메인은 며칠 동안 이 상태를 유지한 후 레지스트리 데이터베이스에서 도메인이 삭제됩니다.

삭제가 발생하면 레지스트리의 정책에 따라 도메인을 재등록할 수 있습니다.

갱신 보류 중 이 상태 코드는 도메인 갱신 요청이 수신되어 처리 중임을 나타냅니다.
복원 보류 중 이 상태 코드는 레지스트리가 redemptionPeriod 상태에 있던 도메인을 복원하도록 레지스트리에 요구했음을 나타냅니다.레지스트리는 레지스트라가 필요한 복원 문서를 제공할 때까지 도메인을 이 상태로 유지합니다.레지스트라가 복원 요청을 확인하기 위해 설정된 기간 내에 레지스트리 오퍼레이터에게 문서를 제공하지 않으면 도메인은 redemption Period 상태로 돌아갑니다.
전송 보류 중 이 상태 코드는 도메인을 새로운 레지스트라에 전송하기 위한 요청이 수신되어 처리 중임을 나타냅니다.
갱신 보류 중 이 상태 코드는 도메인 업데이트 요청이 수신되어 처리 중임을 나타냅니다.
상환 기간 이 상태 코드는 레지스트리에 도메인 삭제를 요구했음을 나타냅니다.도메인은 이 상태로 30일간 유지됩니다.redemptionPeriod 종료 후 5일이 지나면 도메인은 레지스트리 데이터베이스에서 삭제되어 등록에 사용할 수 있게 됩니다.
갱신 기간 이 유예기간은 도메인 이름 등록기간이 레지스트라에 의해 명시적으로 연장(갱신)된 후에 제공됩니다.이 기간 동안 레지스트라가 도메인 이름을 삭제하면 레지스트리는 갱신 비용에 대한 크레딧을 레지스트라에 제공합니다.
server Delete 금지 이 상태 코드를 사용하면 도메인이 삭제되지 않습니다.이는 일반적으로 법적 분쟁, 요청 또는 redemption Period 상태가 있을 때 제정되는 드문 상태입니다.
서버 홀드 이 상태 코드는 도메인의 레지스트리 오퍼레이터에 의해 설정됩니다.도메인이 활성화되지 않았습니다.
서버 갱신 금지 이 상태 코드는 도메인의 레지스트리 오퍼레이터가 레지스트라의 도메인 갱신을 허용하지 않음을 나타냅니다.이는 일반적으로 법적 분쟁 중 또는 도메인이 삭제될 때 제정되는 드문 상태입니다.
server Transfer 금지 이 상태 코드를 사용하면 도메인이 현재 레지스트라에서 다른 레지스트라로 전송되지 않습니다.이는 일반적으로 법적 또는 기타 분쟁 중, 사용자의 요청에 따라 또는 redemption Period 상태가 있을 때 제정되는 드문 상태입니다.
server Update 금지 이 상태 코드는 도메인을 잠그므로 도메인이 업데이트되지 않습니다.이는 일반적으로 법적 분쟁, 요청 또는 redemption Period 상태가 있을 때 제정되는 드문 상태입니다.
전송 기간 이 유예기간은 도메인 이름을 레지스트라 간에 정상적으로 전송한 후 제공됩니다.이 기간 동안 새로운 레지스트라가 도메인 이름을 삭제하면 레지스트리는 레지스트라에 전송 비용 크레딧을 제공합니다.

실행

WHOIS 검색은 기존에는 명령줄 인터페이스 응용 프로그램을 사용하여 수행되었지만 현재는 많은 대체 웹 기반 도구가 있습니다.

WHOIS 데이터베이스는 각 리소스에 대한 텍스트 레코드 세트로 구성됩니다.이러한 텍스트 레코드는 리소스 자체에 대한 다양한 정보 항목과 작성 및 만료 날짜 등의 피할당자, 등록자, 관리 정보 관련 정보로 구성됩니다.

WHOIS 데이터베이스에 리소스 정보를 저장하기 위한 두 가지 데이터 모델, 즉 씩 모델과 씬 모델이 있습니다.

얇고 두꺼운 룩업

WHOIS 정보는 씩 또는 씬 데이터 모델에 따라 저장 및 조회할 수 있습니다.

두꺼운
Thick WHOIS 서버는 특정 데이터 세트의 모든 레지스트라의 완전한 WHOIS 정보를 저장합니다(예를 들어 1개의 WHOIS 서버가 모든 .org 도메인의 WHOIS 정보로 응답할 수 있도록 합니다).
날씬해요.
Thin WHOIS 서버에는 도메인 레지스트라의 WHOIS 서버 이름만 저장됩니다.이 이름에는 검색되는 데이터(도메인이 등록된 레지스트라에 WHOIS 쿼리를 참조하는 .com WHOIS 서버 등)에 대한 자세한 내용이 기재되어 있습니다.

씩 모델에서는 1대의 WHOIS 서버만 접속하면 되기 때문에 일반적으로 데이터의 일관성과 쿼리 속도가 약간 향상됩니다.레지스트라가 폐업했을 경우, 씩 레지스트리는 모든 중요한 정보(등록자가 올바른 데이터를 입력해, 프라이버시 기능을 사용해 데이터를 숨기지 않은 경우)를 포함하고, 등록 정보를 유지할 수 있습니다.그러나 씬 레지스트리를 사용하면 연락처 정보를 사용할 수 없고 정당한 등록자가 도메인을 제어하기 어려울 [18]수 있습니다.

WHOIS 클라이언트가 이 상황에 대처하는 방법을 이해하지 못할 경우 레지스트라의 모든 정보가 표시됩니다.안타깝게도 WHOIS 프로토콜은 씬 모델과 씩 모델을 구별하는 방법을 결정하는 표준을 가지고 있지 않습니다.

보존되는 레코드의 상세한 것에 대하여는, 도메인명 레지스트리에 따라서 다릅니다.com 및 net을 포함한 일부 최상위 도메인은 씬 WHOIS를 운영하기 때문에 도메인 등록자가 고객의 데이터를 유지해야 합니다.org를 포함한 다른 글로벌 최상위 레지스트리는 씩 [19]모델을 운영하고 있습니다.각 국가 코드 최상위 레지스트리에는 고유한 국가 규칙이 있습니다.

소프트웨어

누가
Whois Mushoku Tensei screenshot.png
개발자RIPE NCC(오리지널 BSD 클라이언트), Marco d'Itri(현대판 Linux 클라이언트)
운영 체제Unix, Unix 라이크, ReactOS[20]
플랫폼크로스 플랫폼
유형명령어
면허증.BSD 라이선스(BSD 및 리액트)OS), GPL(Linux)
웹 사이트github.com/rfc1036/whois

WHOIS 정보 시스템용으로 작성된 최초의 애플리케이션은 Unix 및 Unix 유사 운영 체제(Solaris, Linux 등)용 명령줄 인터페이스 도구였습니다.WHOIS 클라이언트 및 서버 소프트웨어는 무료 오픈 소스 소프트웨어로 배포되며 이진 배포는 모든 Unix 유사 시스템에 포함됩니다.다양한 상용 Unix 실장에서는 독자적인 실장(Solaris 7 등)을 사용할 수 있습니다.

WHOIS 명령줄 클라이언트는 인수로 지정된 문구를 WHOIS 서버에 직접 전달합니다.sourceforge.net 등의 사이트에서도 다양한 무료 오픈소스의 예를 볼 수 있습니다.단, 대부분의 최신 WHOIS 도구는 특정 서버 호스트에 액세스하는 -h 옵션 등의 명령줄 플래그 또는 옵션을 구현하지만 기본 서버는 미리 구성되어 있습니다.추가 옵션을 사용하면 접속할 포트 번호를 제어하거나 추가 디버깅데이터를 표시하거나 재귀/참조 동작을 변경할 수 있습니다.

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

웹

World Wide Web의 등장과 특히 Network Solutions의 독과점이 완화되면서 WHOIS 정보를 웹을 통해 검색하는 것이 매우 보편화되었습니다.현재 ARIN,[21] RIPE 및 APNIC에서 인기[22] 있는 웹 기반 WHOIS 쿼리를 수행할 [23]수 있습니다.대부분의 초기 웹 기반 WHOIS 클라이언트는 명령줄 클라이언트의 프런트엔드에 불과했습니다.이 경우 결과 출력은 웹 페이지에 표시되며 청소나 포맷은 거의 이루어지지 않습니다.

현재 웹 기반 WHOIS 클라이언트는 일반적으로 WHOIS 쿼리를 직접 수행한 후 결과를 표시하기 위해 포맷합니다.이러한 클라이언트의 대부분은 도메인 네임레지스트라에 의해 작성되는 소유권입니다.

웹 기반 클라이언트의 필요성은 명령줄 WHOIS 클라이언트가 주로 Unix 및 대규모 컴퓨팅 세계에만 존재했기 때문입니다.Microsoft Windows 및 Macintosh 컴퓨터에는 기본적으로 WHOIS 클라이언트가 설치되어 있지 않았기 때문에 등록자는 잠재 고객에게 WHOIS 데이터에 대한 접근을 제공할 방법을 찾아야 했습니다.대부분의 가정용 PC 플랫폼에는 현재 명령줄 및 그래픽 클라이언트가 존재하지만 많은 최종 사용자는 여전히 이러한 클라이언트에 의존하고 있습니다.Microsoft는 Whois 클라이언트를 포함하는 Sysinternals Suite를 무료로 제공합니다.

CPAN에는 WHOIS 서버에서 동작하는 여러 Perl 모듈이 있습니다.이들 중 상당수는 최신 버전이 아니며 현재(2005) WHOIS 서버 인프라스트럭처에서 완전히 기능하지 않습니다.다만, AS 번호의 검색이나 등록자의 [citation needed]연락처의 검색 등, 취득할 수 있는 유용한 기능은 아직 많이 있습니다.

서버

WHOIS 서비스는 주로 레지스트라 및 레지스트리에 의해 실행됩니다.예를 들어 Public Interest Registry(PIR)는 를 유지합니다.ORG 레지스트리 및 관련 WHOIS 서비스.[24]

지역 인터넷 레지스트리

지역 인터넷 레지스트리

Regional Internet Registry(RIR; 지역 인터넷레지스트리)에 의해 동작하는 WHOIS 서버를 직접 조회하여 특정 자원을 담당하는 인터넷서비스 공급자를 판별할 수 있습니다.

이러한 각 레지스트리의 레코드는 상호 참조되므로 RIPE에 속하는 레코드에 대한 ARIN에 대한 쿼리는 RIPE WHOIS 서버를 가리키는 자리 표시자를 반환합니다.이것에 의해, 쿼리를 실시하는 WHOIS 유저는, 상세한 정보가 RIPE 서버에 있는 것을 알 수 있습니다.RIR 서버 외에 일부 대규모 네트워크(예를 들어 여러 RIR 영역에서 다른 ISP를 취득한 대규모 인터넷 프로바이더)에서 사용되는 라우팅 자산 데이터베이스와 같은 상용 서비스가 존재합니다.

서버 검출

현재 DNS 도메인의 담당 WHOIS 서버를 판별하는 방법은 광범위하게 확장되어 있지 않습니다.다만, Top-Level Domain(TLD; 최상위 도메인)에는 많은 방법이 공통적으로 사용되고 있습니다.레지스트리에 따라서는 DNS SRV 레코드(RFC 2782에서[25] 정의)를 사용하여 클라이언트가 WHOIS [26]서버의 주소를 검출할 수 있습니다.일부 WHOIS 검색에서는 도메인 소유자의 상세 내용을 표시하기 위해 조달 도메인레지스트라를 검색해야 합니다.

쿼리 예시

일반적으로 리소스 할당자의 연락처 정보가 반환됩니다.단, 일부 레지스트라는 개인 등록을 제공하고 있으며, 이 경우 레지스트라의 연락처 정보가 대신 표시됩니다.

일부 레지스트리 오퍼레이터는 도매상입니다.즉, 일반적으로 다수의 소매 등록자에게 도메인네임 서비스를 제공하고, 등록자는 이를 소비자에게 제공합니다.개인등록의 경우 도매등록관의 신원만 반환할 수 있다.이 경우 개인 및 소매등록관의 신원은 숨겨질 수 있다.

다음은 각 자원 보유자에 대해 반환된 WHOIS 데이터의 예입니다.이것은 example.com의 WHOIS 쿼리의 결과입니다.

whois example.com [쿼리 Whois]verisign-grs.com] [ whois.iana.org ][ Querying whois.iana.org ][ whois.iana.org ][ http://www.iana.org ]% IANA WHOIS server % 、 http://www.iana.org 、 this returned returned returned returned returned returned returned returned returned returned returned returned returned returned returned returned returned returned returned returned returned returned 。이 쿼리는 1개의 오브젝트 도메인을 반환했습니다.COM 조직:Internet Assigned Numbers Authority 작성: 1992-01-01 소스:IANA

소개 대상

Reference Whois(RWhois)는 원래 Whois 프로토콜 및 서비스의 확장입니다.RWois는 Whois의 개념을 확장 가능한 계층적 방식으로 확장하여 잠재적으로 나무와 같은 아키텍처를 가진 시스템을 구축합니다.쿼리는 계층 라벨에 따라 결정적으로 서버에 라우팅되므로 정보의 [27]프라이머리 저장소에 대한 쿼리가 줄어듭니다.

IP 주소 할당의 룩업은 많은 경우 Classless Inter-Domain Routing(CIDR; 클래스리스 도메인 간 라우팅) 블록(/24, /22, /16 등)으로 제한됩니다.이는 보통 RWois 또는 Whois 서버를 실행하는 지역 인터넷레지스트리(RIR)와 도메인레지스트라만이 RWois 서버를 실행하는 것을 목적으로 하고 있습니다만, RWois는 보다 작은 인터넷레지스터리에 의해서도 실행됩니다.r IP 주소 할당에 관한 정보.

RWois는 Whois를 대체하는 것으로, 임의의 RWois 서버에 접속해, 룩업을 요구해, 자동적으로 올바른 서버로 리다이렉트 할 수 있는, 정리된 레퍼런스 서비스의 계층을 제공합니다.그러나 기술적 기능은 갖추어져 있지만, RWois 표준의 채택은 약하다.

RWois 서비스는 일반적으로 Transmission Control Protocol(TCP)을 사용하여 통신됩니다.서버는 well-known port number 4321 상에서 요구를 리슨합니다.

Rhois는 1994년 RFC 1714에서 Network [27]Solutions에 의해 처음 지정되었지만 1997년에 RFC 2167로 [28]대체되었습니다.

RWois의 참조 기능은 다른 서버에 대한 응답을 참조하는 Whois 서버의 기능과 다릅니다.이러한 기능은, RWois도 실장하고 있습니다.

비판

WHOIS에 대한 한 가지 비판은 데이터에 [29][30]대한 완전한 접근이 부족하다는 것이다.완전한 데이터베이스에 실시간으로 액세스할 수 있는 당사자는 거의 없습니다.

다른 사람들은 도메인 프라이버시의 경쟁적인 목표를 비판으로 꼽지만, 이 문제는 도메인 프라이버시 서비스에 의해 크게 완화된다.현재 ICANN(Internet Corporation for Assigned Name and Numbers)은 도메인 이름을 소유하거나 관리하는 사람의 메일 주소, 전화번호 및 이메일 주소를 "WHOIS" 디렉토리를 통해 공개하도록 광범위하게 요구하고 있습니다.등록자(도메인 소유자)의 연락처(주소나 전화번호 등)는 WHOIS 서버에 문의하는 모든 사용자가 쉽게 접근할 수 있습니다.그러나 이 정책을 통해 스팸 발송자, 다이렉트 마케터, 신원 도용자 또는 기타 공격자가 이러한 사용자에 대한 개인 정보를 찾기 위해 디렉토리를 약탈할 수 있습니다.ICANN은 프라이버시 확대를 위해 WHOIS의 변화를 모색하고 있지만, 어떤 유형의 변경을 [31]해야 하는지에 대해서는 주요 이해관계자들 사이에서 합의가 이루어지지 않고 있다.도메인 레지스트라에 따라서는, 프라이빗 등록(도메인 프라이버시라고도 불립니다)을 제공하고 있습니다.이것에 의해, 고객의 등록 정보 대신에 레지스트라의 연락처 정보가 표시됩니다.많은 등록기관으로부터 개인 등록을 제안받음으로써, 위험의 일부는 [32]완화되었다.

연구에 따르면 스팸 발송자는 WHOIS [33]서버에서 일반 텍스트 전자 메일 주소를 수집할 수 있습니다.이 때문에 WHOIS 쿼리를 제공하는 일부 WHOIS 서버 및 웹 사이트에서는 웹 기반 CAPTCHA 및 사용자 [32]IP 주소별 검색 쿼리 수 제한 등의 환율 제한 시스템이 구현되어 있습니다.

WHOIS 요건은 2018년 5월 25일 발효된 일반 데이터 보호 규정(GDPR)과 상충됩니다.GDPR은 개인 식별 가능 정보의 처리 및 공개에 엄격한 규정을 두고 있습니다.ICANN은 2017년 11월 WHOIS 요건이 갱신을 거쳐 GDPR을 [32][34]반영할 때까지 등록자가 규칙 준수를 위한 대체 솔루션을 제공할 경우 '등록 데이터 취급과 관련된 계약상의 의무 불이행'을 문책하지 않겠다고 밝혔다.

WHOIS 프로토콜은 국제적인 청중을 염두에 두고 작성되지 않았다.WHOIS 서버 및/또는 클라이언트는 쿼리 또는 데이터베이스 콘텐츠에 대해 유효한 텍스트 인코딩을 결정할 수 없습니다.많은 서버가 당초 US-ASCII를 사용하고 있었기 때문에 국제화에 대한 우려는 그 [35]후까지 고려되지 않았습니다.이는 미국 [1]이외의 국가에서 WHOIS 프로토콜의 유용성 또는 유용성에 영향을 미칠 수 있다.국제화된 도메인 이름의 경우 클라이언트응용 프로그램은 모국어 스크립트와 DNS 이름 간의 도메인 이름 변환을 수행합니다.

정보의 정확성

등록자(도메인 오너)의 ID가 공개되어 있는 경우 WHOIS를 통해 누구나 도메인 상태를 쉽게 확인할 수 있습니다.

개인 등록의 경우 등록 정보를 확인하는 것이 더 어려울 수 있습니다.도메인명을 취득한 등록자가, 등록관이 등록 프로세스를 완료하고 있는 것을 확인하려면 , 다음의 3개의 순서가 필요한 경우가 있습니다.

  1. WHOIS를 실행하여 리소스가 적어도 ICANN에 등록되어 있는지 확인합니다.
  2. 도매 등록관의 이름을 결정하고,
  3. 도매상에게 연락하여 소매업 등록관의 이름을 얻습니다.

이를 통해 소매업체가 실제로 이름을 등록했다는 확신을 얻을 수 있습니다.그러나 2007년의 RegisterFly의 실패와 같이 레지스트라가 폐업하면 프라이버시 보호 등록이 있는 정당한 도메인 소유자는 도메인 [18]이름의 관리를 회복하는 데 어려움을 겪을 수 있습니다.「개인 등록」을 사용하는 등록자는, 고객의 데이터를 제삼자에게 에스크로 하는 등록관을 사용해 자신을 보호하려고 할 수 있습니다.

ICANN에서는 도메인 이름의 모든 등록자에게 해당 도메인과 관련된 부정확한 연락처 데이터를 수정할 수 있는 기회를 제공해야 합니다.이 때문에 등록자는 정기적으로 보유자에게 확인을 위해 연락처 정보를 기록으로 보내야 하지만, 등록자가 부정확한 정보를 제공했을 경우 정보의 정확성에 대한 보증을 제공하지 않는다.

법과 정책

WHOIS는 미국 연방정부에서 정책 이슈를 야기했다.위에서 설명한 바와 같이 WHOIS는 자유로운 발언과 익명성에 관련된 사생활 문제를 야기합니다.그러나 WHOIS는 스팸이나 피싱 등의 위반을 수사하는 법 집행관이 도메인 이름 소유자를 추적하는 데 중요한 도구입니다.그 결과, 법 집행 기관은 WHOIS 기록을 공개 및 [36]검증하기 위해 노력하고 있습니다.

  • Federal Trade Commission(연방거래위원회)[37]은 WHOIS 기록이 얼마나 부정확한 조사를 방해하고 있는지에 대해 증언했다.
  • 2001년, 2002년, [38]2006년에 WHOIS의 중요성에 대해 의회 청문회가 실시되었다.
  • a로 후자"위반"그 부실 온라인 정체성 대북 Act[39]"상표 저작권 법의 위반, 어떤 사람이 알거나 제공되게 되,, 유지, 또는 도메인 이름은 위반과 관련에 사용하는 등록 갱신을 만들고 실질적으로 거짓 탐지. 정보를 제공해 내"[40] 말한다v사전상표법 또는 저작권법의 분리.이 법은 도메인 이름을 사용하여 저지른 범죄에 대한 기소로부터 자신을 보호하기 위해 사용되는 경우에만 허위 WHOIS 데이터 제출 자체를 불법으로 만들지 않습니다.

인터넷 주소 관리 기구의 WHOIS 폐지 제안

인터넷 주소 관리 기구(ICANN)의 EWG(Expert Working Group)는 2013년 6월 24일 WHOIS를 폐기할 것을 권고했다.WHOIS는 대부분의 인터넷 사용자에게 정보를 비밀로 하고 "허용 [41]가능한" 목적으로만 정보를 공개하는 시스템으로 대체할 것을 권고하고 있다.ICANN의 허용되는 목적 목록에는 도메인 이름 조사, 도메인 이름 판매 및 구매, 규제 집행, 개인 데이터 보호, 법적 조치 및 남용 [42]완화가 포함됩니다.WHOIS는 [43]누가 인터넷에서 특정 정보를 전파했는지를 결정하는 데 있어 기자들의 주요 도구였지만, 자유 언론에 의한 WHOIS 사용은 ICANN이 제안한 허용 목적 목록에 포함되지 않았다.

EWG는 2013년 9월 13일까지 최초 보고서에 대한 대중의 의견을 수집했다.최종 보고서는 2014년 6월 6일에 발표되었지만,[44] 권고 사항에 유의미한 변경은 없었다.ICANN은 2015년 3월 현재, 「ICANN WHOIS [45][46]베타」에 임하는 「WHOIS의 재발명」을 진행하고 있다.

표준 문서

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

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b RFC 3912, WHOIS 프로토콜 사양, L. Daigle (2004년 9월)
  2. ^ "Whois(1) — whois — Debian stretch — Debian Manpages".
  3. ^ 에반스 2018, 페이지 116
  4. ^ 에반스 2018, 페이지 119
  5. ^ 에반스 2018, 페이지 120
  6. ^ Innovation at DARPA (PDF) (Report). DARPA. July 2016. Retrieved August 7, 2021.
  7. ^ "Whois Domain Lookup UK » Check detailed info for free IONOS". www.ionos.co.uk. Retrieved 2022-07-27.
  8. ^ Murphy, Cathy (2 October 2003). "CRISP (Cross-Registry Information Service Protocol) Working Group Meeting Minutes". Internet Engineering Task Force. Minneapolis, Minnesota USA: IETF. Archived from the original on 1 June 2015. Retrieved 1 June 2015. The CRISP (Cross-Registry Information Service Protocol) WG will define a standard mechanism that can be used for finding authoritative information associated with a label, a protocol to transport queries and responses for accessing that information, and a first profile (schema & queries) to support commonly-required queries for domain registration information.
  9. ^ Newton, Andrew (July 2006). "Replacing the Whois Protocol: IRIS and the IETF's CRISP Working Group". IEEE Internet Computing. 10 (4): 79–84. doi:10.1109/MIC.2006.86. S2CID 8514005. Retrieved 1 June 2015. The Nicname/Whois protocol has served well, but it remains unchanged since it was first published in the early 1980s, despite great change in the infrastructure and administration of the Internet. There is now more diversity with domain names and IP networks and associated contacts, as well as among the users submitting queries via Whois. The protocol is now so fragmented in terms of information flow and output that queries yield inconsistent results under current conditions. To address the needs of today's Internet, the IETF Cross Registry Internet Service Protocol (CRISP) working group is developing a new protocol, the Internet Registry Information Service (IRIS), to replace Whois.
  10. ^ Sanz, Marcos; Newton, Andrew; Daigle, Leslie (12 January 2005). "The Internet Registry Information Service (IRIS) Protocol" (PDF). gnso.icann.org. Internet Corporation for Assigned Names and Numbers (ICANN). Archived from the original (PDF) on 1 June 2015. Retrieved 1 June 2015. CRISP - Cross-Registry Internet Service Protocol: The CRISP Working Group was tasked with finding a solution to the problems that currently infest the Nicname/Whois protocol. The CRISP Working Group created a list of functional requirements. Proposals meeting these requirements were evaluated. IRIS was selected as the protocol to publish as a standard. Now an IETF Proposed Standard: RFCs: 3981, 3982, 3983
  11. ^ "Crisp Status Pages". IETF Tools: CRISP WG Status Pages. IETF. Archived from the original on 1 June 2015. Retrieved 2 June 2015.
  12. ^ IESG Secretary (26 March 2009). "WG Action: Conclusion of Cross Registry Information Service Protocol (crisp)". IETF CRISP WG: Mail Archive. Archived from the original on 2 June 2015. Retrieved 2 June 2015. The Cross Registry Information Service Protocol (crisp) working group in the Applications Area has concluded.
  13. ^ Mevzek, Patrick (21 January 2009). "[CRISP] RFC 5144 up and running". IETF CRISP WG: Mail Archive. Archived from the original on 2 June 2015. Retrieved 2 June 2015.
  14. ^ "Consolidated RIR IANA Stewardship Proposal Team (CRISP Team)". Number Resource Organization (NRO). Retrieved 4 August 2022.
  15. ^ "Web Extensible Internet Registration Data Service (weirds) Working Group". IETF-88 Proceedings. IETF. Retrieved 8 July 2015.
  16. ^ Harrenstien, K.; White, V. (1 March 1982). NICNAME/WHOIS. doi:10.17487/RFC0812. RFC 812.
  17. ^ "EPP Status Codes - What Do They Mean, and Why Should I Know? - ICANN". www.icann.org. Retrieved 14 March 2018.
  18. ^ a b ".COM and .NET: Thick Or Thin?".
  19. ^ Sarah Stoll (30 May 2009). "Thick vs. Thin Whois for New gTLDs" (PDF). memorandum. ICANN. Retrieved 17 September 2011. Current gTLD registry agreements vary between thin and thick Whois outputs: com, net and jobs are thin; all other gTLD agreements – aero, asia, biz, cat, coop, info, mobi, museum, name, org, pro, tel, travel – are thick.
  20. ^ reactos/whois.c at master · reactos / reactos · GitHub
  21. ^ "Whois-RWS". whois.arin.net.
  22. ^ "Webupdates". RIPE Network Coordination Centre.
  23. ^ "APNIC Whois search". wq.apnic.net.
  24. ^ "DNS and WHOIS - How it Works ICANN WHOIS".
  25. ^ Gulbrandsen, Arnt; Esibov, Levon (February 2000). "A DNS RR for specifying the location of services (DNS SRV)". {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  26. ^ "Getting WHOIS Server Address Directly from Registry".
  27. ^ a b Williamson, S.; Kosters, M. (November 1994). Referral Whois Protocol (RWhois). doi:10.17487/RFC1714. RFC 1714.
  28. ^ Williamson, S.; Kosters, M.; Blacka, D.; Singh, J.; Zeilstra, K. (June 1997). Referral Whois (RWhois) V1.5. doi:10.17487/RFC2167. RFC 2167.
  29. ^ "Battle Begins Over IP Address Whois Data". Internet Governance Project. 12 February 2011. Retrieved 4 April 2015.
  30. ^ "WHOIS Privacy Plan Draws Fire". KerbsonSecurity. Retrieved 4 April 2015.
  31. ^ "The Privacy Conundrum in Domain Registration". Act Now Domains. Retrieved 26 March 2013.
  32. ^ a b c "WHATIS Going to Happen With WHOIS?". Motherboard. 2018-02-02. Retrieved 2018-04-28.
  33. ^ 「SAC 023: WHOIS 서비스는 스팸 발송자를 위한 이메일 주소의 소스입니까?」(ICANN 보안 및 안정성 자문위원회, 2007년 10월)
  34. ^ Vaughan-Nichols, Steven J. "ICANN makes last minute WHOIS changes to address GDPR requirements". ZDNet. Retrieved 2018-05-29.
  35. ^ "WHOIS 내부화의 문제", 2012년 11월
  36. ^ "FTC Calls for Openness, Accessibility in Whois Database System - Federal Trade Commission". www.ftc.gov. 18 July 2006.
  37. ^ "Accuracy of "WHOIS" Internet Database Essential to Law Enforcement, FTC Tells Congress - Federal Trade Commission". www.ftc.gov. 2 May 2002.
  38. ^ Bowman, Lisa (11 July 2001). "Whois at heart of congressional hearings". CNET. Archived from the original on 27 August 2005.
  39. ^ "THOMAS". Archived from the original on July 17, 2012.
  40. ^ "Fraudulent Online Identity Sanctions Act". Archived from the original on July 17, 2012.
  41. ^ "Initial Report from the Expert Working Group on gTLD Directory Services: A Next Generation Registration Directory Service" (PDF). whois.icann.org. ICANN. 24 June 2013. Retrieved 24 March 2015.
  42. ^ "Archived copy". Archived from the original on 2014-01-14. Retrieved 2014-01-13.{{cite web}}: CS1 maint: 제목으로 아카이브된 복사(링크)
  43. ^ "SJMC: COMMON SENSE JOURNALISM". jour.sc.edu. Archived from the original on 2005-01-12.
  44. ^ "Final Report from the Expert Working Group on gTLD Directory Services: A Next-Generation Registration Directory Service (RDS)" (PDF). whois.icann.org. ICANN. 6 June 2014. Retrieved 24 March 2015.
  45. ^ "About WHOIS". whois.icann.org/. ICANN. Retrieved 24 March 2015.
  46. ^ "What's on the Horizon?". whois.icann.org. ICANN. Retrieved 24 March 2015.

원천

외부 링크