Desde hace varios años gestionamos con éxito una red de oficinas con varios servidores Linux (Ubuntu) y clientes Windows+Linux. Un servidor actúa como servidor DNS interno utilizando el paquete de servidor DNS liviano DNSmasq.
Y justo hoy me enteré que el comando
$ nslookup machine.domain.comfunciona, pero
$ nslookup machine.domain.com/NO funciona --> Dominio inexistente/NXDOMAIN
Esto sucedió tanto en una máquina Ubuntu como en una máquina con Windows.
¿Esto se debe simplemente a que aquí (es decir, cuando se utilizan cmds como "nslookup" o "host"), la barra diagonal al final se considera parte del nombre de dominio, es decir, el dominio de nivel superior es "com/"? ¿O indica alguna mala configuración de nuestro servidor DNS interno?
Obviamente, los navegadores "normalmente" manejan esta barra correctamente en el sentido de que utilizan sólo el nombre de dominio sin la barra para la búsqueda de DNS y así obtienen una respuesta. Puse "generalmente" aquí porque hoy me encontré con un Firefox nuevo instalado en una instalación nueva de Ubuntu 22.04 LTS donde al ingresar la barra en la barra de direcciones del navegador (es decir, machine.domain.com/) extrañamente terminaba con el mensaje de error NXDOMAIN mencionado anteriormente.
Y, aún más extraño, sólo después de una búsqueda exitosa eliminando la barra diagonal, también comenzó a funcionar con la "dirección cortada". Este último comportamiento podría deberse al almacenamiento en caché de Firefox...
¿Alguien tiene algunas ideas para mí? ¿Es tal vez incluso una combinación de mi falta de comprensión de cómo funciona DNS (es decir, una barra diagonal o incluso una ruta posterior en realidad apunta a un "dominio diferente") y un error de Firefox (es decir, incluir erróneamente la barra diagonal en la consulta de DNS en el archivo instalado? ¿Versión de Firefox)? ¡Gracias!
Respuesta1
Estás mezclando estándares; el uso de una "barra diagonal" es correcto para el Protocolo de transferencia de hipertexto (HTTP).
Una dirección compatible con HTTP se forma a partir de una definición de protocolo, seguida de un nombre de dominio completo (FQDN) y el indicador uniforme de recursos (URI).
p.ejhttps://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
Mientras que DNS solo está destinado a resolver el FQDN en la dirección IP que se debe alcanzar, por ejemplo
FQDN: uno.uno.uno.uno ipv4: 1.1.1.1
El dominio de nivel superior es parte del FQDN, es decir, la última parte que sigue al .separador, por ejemplo .com .co.uk .site, etc.
En resumen, la razón por la que cualquier dominio al que se pasa nslookupno se resuelve es porque /se interpreta literalmente, mientras que cualquier navegador reconoce lo que es; una de las partes del protocolo HTTP.
nslookup intenta resolver sub.domain.tld/, y cualquier navegador "arrojará" la entrada en el FQDN sub.domain.tldy el URI/
Esperemos que esto aporte algo de claridad.
Respuesta2
Como se menciona aquíenlaceLos dominios (microsoft) solo pueden contener caracteres alfabéticos, dígitos y el símbolo '-'.
Cualquier otra cosa no es legal(No es cierto, correctamente corregido por @Patrick Mevzek), nslookup probablemente no analizará esto o su servidor DNS rechazará legítimamente una solicitud tan tonta :)
Cualquier cosa que suceda en su navegador web después de la barra diagonal no es parte del DNS y nslookup no lo entiende.
curl, por ejemplo, no se quejará y simplemente verá esto como la raíz del servidor web.
curl example.com/
<!doctype html>
<html>
<head>
<title>Example Domain</title>