☰

Whois를 수행할 때 Linux는 누구에게 물어보나요?

tag-icon • tag-icon dns whois
Whois를 수행할 때 Linux는 누구에게 물어보나요?

그렇게 할 때:

$ whois stackoverflow.com

Linux에서 먼저 DNS 쿼리를 수행하고 stackoverflow.com의 IP를 찾은 다음 그곳에서 직접 정보를 요청합니까?

아니면 "루트" whois 서버(Linux 배포판에 하드코딩된 "루트" whois 서버의 IP가 ? 와 비슷한 방식입니까 /etc/bind/db.root?)에게 물어본 다음 정보를 제공하는 다른 whois 서버에 위임합니까?

연결 흐름은 무엇입니까?

my computer doing `whois ...` ---> root whois server ---> another whois server ---> information

또는

my computer doing `whois ...` ---> DNS server (?) ---> ... ?

답변1

당신이 사용하는 경우마르코 디트리whois, 다음을 추가할 수 있습니다.--verbose 옵션을 추가하여 수행 중인 작업을 확인할 수 있습니다. stackoverflow.com의 경우 whois.verisign-grs.com을 묻는 것으로 시작됩니다(자세한 내용은WHOIS 서버 목록), 이는 Stack Overflow의 등록 기관이 Name.com이고 WHOIS 서버가 whois.name.com이라는 사실을 포함하여 여러 가지 정보를 제공합니다. 그런 다음 whois.name.com에 대해 묻습니다.

프로토콜은 다음 문서에 문서화되어 있습니다.RFC 3912. 그만큼whois맨페이지유용한 포인터도 있습니다.

답변2

Stephen은 핵심 부분에 답변했지만 제가 다루고 싶은 다른 사항이 있습니다.

  1. Whois는 잘못 정의된 프로토콜입니다. 계층 구조나 루트 whois 등이 없습니다. 실제로 whois 시스템에는 DNS와 관련된 것이 없습니다. 동일한 소스(레지스트리)에서 데이터를 가져간다는 점 외에도 마음속으로 완전히 분리하는 것부터 시작해야 합니다. 데이터베이스) 완전히 독립적으로 작동합니다.
  2. 이와 관련하여 각 TLD 레지스트리는 다르게 작동합니다. gTLD는 그 자체로 하나의 사례입니다. ICANN 계약에 따라 현재 각 등록 기관은 처리하는 모든 이름에 대해 응답하는 whois 서버를 보유해야 할 의무가 있습니다. 레지스트리에도 동일한 요구 사항이 있습니다. 레지스트리 whois 출력에는 등록자 whois 서버가 나열됩니다. (그러나 위의 설명에 쓴 것처럼 이는 최근에 약간 변경되었습니다. 사실 별다른 이유 없이 많은 whois 클라이언트가 중단되었습니다.) 주로 곧 사라질 역사적인 이유로 인해: 과거에 (그리고 지금도 .COM/.NET의 경우 - .JOBS 종류가 최근에 전환되었지만 이전에는 같은 보트에 있었습니다. 참조https://www.icann.org/resources/pages/thick-whois-transition-policy-2017-02-01-en) '얇은' 레지스트리는 레지스트리가 연락처에 대한 데이터를 저장하지 않고 등록자만 저장한다는 의미입니다. 즉, 도메인 이름에 대한 데이터를 정말로 갖고 싶고 문제가 발생할 경우 연락할 사람을 찾으려면(이것이 whois 프로토콜의 원래 목표였으며 지금도 여전히 그렇습니다), 먼저 레지스트리 whois 서버에 쿼리하여 다음을 수행해야 합니다. 기본 정보 세트를 얻고 등록자 whois 서버를 검색한 다음 이 등록자 whois 서버에 연락하여 모든 연락처 정보에 액세스합니다. 이는 오늘날 .COM/.NET의 레지스트리 출력이 도메인 이름 서버, 날짜 및 상태에 대한 데이터만 제공하는 이유를 설명합니다. 그리고 등록자 whois 서버 이름은 whois 클라이언트가 따라가려고 하지만 때로는 상황이 바뀌기 때문에 따라갈 수 없는 경우도 있습니다(위의 내 설명 참조).
  3. ccTLD는 거의 항상 그런 식으로 작동하지 않습니다. 등록 기관을 사용하여 레지스트리 whois 서버에 쿼리하면 필요한 모든 결과를 얻을 수 있으며 일부가 누락된 경우에도(예: 개인 정보 보호상의 이유로) 등록 기관의 whois 서버에 다음과 같이 쿼리할 필요가 없습니다. 등록 기관은 자신이 처리하는 ccTLD에 대해 이를 실행하도록 의무화하지 않습니다(그러나 일부 등록 기관은 이를 실행합니다). 이는 예를 들어 도메인 이름에 대한 관찰을 설명합니다 .fr.
  4. 일부 whois 클라이언트는 whois 서버의 주소를 하드코드하고 일부는 whois.nic.$TLD기본적으로 레지스트리로 작동하거나 기본 운영 도메인 이름으로 $TLD사용되는 경우가 많습니다 .nic.$TLD
  5. IANA는 다음에서 레지스트리 목록을 처리합니다.https://www.iana.org/domains/root/db다음과 같은 각 레지스트리 페이지에서https://www.iana.org/domains/root/db/fr.htmlWHOIS Server선택한 레지스트리와 관련된 whois 서버를 나열하는 줄이 표시됩니다 . 그러나 때로는 오래되거나 잘못될 수도 있습니다. 에 대한 TLD에 대한 whois 쿼리를 수행하여 이 데이터에 액세스할 수도 있습니다. whois.iana.org그러면 키의 whois 서버를 포함하여 관련 레지스트리에 대한 데이터가 제공됩니다 whois.
  6. 또 다른 트릭도 있습니다. DNS 쿼리를 수행하면(그러나 이 지점이 첫 번째 지점을 무효화하지는 않는다는 점을 기억하십시오) 에 대한 해당 whois 서버의 이름을 CNAME 레코드로 $TLD.whois-servers.net제공합니다 . $TLD일부 whois 클라이언트는 이 트릭을 사용할 수 있지만 나는 그것이 의심스럽습니다(GNU whois클라이언트가 그 중 하나일 수도 있고 아마도 FreeBSD 클라이언트일 수도 있습니다). 이 이니셔티브는 순전히 비공개이며, 그래야 했더라도 ICANN 또는 IANA와 같이 이 모든 것과 관련된 최고 기관에서 처리하지 않습니다. 예를 들면 dig uk.whois-servers.net +short다음과 같습니다: whois.nic.uk.. 이것의 매력은 이것이 변경되는 경우(매우 드물게) 또는 새 레지스트리/TLD가 활성화될 때(더 자주) 업데이트되어야 한다는 것입니다.
  7. SRV일부 레지스트리는 도메인 이름이 특정 서비스를 처리하는 위치를 지정하는 전용 DNS 레코드 유형을 사용하여 whois 서버 주소 엔드포인트를 게시합니다 . 따라서 그렇게 하면 사용되지 않는 두 개의 첫 번째 번호(그러나 로드 밸런싱/장애 조치에 사용될 수 있음) 외에 얻기 위해 연결할 포트 번호( ) 및 서버 이름 , 즉 해당 서비스 아래에 있는 서비스를 dig _nicname._tcp.fr +short실제로 얻을 수 있습니다. 공식 등록된 이름(0 0 43 whois.nic.fr.43whois.nic.frnicnamewhoishttps://www.iana.org/locationments/service-names-port-numbers/service-names-port-numbers.xhtml), 도메인의 경우 fr. 많은 레지스트리에서 사용되지는 않지만 SRV 레코드는 DNS 트리의 모든 수준에서 작동하는 분산 자동 검색 메커니즘을 정확하게 제공하여 레지스트리 및 "하위" 레지스트리 등에 대해 작동해야 합니다. .

최신 프로토콜인 RDAP가 whois를 대체하게 되면 위의 많은 내용이 변경됩니다. 이는 이미 여러 RFC에 의해 정의되었으며 일부 등록 기관(RIR을 위한 생산, 일부 도메인 이름 등록 기관에 대한 실험)에서 사용 중이지만 gTLD의 등록 기관 및 등록 기관(비기술적인 이유로)에서 아직 계약상 강제로 사용하도록 설정되지 않았습니다. ccTLD 등록 기관은 현재 whois 서버를 버리고 대신 RDAP 서버를 배치하는 것을 꺼려하는 것 같습니다.

답변3

WHOIS 클라이언트가 WHOIS 서버(TCP 포트 43)에 요청하면 서버가 직접 응답합니다.데비안의 WHOIS 클라이언트가지고있다하드코딩된 서버 목록자동으로 선택됩니다.IANA에는 WHOIS 서비스도 있습니다.

원천:RFC 3912

관련 정보