Há vários anos administramos com sucesso uma rede de escritório com vários servidores Linux (Ubuntu) e clientes Windows + Linux. Um servidor atua como um servidor DNS interno usando o pacote de servidor DNS leve DNSmasq.
E ainda hoje descobri que o comando
$ nslookup machine.domain.comfunciona, mas
$ nslookup machine.domain.com/NÃO funciona --> Domínio inexistente / NXDOMAIN
Isso aconteceu em uma máquina Ubuntu e também em uma máquina Windows.
Isso ocorre apenas porque aqui (ou seja, ao usar cmds como "nslookup" ou "host"), a barra no final é considerada parte do nome de domínio, ou seja, o domínio de nível superior é "com/"? Ou indica alguma configuração incorreta do nosso servidor DNS interno?
Obviamente, os navegadores "normalmente" lidam com essa barra corretamente, no sentido de que usam apenas o nome de domínio sem a barra para pesquisa de DNS e, assim, obtêm uma resposta. Coloquei "normalmente" aqui porque hoje me deparei com um novo Firefox instalado em uma nova instalação do Ubuntu 22.04 LTS onde inserir a barra na barra de endereço do navegador (ou seja machine.domain.com/) terminava estranhamente com a mensagem de erro NXDOMAIN mencionada acima.
E - ainda mais estranho - somente após uma pesquisa bem-sucedida removendo a barra final, ele também começou a funcionar com o "endereço cortado". Este último comportamento pode ser causado pelo cache do Firefox...
Alguém tem algumas idéias para mim? Talvez seja até mesmo uma combinação da minha falta de compreensão de como o DNS funciona (ou seja, uma barra final ou mesmo um caminho subsequente na verdade aponta para um "domínio diferente") e um bug do Firefox (ou seja, incluir erroneamente a barra na consulta DNS no arquivo instalado Versão do Firefox)? Obrigado!
Responder1
Você está misturando padrões; o uso de uma "barra" é correto para o Hyper Text Transfer Protocol (HTTP).
Um endereço compatível com HTTP forma uma definição de protocolo, seguida por um nome de domínio totalmente qualificado (FQDN) e o indicador uniforme de recursos (URI).
por exemplohttps://sub.domain.tld/uri/of/the/resource/being/requested
Protocolo: https (protocolo HTTP encapsulado TLS) FQDN: sub.domain.tld URI: /uri/of/the/resource/being/requested
Enquanto que o DNS destina-se apenas a resolver o FQDN para o endereço IP a ser alcançado, por exemplo
FQDN: one.one.one.one ipv4: 1.1.1.1
O Domínio de Nível Superior faz parte do FQDN, ou seja, a última parte após o .separador, por exemplo, .com .co.uk .siteetc ...
Resumindo, a razão pela qual qualquer domínio transmitido nslookupnão consegue ser resolvido é porque o /é interpretado literalmente, enquanto qualquer navegador reconhece o que é; uma das partes do protocolo HTTP.
nslookup tenta resolver sub.domain.tld/e qualquer navegador irá "jogar" a entrada no FQDN sub.domain.tlde no URI/
Espero que isso dê alguma clareza
Responder2
Como mencionado aquilinkOs domínios (microsoft) só podem conter caracteres alfabéticos, dígitos e o símbolo '-'.
Qualquer outra coisa não é legal(Não é verdade, corrigido corretamente por @Patrick Mevzek), o nslookup provavelmente não analisará isso ou seu servidor DNS rejeitará legitimamente uma solicitação tão boba :)
O que quer que aconteça no seu navegador após a barra não faz parte do DNS e o nslookup não entende isso.
curl, por exemplo, não reclamará e apenas verá isso como a raiz do servidor web.
curl example.com/
<!doctype html>
<html>
<head>
<title>Example Domain</title>