jompsi
May 15, 2013, updated at 09:06:13 (UTC)
view4296
view18
0
Goto Top

Namensauflösung mit Debian bind9 ist mir nicht ganz klar

GermansolvedQuestionLinux NetworkLinux
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.
telnet 192.168.5.96 25
Wenn ich das aber mit dem fully qualified Servername ausprobiert habe, sah es so aus.
telnet mail.fiktiv.local 25
telnet: could not resolve mail.fiktiv.local/25: Name or service not known
Als ich nur den Servername genommen habe, hat es funktioniert.
telnet mail 25

Nun 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 ms
Funktioniert einwandfrei.

Fully Qualified Name:
ping mail.fiktiv.local
ping: unknown host mail.fiktiv.local
Das funktioniert nicht. Warum?

Von einem Windows 7 Client funktionieren beide Varianten.

Es wäre super wenn mir das jemand erklären könnte face-smile
Scheint mir persönlich ein wenig unlogisch.

Freundliche Grüsse
jompsi
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 206489

Url: https://administrator.de/contentid/206489

Printed on: May 7, 2024 at 23:05 o'clock

18 Comments
Latest comment
Goto Top
Member: SlainteMhath
SlainteMhath May 15, 2013 at 09:24:21 (UTC)
Goto Top
Moin,

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
Member: dog
dog May 15, 2013 at 09:36:41 (UTC)
Goto Top
Poste mal den Inhalt deiner /etc/resolv.conf
Member: jompsi
jompsi May 15, 2013 at 09:52:15 (UTC)
Goto Top
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.
$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.96

cat /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.222

Gruess
jompsi
Member: dog
dog May 15, 2013 updated at 10:11:35 (UTC)
Goto Top
search fiktiv.local

There'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 .
(oder ganz weglassen) ist besser.

Außerdem hat der Nameserver mit der öffentlichen IP da nichts zu suchen, wenn der nicht auch fiktiv.local auflösen kann.
Member: jompsi
jompsi May 15, 2013 updated at 10:28:37 (UTC)
Goto Top
# Generated by NetworkManager
domain fiktiv.local
#search fiktiv.local
nameserver 10.200.1.87
nameserver 10.200.1.97
Bei dieser Änderung geht der ping nur mit mail. mail.fiktiv.local gibt immer noch dieselebe FM.

# Generated by NetworkManager
domain fiktiv.local
search .
nameserver 10.200.1.87
nameserver 10.200.1.97
und so geht der ping gar nicht mehr und beim nslookup funktioniert nur noch der fully qualified Name.

Danke für die Hilfe.
Member: fnord2000
fnord2000 May 15, 2013 at 10:31:41 (UTC)
Goto Top
Zitat von @dog:
search fiktiv.local

There'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 .
(oder ganz weglassen) ist besser.

Außerdem hat der Nameserver mit der öffentlichen IP da nichts zu suchen, wenn der nicht auch fiktiv.local
auflö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?
Member: dog
dog May 15, 2013 at 10:48:58 (UTC)
Goto Top
Die Information ist Unsinn.

Nein, ist es nicht. Habe ich mehrmals auf unterschiedlichen Distros gesehen.
Der Verweis auf tcpdump kommt ja nicht zum Spaß.
Member: jompsi
jompsi May 15, 2013 at 15:18:42 (UTC)
Goto Top
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.
Member: dog
dog May 15, 2013 updated at 16:08:47 (UTC)
Goto Top
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.
Member: jompsi
jompsi May 16, 2013 at 06:51:45 (UTC)
Goto Top
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:
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)
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:
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
Member: jompsi
jompsi May 16, 2013 at 06:55:19 (UTC)
Goto Top
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. face-sad
Member: fnord2000
fnord2000 May 16, 2013 at 07:20:38 (UTC)
Goto Top
Zitat von @jompsi:
Beim Ping Versuch mit dem fully qualified Name erhalte icht nichts.

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?
Member: jompsi
jompsi May 16, 2013 at 07:42:25 (UTC)
Goto Top
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
multi on

Dieser Wert steht bei allen Servern drin.
Member: dog
dog May 16, 2013 at 08:03:04 (UTC)
Goto Top
Und wie sieht deine /etc/hosts aus?
Member: jompsi
jompsi May 16, 2013 at 08:19:09 (UTC)
Goto Top
/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
Member: dog
dog May 16, 2013 at 10:15:12 (UTC)
Goto Top
Langsam....ich dachte inhouse wäre der Server der nicht geht? Und auf welchem Server hast du jetzt tcpdump ausgeführt?
Member: jompsi
jompsi May 21, 2013 updated at 06:25:04 (UTC)
Goto Top
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
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
Member: jompsi
jompsi May 21, 2013 updated at 09:10:09 (UTC)
Goto Top
Hallo zusammen

Ich habe die Lösung nun gefunden face-smile

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
Bei den Rechnern, bei welchen der ping auf den FQDN funktioniert, sieht die Datei so 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 dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Wenn man die Linie Hosts folgendermassen anpasst:
hosts:          files dns
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 face-smile
GermansolvedQuestionLinux NetworkLinux
Hotly discussed
LinuxeroWireguard with systemd and nftablesLinuxero - 9 Comments