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

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

이 작업을 수행할 때:

$ whois stackoverflow.com

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

아니면 "루트" whois 서버("루트 whois 서버"의 IP가 비슷한 방식으로 Linux 배포판에 하드코딩되어 있습니까 /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일반적으로 레지스트리로 도메인 이름을 기본값으로 사용 하려고 합니다.$TLDnic.$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. 일부 레지스트리는 특수한 DNS 레코드 유형을 사용하여 SRV도메인 이름이 특정 서비스를 처리하는 위치를 지정하는 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 등록 기관은 RDAP 서버를 위해 현재 whois 서버를 포기할 의지가 없는 것 같습니다.

답변3

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

원천:RFC 3912

관련 정보