Wir betreiben seit mehreren Jahren erfolgreich ein Büronetzwerk mit verschiedenen Linux-Servern (Ubuntu) und Windows+Linux-Clients. Ein Server fungiert als interner DNS-Server unter Verwendung des leichtgewichtigen DNS-Serverpakets DNSmasq.
Und gerade heute habe ich festgestellt, dass der Befehl
$ nslookup machine.domain.comfunktioniert, aber
$ nslookup machine.domain.com/NICHT funktioniert --> Nicht vorhandene Domäne / NXDOMAIN
Dies geschah sowohl auf einem Ubuntu-Rechner als auch auf einem Windows-Rechner.
Liegt das nur daran, dass hier (also bei Verwendung von Befehlen wie „nslookup“ oder „host“) der Schrägstrich am Ende als Teil des Domänennamens betrachtet wird, d. h. die Top-Level-Domäne ist „com/“? Oder deutet das auf eine Fehlkonfiguration unseres internen DNS-Servers hin?
Offensichtlich verarbeiten Browser diesen Schrägstrich „normalerweise“ korrekt in dem Sinne, dass sie für die DNS-Suche nur den Domänennamen ohne Schrägstrich verwenden und so eine Antwort erhalten. Ich habe das „normalerweise“ hier eingefügt, weil ich gerade heute auf einen neuen Firefox gestoßen bin, der auf einer neuen Ubuntu 22.04 LTS-Installation installiert war, bei dem die Eingabe des Schrägstrichs in die Adressleiste des Browsers (also machine.domain.com/) seltsamerweise mit der oben erwähnten NXDOMAIN-Fehlermeldung endete.
Und - noch seltsamer - erst nach einer erfolgreichen Suche durch Entfernen des abschließenden Schrägstrichs funktionierte es auch mit der "durchgestrichenen Adresse". Dieses letztere Verhalten könnte durch das Firefox-Caching verursacht werden...
Hat jemand ein paar Erkenntnisse für mich? Ist es vielleicht sogar eine Kombination aus meinem fehlenden Verständnis, wie DNS funktioniert (d. h. ein abschließender Schrägstrich oder sogar ein nachfolgender Pfad verweist tatsächlich auf eine „andere Domäne“) und einem Firefox-Fehler (d. h. die irrtümliche Einbeziehung des Schrägstrichs in die DNS-Abfrage in der installierten Firefox-Version)? Danke!
Antwort1
Sie vermischen Standards; die Verwendung eines „Schrägstrichs“ ist für das Hypertext Transfer Protocol (HTTP) korrekt.
Eine HTTP-kompatible Adresse besteht aus einer Protokolldefinition, gefolgt von einem vollqualifizierten Domänennamen (FQDN) und dem Uniform Resource Indicator (URI).
z.Bhttps://sub.domain.tld/uri/der/angeforderten/Ressource
Protokoll: https (TLS-gekapseltes HTTP-Protokoll) FQDN: sub.domain.tld URI: /uri/der/angeforderten/Ressource
Wobei DNS nur dazu dient, den FQDN in die zu erreichende IP-Adresse aufzulösen, z. B.
FQDN: eins.eins.eins.eins ipv4: 1.1.1.1
Die Top-Level-Domain ist ein Teil des FQDN, nämlich der letzte Teil nach dem .Trennzeichen, zB .com .co.uk .siteetc...
Kurz gesagt liegt der Grund dafür, dass die Weiterleitung an eine beliebige Domain nslookupfehlschlägt, darin, dass es /wörtlich interpretiert wird, während jeder Browser erkennt, was es ist; es ist einer der Teile des HTTP-Protokolls.
nslookup versucht aufzulösen sub.domain.tld/, und jeder Browser "wirft" die Eingabe in den FQDN sub.domain.tldund die URI/
Hoffentlich bringt das etwas Klarheit
Antwort2
Wie hier erwähntVerknüpfung(Microsoft) Domänen dürfen nur alphabetische Zeichen, Ziffern und das Symbol „-“ enthalten.
Alles andere ist nicht legal(Stimmt nicht, zu Recht korrigiert von @Patrick Mevzek), nslookup wird dies wahrscheinlich nicht analysieren oder Ihr DNS-Server lehnt solch eine dumme Anfrage zu Recht ab :)
Was auch immer in Ihrem Webbrowser nach dem Schrägstrich passiert, ist nicht Teil des DNS und versteht nslookup nicht.
curl beispielsweise beschwert sich nicht und betrachtet dies einfach als die Wurzel des Webservers.
curl example.com/
<!doctype html>
<html>
<head>
<title>Example Domain</title>