Kogo pyta Linux, kiedy wykonujesz whois?

Kiedy to zrobisz:

$ whois stackoverflow.com

czy Twój Linux najpierw wykonuje zapytanie DNS, znajduje adres IP stackoverflow.com, a następnie pyta o informacje bezpośrednio tam?

Czy też pyta „root” serwer whois (czy adres IP „root whois server” jest zakodowany na stałe w dystrybucji Linuksa, w podobny sposób jak /etc/bind/db.root?), Który następnie przekazuje inny serwer whois, który udziela informacji?

Jaki jest przepływ połączenia?

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

lub

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

Jeśli korzystasz z Marco d'Itriwhois , możesz dodać --verboseopcję, aby zobaczyć, co robi. W przypadku stackoverflow.com zaczyna się od zapytania whois.verisign-grs.com (zobacz listę serwerów WHOIS ), co daje mu wiele informacji, w tym fakt, że rejestratorem Stack Overflow jest Name.com i jego WHOIS serwer to whois.name.com; więc następnie pyta whois.name.com.

Protokół jest udokumentowany w RFC 3912 . whoisPodręcznika zawiera także użyteczne wskazówki.

Stephen odpowiedział na najważniejsze części, ale masz kilka innych kwestii, którymi chciałbym się zająć:

1. Whois to źle zdefiniowany protokół. Nie ma hierarchii, nie ma root whois itp. W rzeczywistości nie ma nic związanego z DNS w systemach whois, powinieneś zacząć od całkowitego oddzielenia ich w swojej głowie, ponieważ oprócz tego, że biorą swoje dane z tego samego źródła (rejestru baza danych) działają całkowicie niezależnie.
2. Każdy rejestr TLD działa pod tym względem inaczej. gTLD to sprawa sama w sobie: zgodnie z umową ICANN na razie każdy rejestrator ma obowiązek posiadania serwera whois odpowiadającego na wszystkie obsługiwane nazwy. Rejestry mają takie same wymagania. Dane wyjściowe Whois z rejestru zawierają serwer Whois rejestratora (ale jak napisałem w powyższym komentarzu, zmieniło się to nieco niedawno - nie bez powodu - co złamało wielu klientów Whois) głównie z przyczyn historycznych, które wkrótce znikną: w przeszłości (i wciąż teraz dla .COM / .NET - .JOBS niedawno się zmieniło, ale wcześniej był na tej samej łodzi, patrz https://www.icann.org/resources/pages/thick-whois-transition-policy-2017- 02-01-en), w których „cienki” oznacza, że ​​rejestr nie przechowuje danych o kontaktach, a jedynie rejestrator. Co oznacza, że ​​jeśli naprawdę chcesz mieć dane dotyczące nazwy domeny i znaleźć osobę, z którą należy się skontaktować w przypadku problemów (co było - i nadal jest - pierwotnym celem protokołu whois), musisz najpierw zapytać serwer whois rejestru, aby uzyskać podstawowy zestaw informacji i odkryć serwer whois rejestratora, a następnie skontaktować się z serwerem whois rejestratora, aby uzyskać dostęp do wszystkich informacji kontaktowych. To wyjaśnia, dlaczego dane wyjściowe rejestru .COM / .NET dają dziś tylko dane o serwerach nazw domen, datach i statusach. I nazwa serwera whois rejestratora, którego klient whois próbuje śledzić, ale czasami nie może, ponieważ wszystko się zmienia (patrz mój komentarz powyżej)
3. ccTLD prawie zawsze tak nie działają, nawet jeśli korzystasz z rejestratorów, zapytanie do serwera whois rejestru zwróci ci wszystkie potrzebne wyniki, a nawet jeśli niektórych brakuje (np. ze względu na prywatność), nie musisz pytać serwera whois rejestratorów jako nie są upoważnione przez rejestry do uruchamiania go dla obsługiwanych ccTLD (ale niektórzy rejestratorzy tak robią). To wyjaśnia .frna przykład twoją obserwację nazwy domeny.
4. niektórzy klienci whois zapisują na stałe adresy serwerów whois, niektórzy próbują whois.nic.$TLDdomyślnie, który często działa jako rejestr, $TLDczęsto nic.$TLDjako podstawowa nazwa domeny operacyjnej.
5. IANA obsługuje listę rejestrów w https://www.iana.org/domains/root/db i na każdej stronie rejestru, takich jak https://www.iana.org/domains/root/db/fr.html ty będzie miał wiersz z WHOIS Serverlistą serwera whois związanego z wybranym rejestrem. Pamiętaj jednak, że czasami może się to zdezaktualizować lub źle. Możesz również uzyskać dostęp do tych danych, wykonując kwerendę Whois dla TLD whois.iana.org, która da ci dane dotyczące odpowiedniego rejestru, w tym jego serwera whois w whoiskluczu.
6. Jest też inna sztuczka. Jeśli wykonasz zapytanie DNS (ale pamiętaj, że ten punkt nie unieważnia pierwszego punktu), $TLD.whois-servers.netponieważ poda on nazwę odpowiedniego serwera whois $TLDjako rekord CNAME. Niektórzy klienci Whois mogą skorzystać z tej sztuczki, ale wątpię w to ( whoisklient GNU może być jednym z nich lub może jest to FreeBSD). Należy pamiętać, że ta inicjatywa jest czysto prywatna i nawet jeśli powinna, nie jest obsługiwana przez najwyższe organy zaangażowane w to wszystko, takie jak ICANN lub IANA. Na przykład dig uk.whois-servers.net +shortda Ci: whois.nic.uk.. Urok tego polega na tym, że należy go zaktualizować, jeśli zmieni się (bardzo rzadko) lub (częściej), gdy uruchomione zostaną nowe rejestry / TLD.
7. Niektóre rejestry publikują punkt końcowy adresu serwera whois, za pomocą SRVktórego jest dedykowanym typem rekordu DNS, aby określić, gdzie nazwa domeny obsługuje określoną usługę. Więc jeśli to zrobisz dig _nicname._tcp.fr +short, naprawdę otrzymasz, 0 0 43 whois.nic.fr.który oprócz dwóch pierwszych liczb, które nie są używane (ale mogą być używane do równoważenia obciążenia / przełączania awaryjnego), numer portu ( 43) i nazwę serwera, z którym whois.nic.frchcesz się skontaktować nicname, czyli whoisusługa pod jego oficjalna zarejestrowana nazwa ( https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml ), dlafrdomena. Nie jest używane przez wiele rejestrów, ale powinno być, rekordy SRV dokładnie zapewniają ten rozproszony mechanizm automatycznego wykrywania, który działa nawet na dowolnym poziomie drzewa DNS, dzięki czemu działa w przypadku rejestrów i rejestrów „podrzędnych” itp. .

Zauważ, że wiele z powyższych zmian ulegnie zmianie, gdy nowy protokół RDAP zastąpi whois. Jest już zdefiniowany przez wiele RFC i jest używany przez niektóre rejestry (w produkcji dla RIR, w eksperymentach dla niektórych rejestrów nazw domen), ale nie jest jeszcze umownie zmuszony do używania przez rejestry i rejestratorów (z przyczyn nietechnicznych) w gTLD world, a rejestry ccTLD wydają się niechętne porzucaniu swoich obecnych serwerów whois zamiast umieszczania serwerów RDAP.

Twój klient WHOIS pyta serwer WHOIS (na porcie TCP 43) i odpowiada bezpośrednio. Klient WHOIS Debiana ma zakodowaną listę serwerów, z których automatycznie wybiera. IANA ma również usługę WHOIS.

Źródło: RFC 3912