A quem o Linux pergunta quando você executa um whois?

Quando você faz:

$ whois stackoverflow.com

seu Linux primeiro faz uma consulta DNS, encontra o IP do stackoverflow.com e depois pede as informações diretamente lá?

Ou pergunta a um servidor whois "raiz" (o IP do "servidor whois raiz" é codificado em uma distribuição Linux, de maneira semelhante a /etc/bind/db.root?), Que depois delega a outro servidor whois que fornece as informações?

Qual é o fluxo de conexão?

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

ou

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

Se você estiver usando o Marco d'Itriwhois , pode adicionar a --verboseopção para ver o que está fazendo. Para o stackoverflow.com, ele começa perguntando whois.verisign-grs.com (consulte sua lista de servidores WHOIS ), que fornece várias informações, incluindo o fato de o registrador do Stack Overflow ser o Name.com e seu WHOIS servidor é whois.name.com; então ele pergunta a whois.name.com.

O protocolo está documentado na RFC 3912 . A página de whoismanual também possui indicadores úteis.

Stephen respondeu as partes principais, mas você tem alguns outros pontos que quero abordar:

1. Whois é um protocolo mal definido. Não existe hierarquia, whois raiz, etc. Na verdade, não há nada relacionado ao DNS nos sistemas whois, você deve separá-los completamente em sua mente, pois, além do fato de que eles obtêm os dados da mesma fonte (o registro banco de dados) eles operam de forma completamente independente.
2. Cada registro de TLD opera de maneira diferente nesse sentido. Os gTLDs são um caso por conta própria: de acordo com o contrato da ICANN, por enquanto, cada registrador tem a obrigação de ter um servidor whois respondendo por todos os nomes que ele manipula. Os registros têm o mesmo requisito. A saída whois do registro lista o servidor whois do registrador (mas, como escrevi em um comentário acima, isso mudou um pouco recentemente - por nenhuma boa razão - que quebrou muitos clientes whois) principalmente por um motivo histórico que desaparecerá em breve: no passado (e ainda agora para .COM / .NET - .JOBS mudou recentemente, mas estava anteriormente no mesmo barco, consulte https://www.icann.org/resources/pages/thick-whois-transition-policy-2017- 02-01-pt) registros onde 'thin', o que significa que o registro não armazena dados sobre os contatos, apenas o registrador. O que significa que, se você realmente deseja obter dados sobre o nome de domínio e descobrir com quem entrar em contato em caso de problemas (que era - e ainda é - o objetivo original do protocolo whois), é necessário primeiro consultar o servidor whois do registro para obtenha o conjunto básico de informações e descubra o servidor whois do registrador e entre em contato com esse servidor whois do registrador para obter acesso a todas as informações de contato. Isso explica por que a saída do registro do .COM / .NET hoje fornece apenas dados sobre servidores de nomes de domínio, datas e status. E o nome do servidor whois do registrador, que o cliente whois tenta seguir, mas às vezes não consegue, porque as coisas mudam (veja meu comentário acima)
3. Os ccTLDs quase sempre não funcionam assim, mesmo que o uso de registradores, a consulta ao servidor whois do registro recupere todos os resultados necessários e mesmo que alguns estejam ausentes (por motivos de privacidade, por exemplo), você não precisa consultar o servidor whois dos registradores, pois eles não são obrigados pelos registros a executá-los nos ccTLDs com os quais lidam (mas alguns registradores, no entanto). Isso explica sua observação para um .frnome de domínio, por exemplo.
4. alguns clientes whois codificam endereços de servidores whois, outros tentam whois.nic.$TLDpor padrão, que geralmente funciona como registro de, $TLDgeralmente, tem nic.$TLDcomo nome de domínio operacional primário.
5. A IANA lida com a lista de registros em https://www.iana.org/domains/root/db e em cada página de registro, como https://www.iana.org/domains/root/db/fr.html . terá uma linha WHOIS Serverlistando o servidor whois relacionado ao registro selecionado. Observe, porém, que às vezes pode ficar desatualizado ou errado. Você também pode acessar esses dados fazendo uma consulta whois para um TLD whois.iana.org, que fornecerá dados sobre o registro relevante, incluindo o servidor whois na whoischave.
6. Há também outro truque. Se você fizer uma consulta DNS (mas lembre-se de que este ponto não invalida o primeiro ponto), $TLD.whois-servers.netele fornecerá o nome do servidor whois correspondente $TLD, como um registro CNAME. Alguns clientes whois podem usar esse truque, mas duvido que (o whoiscliente GNU possa ser um deles, ou talvez seja o FreeBSD). Observe que essa iniciativa é puramente privada e, mesmo que deveria ter sido, não é tratada pelas principais autoridades envolvidas em tudo isso, como ICANN ou IANA. Por exemplo dig uk.whois-servers.net +shortvai lhe dar: whois.nic.uk.. O charme disso é que ele deve ser atualizado se isso mudar (muito raro) ou (com mais frequência) quando novos registros / TLDs forem publicados.
7. Alguns registros publicam seus pontos de extremidade de endereço de servidor whois usando SRVqual é o tipo de registro DNS dedicado para especificar onde um nome de domínio lida com um serviço específico. Portanto, se você dig _nicname._tcp.fr +shortconseguir realmente obter o 0 0 43 whois.nic.fr.que fornece, além dos dois primeiros números que não são usados ​​(mas podem ser usados ​​para balanceamento de carga / failover), o número da porta ( 43) e o nome do servidor whois.nic.fra ser contatado para obter nicname, que é o whoisserviço sob sua nome oficial registrado ( https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml ), para ofrdomínio. Ele não é usado por muitos registros, mas deveria ter sido, os registros SRV fornecem exatamente esse mecanismo de descoberta automática distribuída que funciona até em qualquer nível da árvore DNS, de modo que funciona para registros e "sub" - registros, etc. .

Observe que muitas das opções acima serão alteradas quando o RDAP, um protocolo mais recente, substituir o whois. Ele já está definido por várias RFCs e está sendo usado por alguns registros (em produção para RIRs, em experimentos para alguns registros de nomes de domínio), mas ainda não é forçado contratualmente a ser usado por registros e registradores (por razões não técnicas) no gTLD mundo, e os registros de ccTLDs parecem relutantes em abandonar seus servidores whois atuais para colocar servidores RDAP.

Seu cliente WHOIS solicita um servidor WHOIS (na porta TCP 43) e responde diretamente. O cliente WHOIS do Debian tem uma lista codificada de servidores que ele escolhe automaticamente. A IANA também possui um serviço WHOIS.

Fonte: RFC 3912