it-swarm.com.de

Lokale Domänen in meinem Office-LAN können nicht aufgelöst werden

Unter Linux Debian 9 kann ich eine bestimmte lokale Domäne auflösen, z. my.sample-domain.local Mit einigen Befehlen wie nslookup oder Host, jedoch nicht mit einigen anderen Befehlen wie ping oder dem Postgres-Client psql.

Ich denke, Dinge wie Network Manager haben meinen DNS-Resolver korrekt eingerichtet (der Inhalt von /etc/resolv.conf), Daher bin ich mir nicht sicher, warum dies geschieht.

Ich habe mit einem Kollegen unter Windows 10 gesprochen, und er hat keinen benutzerdefinierten Eintrag in seiner Host-Datei, obwohl in seinem Fall die Windows-Version von ping und die Datenbank-Benutzeroberfläche für Postgres wie erwartet funktionieren und die Domäne in eine aufgelöst wird IP Adresse.

Siehe unten:

$ ping my.sample-domain.local
ping: my.sample-domain.local: Name or service not known

$ Host my.sample-domain.local
my.sample-domain.local has address <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>

$ ping -c 5 <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>
PING <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN> (<THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>) 56(84) bytes of data.
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=1 ttl=128 time=1.16 ms
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=2 ttl=128 time=0.644 ms
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=3 ttl=128 time=0.758 ms
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=4 ttl=128 time=0.684 ms
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=5 ttl=128 time=0.794 ms

--- <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN> ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4056ms
rtt min/avg/max/mdev = 0.644/0.808/1.160/0.183 ms

$ nslookup my.sample-domain.local
Server:        <THE_IP_REPRESENTING_THE_NAMESERVER>
Address:    <THE_IP_REPRESENTING_THE_NAMESERVER>#53

Non-authoritative answer:
Name:    my.sample-domain.local
Address: <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>


$ cat /etc/resolv.conf
domain <AN_INTERNAL_DOMAIN>
search <AN_INTERNAL_DOMAIN>
nameserver <THE_IP_REPRESENTING_THE_NAMESERVER>
nameserver <ANOTHER_IP_REPRESENTING_THE_NAMESERVER>

EDIT :

In der Zwischenzeit wurde mir klar, dass sich im selben Office-LAN eine virtuelle Ubuntu 16-Maschine befindet. Deshalb habe ich mich angemeldet und den Befehl ping ausprobiert, der dort funktioniert.

Auch das Ubuntu VM hat keine spezielle benutzerdefinierte Einstellung in /etc/hosts (Das gleiche wie mein Debian 9-Laptop mit nicht angepasstem /etc/hosts).

Beide /etc/resolv.conf Sehen ähnlich aus (einige gemeinsam genutzte Domänen/IPs, einige andere IPs für dieselbe Domäne).

Die Datei /etc/nsswitch.conf Ist jedoch anders, daher denke ich, dass mit diesem mdsn4_minimal Und der Reihenfolge der Hostauflösung etwas los ist, wie mdsn4_minimal Vor dns:

hosts:      files mdns4_minimal [NOTFOUND=return] dns

und unter Ubuntu:

hosts:      files dns

EDIT 2 :

Sowohl Ubuntu 16 VM] als auch mein Debian 9-Laptop können diese .local - Domäne mit dem Befehl Dig auflösen.

9
TPPZ

Host und nslookup führen DNS-Suchvorgänge durch. Die meisten Anwendungen verwenden jedoch glibcs ​​ Name Service Switch, um zu entscheiden, wie Hostnamen gesucht werden.

Ihr /etc/nsswitch.conf Aktiviert möglicherweise mDNS, was zu Problemen beim Auflösen von .local - Namen führen kann. Sie können die Reihenfolge ändern, in der Suchvorgänge durchgeführt werden, oder den mDNS-Dienst einfach entfernen, wenn Sie der Meinung sind, dass Sie ihn nicht benötigen.

Ihr nsswitch.conf Hat mdns4_minimal, Was mDNS Lookup (für .local Namen) ausführt. Das [NOTFOUND=return], Nachdem es die Suche beendet hat und daher DNS nie verwendet wird und Ihre Anwendung den Hostnamen nicht auflösen kann. Sie können entweder das gesamte mdns4_minimal [NOTFOUND=return] Entfernen, damit keine mDNS-Suchvorgänge verwendet werden, oder einfach die NOTFOUND-Aktion entfernen, damit die DNS-Suche durchgeführt wird, falls die mDNS-Suche fehlschlägt.

Weitere Informationen finden Sie in der Dokumentation zu Name Service Switch .

18
sebasth

Das größere Problem hierbei ist: Es ist bekannt, dass DNS-Domänennamen, die mit .local Enden, beim Einrichten von DNS-Infrastrukturen nicht verwendet werden sollten.

Die Verwendung von .local Ist für die Verwendung von zeroconf/avahi aka bonjour reserviert. Hierbei handelt es sich um parallele Dienste zum Auflösen lokaler Namen/Dienste neben DNS.

Ihr interner DNS-Namensdienst hat in einigen Szenarien mit Sicherheit Konflikte mit zeroconf. Also die Lösung in der Frage, die Sie akzeptiert haben.

Langfristig sollte Ihr interner Netzwerk-DNS-Name nicht mit .local Enden.

PS Neben DNS sollten auch lokale Microsoft DCs/ADs nicht .local Benannt werden. Sie werden seltsame Probleme haben, wenn Sie das tun.

Multicast-DNS-Standard (mDNS).
Der Standard-Track RFC 6762 der Internet Engineering Task Force (IETF) (20. Februar 2013) behält sich die Verwendung des Domain-Namenslabels local als Pseudo-Top-Level-Domain für Hostnamen in lokalen Netzwerken vor Wird über das Multicast-DNS-Namensauflösungsprotokoll aufgelöst.

Von MS Technet (Wikipedia)

Wenn Sie über Macintosh-Clientcomputer verfügen, auf denen das Betriebssystem Macintosh OS X Version 10.3 oder höher ausgeführt wird, wird empfohlen, die Bezeichnung .local nicht für den vollständigen DNS-Namen Ihrer internen Domäne zu verwenden. Wenn Sie die Bezeichnung .local verwenden müssen, müssen Sie auch die Einstellungen auf den Macintosh-Computern konfigurieren, damit diese andere Computer im Netzwerk erkennen können

RFC 6762

Jede DNS-Abfrage für einen Namen, der mit ".local" endet. MUSS an die gesendet werden
mdNS IPv4-verbindungslokale Multicast-Adresse 224.0.0.251 (oder deren IPv6)
äquivalent FF02 :: FB).

......

  1. Reverse Address Mapping

    Wie ".local." Werden auch die IPv4- und IPv6-Reverse-Mapping-Domänen als verbindungslokal definiert:

    Jede DNS-Abfrage für einen Namen, der mit "254.169.in-addr.arpa" endet. MUSS an die verbindungslokale mDNS IPv4-Multicast-Adresse 224.0.0.251 oder die mDNS IPv6-Multicast-Adresse FF02 :: FB gesendet werden. Da Namen unter dieser Domäne IPv4-Link-lokalen Adressen entsprechen, ist es logisch, dass der lokale Link der beste Ort ist, um Informationen zu diesen Namen zu finden.

......

Zum Aktivieren und Deaktivieren von Multicast-DNS für Namen, die explizit mit ".local" enden, ist keine spezielle Steuerung erforderlich. wie vom Benutzer eingegeben.
Der Benutzer benötigt keine Möglichkeit, Multicast-DNS für Namen zu deaktivieren, die mit ".local" enden. Wenn der Benutzer Multicast-DNS nicht verwenden möchte, kann er dies erreichen, indem er diese Namen einfach nicht verwendet .
Wenn ein Benutzer einen Namen eingibt, der auf ".local." Endet, können wir davon ausgehen, dass der Benutzer wahrscheinlich die Absicht hatte, dies zu tun sollte arbeiten.

Obwohl ich nicht aus einer offiziellen Quelle stamme, habe ich auch diesen gefunden, der einen Absatz enthält, der das Problem gut erklärt: Verwenden Sie .local nicht mehr als Top-Level-Domain für Ihr LAN

Die .local-Domäne wird als Pseudo-Top-Level-Domäne bezeichnet. Was bedeutet das? Dies bedeutet, dass es sich nicht um eine offizielle Top-Level-Domain handelt, die im Internet verwendet (routingfähig) werden kann, sondern eine halboffizielle Stellung hat, da sie in einigen Anwendungen verwendet wird.
Im Fall von .local wird es vom Multicast Domain Name Service (mDNS) verwendet. Hosts, die diesen Dienst implementieren, verwenden .local als Domänennamen und haben ihre eigene Methode zum Auflösen von Namen. Normalerweise wäre dies kein Problem. Wenn Sie jedoch auch DNS in Ihrem Netzwerk mit .local als Top-Level-Domain implementieren, führt dies zu schwerwiegenden Problemen bei der Namensauflösung.
Ich habe gesehen, dass dies auf Linux-Systemen häufig vorkommt, und ich kann mir vorstellen, dass Apples OS X wahrscheinlich auch diese Probleme haben wird. Normalerweise stellen Sie in diesen Netzwerktypen fest, dass die DNS-Namensauflösung überhaupt nicht oder nur teilweise funktioniert. Am Ende müssen Sie die ganze Zeit IP-Adressen verwenden, da Sie nicht wissen, ob ein Name aufgelöst werden kann oder nicht (was den Sinn eines DNS-Servers zunichte macht).

7
Rui F Ribeiro

Vielleicht haben Sie ein NBNS , das mit einem DNS in Konflikt steht, also korrigieren Sie das oder bearbeiten Sie es Ihre Hosts Datei oder verpacken Sie Ihre Befehle;

NAME=my.sample-domain.local
ping $(Host $NAME | Perl -pe 's/.* //g')

DNS sollte mit Dig überprüft werden;

Dig @$SERVER $NAME +short

Ich vermute Host sucht zuerst nach NBNS (oder umgekehrt).

0
user1133275