Whois를 수행 할 때 Linux는 누구에게 묻습니까?


11

할 때 :

$ whois stackoverflow.com

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

또는 "루트"후이즈 서버 (Linux 루트로 "루트 후이즈 서버"의 IP는 /etc/bind/db.root? 와 비슷한 방식으로 )에 정보를 제공하는 다른 후이즈 서버에 위임 하는가?

연결 흐름은 무엇입니까?

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

또는

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

답변:


12

Marco d' Itri 's를whois 사용하는 경우 --verbose옵션을 추가하여 수행중인 작업을 확인할 수 있습니다 . stackoverflow.com의 경우, whois.verisign-grs.com ( WHOIS 서버 목록 참조)에 요청하여 시작합니다.이 목록에는 Stack Overflow의 등록 기관이 Name.com이라는 사실과 WHOIS를 포함한 많은 정보가 제공됩니다. 서버는 whois.name.com입니다. 그런 다음 whois.name.com에 문의합니다.

프로토콜은 RFC 3912에 문서화되어 있습니다. whois맨 페이지가 유용 포인터를 가지고있다.


감사합니다 (데비안의 기본 whois는 Marco d' Itri의 것 같습니다). whoisverisign-grs 이외의 다른 WHOIS 서버를 사용 하라는 명령이 있습니까? 에서 찾지 못했습니다 man whois.
Basj

다른 것 : 당신은 그런 다음 쿼리했다 whois.name.com. 이것은 모든 레지스트라에 레지스트라-후이즈 서버가 있어야 함을 의미합니까? 그렇게 whois google.fr할 때 하드 코딩 된 사람이 아닌 다른 사람, 즉 whois.nic.fr을 쿼리하지 않는 것 같습니다. 맞습니까?
Basj

맞습니다. 데비안의 기본값 whois은 Marco d' Itri입니다 (Marco는 데비안 개발자입니다). 찾고있는 옵션은입니다 -h(참조 whois -h whois.name.com stackoverflow.com). 레지스트라에 모두 WHOIS 서버가있을 필요는 없습니다. TLD의“인증”등록 기관 만이 AFAIK를 수행합니다. 따라서 google.fr레지스트라는 MARKMONITOR이지만, 정보는 TLD 레지스트라 인 AFNIC에서 온 것입니다 .fr.
Stephen Kitt

고마워 재미있는 점은 할 때 whois stackoverflow.com정보가 거의 없지만 할 때 whois -h whois.name.com stackoverflow.com얻지 못하는 훨씬 더 많은 정보 ( Admin Organization: Stack Exchange, Inc.주소, 주소 등)를 얻는 것 whois stackoverflow.com입니다. 이 예상되는 동작입니다 whois즉, 당신이, 한 첫 번째 할 일 whois domain.com, 다음 후이즈 서버에서 찾고, 당신은해야 다시 A는 whois -h ... domain.com더 많은 정보를 가지고? whois그가 레지스트라 창녀를 찾을 때이 모든 것을 직접 수행 해서는 안 됩니까?
Basj

때문에, 동일한 정보를 얻을 수 있어야 whois stackoverflow.com 않습니다 가서 (적어도, 그것은 버전 5.2.17에서와) whois.name.com 자체를 부탁드립니다. 속도 제한 문제가 발생했을 수 있습니다. whois.name.com은 요청이 너무 많으면 일시적으로 차단하지만 오류 메시지가 표시됩니다. 덤프 whois stackoverflow.com하고 whois -h whois.name.com stackoverflow.com비교하면 두 경우 모두 정확히 동일한 name.com 출력이 나타납니다.
Stephen Kitt

11

스티븐이 핵심 부분에 대답했지만 당신이 다루고 싶은 다른 점이 있습니다.

  1. Whois는 잘못 정의 된 프로토콜입니다. 계층 구조, 루트 후이즈 등이 없습니다. 실제로 후이즈 시스템에는 DNS와 관련이 없습니다. 동일한 소스 (레지스트리에서 데이터를 가져 오는 것 외에)와 마찬가지로 마음에서 완전히 분리해야합니다. 데이터베이스) 그들은 완전히 독립적으로 작동합니다.
  2. 이와 관련하여 각 TLD 레지스트리는 다르게 작동합니다. gTLD는 자체적 인 경우입니다. ICANN 계약에 따라 현재 각 등록 기관은 처리하는 모든 이름에 대해 whois 서버에 응답 할 의무가 있습니다. 레지스트리의 요구 사항은 동일합니다. Registry whois 출력에는 등록자 WHOIS 서버가 나열되어 있지만 (위의 의견에 썼을 때, 실제로는 최근에 사라질 역사적인 이유로 인해 약간 최근에 변경되었습니다. (그리고 여전히 .COM / .NET-.JOBS 종류는 최근에 전환되었지만 이전에는 같은 보트에 있었음. https://www.icann.org/resources/pages/thick-whois-transition-policy-2017- 02-01-ko) 레지스트리가 '씬'인 경우 레지스트리는 연락처에 대한 데이터를 저장하지 않으며 등록자 만 해당합니다. 즉, 실제로 도메인 이름에 대한 데이터를 갖고 문제가 발생한 경우 (whois 프로토콜의 원래 목표였던) 연락 담당자를 찾으려면 먼저 레지스트리 whois 서버에 쿼리해야합니다. 기본 정보 세트를 확보하고 등록자 whois 서버를 찾은 다음이 등록자 whois 서버에 문의하여 모든 연락처 정보에 액세스하십시오. 이것은 오늘날 .COM / .NET의 레지스트리 출력이 도메인 이름 서버, 날짜 및 상태에 대한 데이터 만 제공하는 이유를 설명합니다. 그리고 클라이언트가 따르려고하지만 때로는 상황이 바뀌기 때문에 때로는 등록자 whois 서버 이름 (위의 내 의견 참조)
  3. ccTLD는 거의 항상 그렇게 작동하지 않습니다. 등록 기관을 사용하여 레지스트리 whois 서버를 쿼리해도 필요한 모든 결과가 반환되고 일부 정보가 누락 된 경우에도 (예 : 개인 정보 보호를 위해) 등록자의 whois 서버를 쿼리 할 필요는 없습니다. 그것들은 그들이 취급하는 ccTLD에 대해 그것을 실행하도록 레지스트리에 의해 의무화되지 않습니다 (그러나 그럼에도 불구하고 일부 등록 기관은 그렇게합니다). 이것은 .fr예를 들어 도메인 이름에 대한 관찰을 설명합니다 .
  4. 일부 후이즈 클라이언트가 후이즈 서버의 주소를 하드, 일부 시도는 whois.nic.$TLD종종 레지스트리로 작동 기본적으로 $TLD자주는이 nic.$TLD기본 운영 도메인 이름으로.
  5. IANA는 https://www.iana.org/domains/root/db 및 각 레지스트리 페이지 (예 : https://www.iana.org/domains/root/db/fr.html) 에서 레지스트리 목록을 처리 합니다. WHOIS Server선택한 레지스트리와 관련된 whois 서버를 나열 하는 행이 있습니다. 그러나 때때로 오래되거나 잘못 될 수 있습니다. 에 대한 TLD에 대한 whois 쿼리를 수행하여이 데이터에 액세스 할 수 whois.iana.org있으며 whois키 의 whois 서버를 포함하여 관련 레지스트리에 대한 데이터를 제공합니다 .
  6. 또 다른 트릭이 있습니다. DNS 쿼리를 수행하는 경우 (이 시점이 첫 번째 포인트를 무효화하지는 않는다는 점을 명심하십시오) CNAME 레코드로에 $TLD.whois-servers.net대한 해당 whois 서버의 이름을 제공합니다 $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.사용되지 않습니다 처음 두 숫자 외에 제공하는 포트 번호 ((하지만로드 밸런싱에 사용될 수 / 장애) 43) 및 서버 이름을 whois.nic.fr얻기 위해 접촉 nicname하고, whois서비스에서 그것의 에 대한 공식 등록 이름 ( https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml )fr도메인. SRV 레코드는 많은 레지스트리에서 사용되지 않지만 SRV 레코드는 DNS 트리의 모든 수준에서도 작동하여 레지스트리 및 "하위"레지스트리 등에서 작동하는이 분산 자동 검색 메커니즘을 정확하게 제공합니다. .

최신 프로토콜 인 RDAP가 후이즈를 대체하면 위의 많은 부분이 변경 될 것입니다. 이미 여러 RFC에 의해 정의되어 있으며 일부 레지스트리 (RIR 생산, 일부 도메인 이름 레지스트리 실험)에서 사용 중이지만 gTLD의 레지스트리 및 등록자 (기술적 인 이유로)가 아직 계약 상 강제로 사용되지는 않습니다. ccTLD 레지스트리는 현재 whois 서버를 버리고 RDAP 서버를 대신 사용하는 것을 꺼려합니다.


2

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

출처 : RFC 3912


감사. 는 IS tld_serv_list데비안에서 파일을 사용할 수 없습니다은? 파일 시스템을 검색했지만 찾을 수 없습니다. 이것이 whois 바이너리 안에 컴파일되었다는 의미 /usr/bin/whois입니까?
Basj

1
실제로 바이너리로 컴파일됩니다 (의 출력 참조 strings /usr/bin/whois).
Stephen Kitt
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.