18
Namensauflösung mit Debian bind9 ist mir nicht ganz klar
Hallo zusammen
Ich habe im Betrieb einen Linux Debian DNS Server aufgesetzt. Dazu habe ich bind9 verwendet.
Diese Lösung läuft nun seit 3-4 Monaten und bisher gab es keine Zwischenfälle, doch nun ist mir etwas aufgefallen, was mir nicht ganz klar erscheint.
Diese Frage ist aufgetreten, als ich einen SMTP Server aufsetzen musste. Als dieser aufgesetzt war, konnte ich von einem anderen Linux Debian Server via Telnet folgendermassen darauf zugreifen.
Wenn ich das aber mit dem fully qualified Servername ausprobiert habe, sah es so aus.
Als ich nur den Servername genommen habe, hat es funktioniert.
Nun zu meiner Frage. Wenn ich von einem Linux Debian Server pinge, erhalte ich diese Resultate.
Servername:
Funktioniert einwandfrei.
Fully Qualified Name:
Das funktioniert nicht. Warum?
Von einem Windows 7 Client funktionieren beide Varianten.
Es wäre super wenn mir das jemand erklären könnte
Scheint mir persönlich ein wenig unlogisch.
Freundliche Grüsse
jompsi
Ich habe im Betrieb einen Linux Debian DNS Server aufgesetzt. Dazu habe ich bind9 verwendet.
Diese Lösung läuft nun seit 3-4 Monaten und bisher gab es keine Zwischenfälle, doch nun ist mir etwas aufgefallen, was mir nicht ganz klar erscheint.
Diese Frage ist aufgetreten, als ich einen SMTP Server aufsetzen musste. Als dieser aufgesetzt war, konnte ich von einem anderen Linux Debian Server via Telnet folgendermassen darauf zugreifen.
telnet 192.168.5.96 25telnet mail.fiktiv.local 25
telnet: could not resolve mail.fiktiv.local/25: Name or service not knowntelnet mail 25Nun zu meiner Frage. Wenn ich von einem Linux Debian Server pinge, erhalte ich diese Resultate.
Servername:
ping mail
PING mail.fiktiv.local (192.168.5.96) 56(84) bytes of data.
64 bytes from mail.fiktiv.local (192.168.5.96): icmp_req=1 ttl=64 time=0.305 msFully Qualified Name:
ping mail.fiktiv.local
ping: unknown host mail.fiktiv.localVon einem Windows 7 Client funktionieren beide Varianten.
Es wäre super wenn mir das jemand erklären könnte
Scheint mir persönlich ein wenig unlogisch.
Freundliche Grüsse
jompsi
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 206489
Url: https://administrator.de/forum/namensaufloesung-mit-debian-bind9-ist-mir-nicht-ganz-klar-206489.html
Ausgedruckt am: 23.12.2024 um 08:12 Uhr
18 Kommentare
Neuester Kommentar
Moin,
Vorab: PING ist kein Tool zum Prüfen der Namensauflösung, dazu nimmt man (unter Windows und Linux) nslookup!
Und noch zwei Fragen:
1) Was ist auf dem Win7 und dem Linux für ein Domain Suffix für die Namensauflösung konfiguriert?
2) Wie sieht denn der Eintrag in den Zonefiles und die bind9-Konfig aus?
lg,
Slainte
Vorab: PING ist kein Tool zum Prüfen der Namensauflösung, dazu nimmt man (unter Windows und Linux) nslookup!
Von einem Windows 7 Client funktionieren beide Varianten.
Weil evtl. der Win7 Rechner den Namen ggfs. per NetBios auflöst, und nicht per DNS - deswegen NSLOOKUP, nicht PING.Und noch zwei Fragen:
1) Was ist auf dem Win7 und dem Linux für ein Domain Suffix für die Namensauflösung konfiguriert?
2) Wie sieht denn der Eintrag in den Zonefiles und die bind9-Konfig aus?
lg,
Slainte
Poste mal den Inhalt deiner
/etc/resolv.conf
Hallo
Vielen Dank für die Antworten.
nslookup funktioniert mit Servername und mit fully qualified Name und das von einem Linux Debian Server und dem Windows 7 Client.
Wir arbeiten mit Workgroups. Beim Windows ist der DNS Suffix fiktiv.local. Wo kann ich das beim Linux Debian nachschauen?
Ausschnitt aus dem Zone File.
cat /etc/resolv.conf
Gruess
jompsi
Vielen Dank für die Antworten.
nslookup funktioniert mit Servername und mit fully qualified Name und das von einem Linux Debian Server und dem Windows 7 Client.
Wir arbeiten mit Workgroups. Beim Windows ist der DNS Suffix fiktiv.local. Wo kann ich das beim Linux Debian nachschauen?
Ausschnitt aus dem Zone File.
$ORIGIN fiktiv.local.
$ttl 10800
@ IN SOA infra1.fiktiv.local. root.fiktiv.local. (
12
8H
2H
4W
3H )
@ IN NS infra1.fiktiv.local.
infra1 IN A 192.168.1.87
mail IN A 192.168.1.96cat /etc/resolv.conf
# Generated by NetworkManager
domain fiktiv.local
search fiktiv.local
nameserver 192.168.1.87
nameserver 192.168.1.97
nameserver 208.67.222.222Gruess
jompsi
search fiktiv.localThere's your problem.
Wenn du
host.fiktiv.local eingibst, versucht Linux den Namen host.fiktiv.local.fiktiv.local aufzulösen.Das kannst du auch mit tcpdump (
tcpdump -i any port 53) nachvollziehen.search .Außerdem hat der Nameserver mit der öffentlichen IP da nichts zu suchen, wenn der nicht auch
fiktiv.local auflösen kann.# Generated by NetworkManager
domain fiktiv.local
#search fiktiv.local
nameserver 10.200.1.87
nameserver 10.200.1.97# Generated by NetworkManager
domain fiktiv.local
search .
nameserver 10.200.1.87
nameserver 10.200.1.97Danke für die Hilfe.
Zitat von @dog:
There's your problem.
Wenn du
Das kannst du auch mit tcpdump (
(oder ganz weglassen) ist besser.
Außerdem hat der Nameserver mit der öffentlichen IP da nichts zu suchen, wenn der nicht auch
auflösen kann.
search fiktiv.localThere's your problem.
Wenn du
host.fiktiv.local eingibst, versucht Linux den Namen host.fiktiv.local.fiktiv.local aufzulösen.Das kannst du auch mit tcpdump (
tcpdump -i any port 53) nachvollziehen.search .Außerdem hat der Nameserver mit der öffentlichen IP da nichts zu suchen, wenn der nicht auch
fiktiv.localauflösen kann.
Die Information ist Unsinn.
Linux probiert doch immer erstmal eine FQDN Auflösung. Erst wenn das fehlschlägt wird der Search-Parameter ausgewertet und angehangen.
Mir ist im Leben auch noch nie ein Rechner mit search . begegnet.
Der Nameserver fühlt sich aber schon Zuständig für die betreffende Domäne, oder?
Die Information ist Unsinn.
Nein, ist es nicht. Habe ich mehrmals auf unterschiedlichen Distros gesehen.
Der Verweis auf tcpdump kommt ja nicht zum Spaß.
Ja, der Nameserver fühlt sich verantwortlich. Beim nslookup sehe ich, dass er auf den richten Nameserver geht und auch die korrekten Daten zurück gibt.
Deshalb bin ich ein wenig verwirrt, dass das Problem beim Ping auftritt. Ich möchte eigentlich, dass beide Varianten funktionieren. Nur Servername pingen und fully qualified Name pingen.
Deshalb bin ich ein wenig verwirrt, dass das Problem beim Ping auftritt. Ich möchte eigentlich, dass beide Varianten funktionieren. Nur Servername pingen und fully qualified Name pingen.
Beim nslookup sehe ich, dass er auf den richten Nameserver geht und auch die korrekten Daten zurück gibt.
Weil nslookup/dig ein Debug-Tool ist, was direkt die eingestellen Nameserver abfragt.
Der System-Resolver arbeitet anders!
Starte den oben genannten tcpdump-Befehl und in einem anderen Terminal (auf dem selben PC) ein ping und poste die Ausgabe.
Alternativ versuch in deiner Ausgangskonfiguration mal
ping host.fiktiv.local. (der Punkt am Ende ist entscheidend!) - das muss auf jeden Fall gehen.
Mir ist aufgefallen, dass bei zwei Linux Debian Servern nur der Ping mit dem Servername funktioniert und bei zwei anderen funktioniert der Ping mit dem Servername und fully qualified Name.
Weshalb ist mir noch nicht ersichtlich.
Zuerst den tcpdump von einem Server, bei welchem der Ping nur mit dem Servername funktioniert:
Beim Ping Versuch mit dem fully qualified Name erhalte icht nichts.
Und nun noch die zwei tcpdumps von einem Server, bei welchem beides funktioniert.
Servername:
fully qualified Name:
Vielen Dank für den Support
Weshalb ist mir noch nicht ersichtlich.
Zuerst den tcpdump von einem Server, bei welchem der Ping nur mit dem Servername funktioniert:
inhouse:~# tcpdump -i any port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
08:33:46.621860 IP inhouse.fiktiv.local.41409 > infra1.fiktiv.local.domain: 41534+ A? mail.fiktiv.local. (36)
08:33:46.622387 IP inhouse.fiktiv.local.42177 > infra1.fiktiv.local.domain: 16235+ PTR? 87.1.168.192.in-addr.arpa. (42)
08:33:46.622593 IP infra1.fiktiv.local.domain > inhouse.fiktiv.local.41409: 41534* 1/1/1 A 192.168.1.96 (89)
08:33:46.622964 IP infra1.fiktiv.local.domain > inhouse.fiktiv.local.42177: 16235* 1/1/1 PTR infra1.fiktiv.local. (106)
08:33:46.623117 IP inhouse.fiktiv.local.43469 > infra1.fiktiv.local.domain: 61905+ PTR? 86.1.168.192.in-addr.arpa. (42)
08:33:46.623797 IP infra1.fiktiv.local.domain > inhouse.fiktiv.local.43469: 61905* 1/1/1 PTR inhouse.fiktiv.local. (114)
08:33:46.625811 IP inhouse.fiktiv.local.47807 > infra1.fiktiv.local.domain: 45087+ PTR? 96.1.168.192.in-addr.arpa. (42)
08:33:46.626474 IP infra1.fiktiv.local.domain > inhouse.fiktiv.local.47807: 45087* 1/1/1 PTR mail.fiktiv.local. (111)
08:33:47.625206 IP inhouse.fiktiv.local.41349 > infra1.fiktiv.local.domain: 11908+ PTR? 96.1.168.192.in-addr.arpa. (42)
08:33:47.625867 IP infra1.fiktiv.local.domain > inhouse.fiktiv.local.41349: 11908* 1/1/1 PTR mail.fiktiv.local. (111)Und nun noch die zwei tcpdumps von einem Server, bei welchem beides funktioniert.
Servername:
joe:~# tcpdump -i any port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
08:31:47.838868 IP joe.fiktiv.local.59821 > infra1.fiktiv.local.domain: 39926+ A? mail.fiktiv.local. (36)
08:31:47.839256 IP joe.fiktiv.local.51867 > infra1.fiktiv.local.domain: 7156+ PTR? 87.1.168.192.in-addr.arpa. (42)
08:31:47.839741 IP infra1.fiktiv.local.domain > joe.fiktiv.local.59821: 39926* 1/1/1 A 192.168.1.96 (89)
08:31:47.839834 IP infra1.fiktiv.local.domain > joe.fiktiv.local.51867: 7156* 1/1/1 PTR infra1.fiktiv.local. (106)
08:31:47.839946 IP joe.fiktiv.local.41968 > infra1.fiktiv.local.domain: 4984+ PTR? 98.1.168.192.in-addr.arpa. (42)
08:31:47.840237 IP joe.fiktiv.local.55112 > infra1.fiktiv.local.domain: 45687+ PTR? 96.1.168.192.in-addr.arpa. (42)
08:31:47.840677 IP infra1.fiktiv.local.domain > joe.fiktiv.local.41968: 4984* 1/1/1 PTR joe.fiktiv.local. (110)
08:31:47.840797 IP infra1.fiktiv.local.domain > joe.fiktiv.local.55112: 45687* 1/1/1 PTR mail.fiktiv.local. (111)
08:31:48.840832 IP joe.fiktiv.local.41241 > infra1.fiktiv.local.domain: 6904+ PTR? 96.1.168.192.in-addr.arpa. (42)
08:31:48.841544 IP infra1.fiktiv.local.domain > joe.fiktiv.local.41241: 6904* 1/1/1 PTR mail.fiktiv.local. (111)fully qualified Name:
joe:~# tcpdump -i any port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
08:32:04.294901 IP joe.fiktiv.local.51616 > infra1.fiktiv.local.domain: 50290+ A? mail.fiktiv.local. (36)
08:32:04.295288 IP joe.fiktiv.local.60213 > infra1.fiktiv.local.domain: 18748+ PTR? 87.1.168.192.in-addr.arpa. (42)
08:32:04.295442 IP infra1.fiktiv.local.domain > joe.fiktiv.local.51616: 50290* 1/1/1 A 192.168.1.96 (89)
08:32:04.295799 IP infra1.fiktiv.local.domain > joe.fiktiv.local.60213: 18748* 1/1/1 PTR infra1.fiktiv.local. (106)
08:32:04.295951 IP joe.fiktiv.local.58705 > infra1.fiktiv.local.domain: 17956+ PTR? 98.1.168.192.in-addr.arpa. (42)
08:32:04.296001 IP joe.fiktiv.local.40656 > infra1.fiktiv.local.domain: 60754+ PTR? 96.1.168.192.in-addr.arpa. (42)
08:32:04.296672 IP infra1.fiktiv.local.domain > joe.fiktiv.local.58705: 17956* 1/1/1 PTR joe.fiktiv.local. (110)
08:32:04.296762 IP infra1.fiktiv.local.domain > joe.fiktiv.local.40656: 60754* 1/1/1 PTR mail.fiktiv.local. (111)
08:32:05.296281 IP joe.fiktiv.local.44526 > infra1.fiktiv.local.domain: 13107+ PTR? 96.1.168.192.in-addr.arpa. (42)
08:32:05.296952 IP infra1.fiktiv.local.domain > joe.fiktiv.local.44526: 13107* 1/1/1 PTR mail.fiktiv.local. (111)Vielen Dank für den Support
Ich hoffe das hat keinen grossen Einfluss, aber die Server sind virtualisiert. Tut mir leid, ist mir erst jetzt in den Sinn gekommen. Diese Information ist hoffentlich nicht ausschlaggebend für die Problemlokalisierung. 
Wie du erhältst nichts?
Wenn da nichts kommt, dann stellt der Rechner auch keine Anfrage an den DNS-Server.
Wenn er keine Anfrage an den DNS-Server stellt, dann können wir diesen auch als Fehlerquelle erstmal ausschließen.
Dein Problem liegt wohl also bei den Rechnern, die den DNS-Server gar nicht erst befragen.
Evtl. irgendwas in den hosts-Dateien? Obwohl, dann sollter er ja nicht mit "unknown host" reagieren.
Wie sieht es mit /etc/host.conf aus?
Ich erhalte nichts im tcpdump wenn ich den fully qualified Name angebe.
Die hosts Dateien sind in Ordnung. Gibt keine Abweichung von den Servern wo es funktioniert und denen bei jenen der Fehler auftritt.
host.conf
Dieser Wert steht bei allen Servern drin.
Die hosts Dateien sind in Ordnung. Gibt keine Abweichung von den Servern wo es funktioniert und denen bei jenen der Fehler auftritt.
host.conf
multi onDieser Wert steht bei allen Servern drin.
Und wie sieht deine
/etc/hosts aus?
/etc/hosts
127.0.0.1 localhost
127.0.1.1 infra1.fiktiv.local infra1
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Langsam....ich dachte inhouse wäre der Server der nicht geht? Und auf welchem Server hast du jetzt tcpdump ausgeführt?
Morgen
Es geht auf dem Server inhouse und infra1 nicht. tcpdump habe ich auf beiden ausgeführt. Habe aber nur das Resultat von inhouse gepostet, weil bei beiden im tcpdump nichts erscheint, wenn ich den Namen fully qualified Name anpinge.
Auf dem Server joe funktioniert beides und von diesem habe ich oben auch von beiden Testszenarien den tcpdump gepostet.
/etc/hosts von inhouse
Es geht auf dem Server inhouse und infra1 nicht. tcpdump habe ich auf beiden ausgeführt. Habe aber nur das Resultat von inhouse gepostet, weil bei beiden im tcpdump nichts erscheint, wenn ich den Namen fully qualified Name anpinge.
Auf dem Server joe funktioniert beides und von diesem habe ich oben auch von beiden Testszenarien den tcpdump gepostet.
/etc/hosts von inhouse
127.0.0.1 localhost
127.0.1.1 inhouse.fiktiv.local inhouse
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Hallo zusammen
Ich habe die Lösung nun gefunden
Bei den Servern, bei welchen es nicht funktioniert hat den FQDN zu pingen sah die Datei /etc/nsswitch.conf folgendermassen aus:
Bei den Rechnern, bei welchen der ping auf den FQDN funktioniert, sieht die Datei so aus:
Wenn man die Linie Hosts folgendermassen anpasst:
Funktioniert es.
Mir ist nicht erklärlich, warum es bei ein paar Servern korrekt eingetragen war und bei ein paar anderen nicht. Ich habe die Datei erst gerade entdeckt und habe dort nicht den Fehler selbst eingebaut.
Vielen Dank für die Unterstützung @dog und @fnord2000
Ich habe die Lösung nun gefunden
Bei den Servern, bei welchen es nicht funktioniert hat den FQDN zu pingen sah die Datei /etc/nsswitch.conf folgendermassen aus:
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: compat
group: compat
shadow: compat
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: compat
group: compat
shadow: compat
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nisWenn man die Linie Hosts folgendermassen anpasst:
hosts: files dnsMir ist nicht erklärlich, warum es bei ein paar Servern korrekt eingetragen war und bei ein paar anderen nicht. Ich habe die Datei erst gerade entdeckt und habe dort nicht den Fehler selbst eingebaut.
Vielen Dank für die Unterstützung @dog und @fnord2000
