Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit
GELÖST

Namensauflösung mit Debian bind9 ist mir nicht ganz klar

Frage Linux Linux Netzwerk

Mitglied: jompsi

jompsi (Level 1) - Jetzt verbinden

15.05.2013, aktualisiert 11:06 Uhr, 2753 Aufrufe, 18 Kommentare

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.
01.
telnet 192.168.5.96 25
Wenn ich das aber mit dem fully qualified Servername ausprobiert habe, sah es so aus.
01.
telnet mail.fiktiv.local 25 
02.
telnet: could not resolve mail.fiktiv.local/25: Name or service not known
Als ich nur den Servername genommen habe, hat es funktioniert.
01.
telnet mail 25
Nun zu meiner Frage. Wenn ich von einem Linux Debian Server pinge, erhalte ich diese Resultate.
Servername:
01.
ping mail 
02.
PING mail.fiktiv.local (192.168.5.96) 56(84) bytes of data. 
03.
64 bytes from mail.fiktiv.local (192.168.5.96): icmp_req=1 ttl=64 time=0.305 ms
Funktioniert einwandfrei.

Fully Qualified Name:
01.
ping mail.fiktiv.local 
02.
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
Scheint mir persönlich ein wenig unlogisch.

Freundliche Grüsse
jompsi

Mitglied: SlainteMhath
15.05.2013 um 11:24 Uhr
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
Bitte warten ..
Mitglied: dog
15.05.2013 um 11:36 Uhr
Poste mal den Inhalt deiner /etc/resolv.conf
Bitte warten ..
Mitglied: jompsi
15.05.2013 um 11:52 Uhr
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.
01.
$ORIGIN fiktiv.local. 
02.
$ttl 10800 
03.
@       IN      SOA     infra1.fiktiv.local. root.fiktiv.local. ( 
04.
                        12 
05.
                        8H 
06.
                        2H 
07.
                        4W 
08.
                        3H ) 
09.
@                               IN      NS      infra1.fiktiv.local. 
10.
infra1                          IN      A       192.168.1.87 
11.
mail                            IN      A       192.168.1.96
cat /etc/resolv.conf
01.
# Generated by NetworkManager 
02.
domain fiktiv.local 
03.
search fiktiv.local 
04.
nameserver 192.168.1.87 
05.
nameserver 192.168.1.97 
06.
nameserver 208.67.222.222
Gruess
jompsi
Bitte warten ..
Mitglied: dog
15.05.2013, aktualisiert um 12:11 Uhr
01.
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.

01.
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.
Bitte warten ..
Mitglied: jompsi
15.05.2013, aktualisiert um 12:28 Uhr
01.
# Generated by NetworkManager 
02.
domain fiktiv.local 
03.
#search fiktiv.local 
04.
nameserver 10.200.1.87 
05.
nameserver 10.200.1.97
Bei dieser Änderung geht der ping nur mit mail. mail.fiktiv.local gibt immer noch dieselebe FM.

01.
# Generated by NetworkManager 
02.
domain fiktiv.local 
03.
search . 
04.
nameserver 10.200.1.87 
05.
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.
Bitte warten ..
Mitglied: fnord2000
15.05.2013 um 12:31 Uhr
Zitat von dog:
01.
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.

01.
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?
Bitte warten ..
Mitglied: dog
15.05.2013 um 12:48 Uhr
Die Information ist Unsinn.

Nein, ist es nicht. Habe ich mehrmals auf unterschiedlichen Distros gesehen.
Der Verweis auf tcpdump kommt ja nicht zum Spaß.
Bitte warten ..
Mitglied: jompsi
15.05.2013 um 17:18 Uhr
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.
Bitte warten ..
Mitglied: dog
15.05.2013, aktualisiert um 18:08 Uhr
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.
Bitte warten ..
Mitglied: jompsi
16.05.2013 um 08:51 Uhr
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:
01.
inhouse:~# tcpdump -i any port 53 
02.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode 
03.
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 
04.
08:33:46.621860 IP inhouse.fiktiv.local.41409 > infra1.fiktiv.local.domain: 41534+ A? mail.fiktiv.local. (36) 
05.
08:33:46.622387 IP inhouse.fiktiv.local.42177 > infra1.fiktiv.local.domain: 16235+ PTR? 87.1.168.192.in-addr.arpa. (42) 
06.
08:33:46.622593 IP infra1.fiktiv.local.domain > inhouse.fiktiv.local.41409: 41534* 1/1/1 A 192.168.1.96 (89) 
07.
08:33:46.622964 IP infra1.fiktiv.local.domain > inhouse.fiktiv.local.42177: 16235* 1/1/1 PTR infra1.fiktiv.local. (106) 
08.
08:33:46.623117 IP inhouse.fiktiv.local.43469 > infra1.fiktiv.local.domain: 61905+ PTR? 86.1.168.192.in-addr.arpa. (42) 
09.
08:33:46.623797 IP infra1.fiktiv.local.domain > inhouse.fiktiv.local.43469: 61905* 1/1/1 PTR inhouse.fiktiv.local. (114) 
10.
08:33:46.625811 IP inhouse.fiktiv.local.47807 > infra1.fiktiv.local.domain: 45087+ PTR? 96.1.168.192.in-addr.arpa. (42) 
11.
08:33:46.626474 IP infra1.fiktiv.local.domain > inhouse.fiktiv.local.47807: 45087* 1/1/1 PTR mail.fiktiv.local. (111) 
12.
08:33:47.625206 IP inhouse.fiktiv.local.41349 > infra1.fiktiv.local.domain: 11908+ PTR? 96.1.168.192.in-addr.arpa. (42) 
13.
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:
01.
joe:~# tcpdump -i any port 53 
02.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode 
03.
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 
04.
08:31:47.838868 IP joe.fiktiv.local.59821 > infra1.fiktiv.local.domain: 39926+ A? mail.fiktiv.local. (36) 
05.
08:31:47.839256 IP joe.fiktiv.local.51867 > infra1.fiktiv.local.domain: 7156+ PTR? 87.1.168.192.in-addr.arpa. (42) 
06.
08:31:47.839741 IP infra1.fiktiv.local.domain > joe.fiktiv.local.59821: 39926* 1/1/1 A 192.168.1.96 (89) 
07.
08:31:47.839834 IP infra1.fiktiv.local.domain > joe.fiktiv.local.51867: 7156* 1/1/1 PTR infra1.fiktiv.local. (106) 
08.
08:31:47.839946 IP joe.fiktiv.local.41968 > infra1.fiktiv.local.domain: 4984+ PTR? 98.1.168.192.in-addr.arpa. (42) 
09.
08:31:47.840237 IP joe.fiktiv.local.55112 > infra1.fiktiv.local.domain: 45687+ PTR? 96.1.168.192.in-addr.arpa. (42) 
10.
08:31:47.840677 IP infra1.fiktiv.local.domain > joe.fiktiv.local.41968: 4984* 1/1/1 PTR joe.fiktiv.local. (110) 
11.
08:31:47.840797 IP infra1.fiktiv.local.domain > joe.fiktiv.local.55112: 45687* 1/1/1 PTR mail.fiktiv.local. (111) 
12.
08:31:48.840832 IP joe.fiktiv.local.41241 > infra1.fiktiv.local.domain: 6904+ PTR? 96.1.168.192.in-addr.arpa. (42) 
13.
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:
01.
joe:~# tcpdump -i any port 53 
02.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode 
03.
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 
04.
08:32:04.294901 IP joe.fiktiv.local.51616 > infra1.fiktiv.local.domain: 50290+ A? mail.fiktiv.local. (36) 
05.
08:32:04.295288 IP joe.fiktiv.local.60213 > infra1.fiktiv.local.domain: 18748+ PTR? 87.1.168.192.in-addr.arpa. (42) 
06.
08:32:04.295442 IP infra1.fiktiv.local.domain > joe.fiktiv.local.51616: 50290* 1/1/1 A 192.168.1.96 (89) 
07.
08:32:04.295799 IP infra1.fiktiv.local.domain > joe.fiktiv.local.60213: 18748* 1/1/1 PTR infra1.fiktiv.local. (106) 
08.
08:32:04.295951 IP joe.fiktiv.local.58705 > infra1.fiktiv.local.domain: 17956+ PTR? 98.1.168.192.in-addr.arpa. (42) 
09.
08:32:04.296001 IP joe.fiktiv.local.40656 > infra1.fiktiv.local.domain: 60754+ PTR? 96.1.168.192.in-addr.arpa. (42) 
10.
08:32:04.296672 IP infra1.fiktiv.local.domain > joe.fiktiv.local.58705: 17956* 1/1/1 PTR joe.fiktiv.local. (110) 
11.
08:32:04.296762 IP infra1.fiktiv.local.domain > joe.fiktiv.local.40656: 60754* 1/1/1 PTR mail.fiktiv.local. (111) 
12.
08:32:05.296281 IP joe.fiktiv.local.44526 > infra1.fiktiv.local.domain: 13107+ PTR? 96.1.168.192.in-addr.arpa. (42) 
13.
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
Bitte warten ..
Mitglied: jompsi
16.05.2013 um 08:55 Uhr
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.
Bitte warten ..
Mitglied: fnord2000
16.05.2013 um 09:20 Uhr
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?
Bitte warten ..
Mitglied: jompsi
16.05.2013 um 09:42 Uhr
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
01.
multi on
Dieser Wert steht bei allen Servern drin.
Bitte warten ..
Mitglied: dog
16.05.2013 um 10:03 Uhr
Und wie sieht deine /etc/hosts aus?
Bitte warten ..
Mitglied: jompsi
16.05.2013 um 10:19 Uhr
/etc/hosts
01.
127.0.0.1       localhost 
02.
127.0.1.1       infra1.fiktiv.local    infra1 
03.
 
04.
# The following lines are desirable for IPv6 capable hosts 
05.
::1     ip6-localhost ip6-loopback 
06.
fe00::0 ip6-localnet 
07.
ff00::0 ip6-mcastprefix 
08.
ff02::1 ip6-allnodes 
09.
ff02::2 ip6-allrouters
Bitte warten ..
Mitglied: dog
16.05.2013 um 12:15 Uhr
Langsam....ich dachte inhouse wäre der Server der nicht geht? Und auf welchem Server hast du jetzt tcpdump ausgeführt?
Bitte warten ..
Mitglied: jompsi
21.05.2013, aktualisiert um 08:25 Uhr
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
01.
127.0.0.1       localhost 
02.
127.0.1.1       inhouse.fiktiv.local   inhouse 
03.
 
04.
# The following lines are desirable for IPv6 capable hosts 
05.
::1     ip6-localhost ip6-loopback 
06.
fe00::0 ip6-localnet 
07.
ff00::0 ip6-mcastprefix 
08.
ff02::1 ip6-allnodes 
09.
ff02::2 ip6-allrouters
Bitte warten ..
Mitglied: jompsi
21.05.2013, aktualisiert um 11:10 Uhr
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:
01.
# /etc/nsswitch.conf 
02.
03.
# Example configuration of GNU Name Service Switch functionality. 
04.
# If you have the `glibc-doc-reference' and `info' packages installed, try: 
05.
# `info libc "Name Service Switch"' for information about this file. 
06.
 
07.
passwd:         compat 
08.
group:          compat 
09.
shadow:         compat 
10.
 
11.
hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4 
12.
networks:       files 
13.
 
14.
protocols:      db files 
15.
services:       db files 
16.
ethers:         db files 
17.
rpc:            db files 
18.
 
19.
netgroup:       nis
Bei den Rechnern, bei welchen der ping auf den FQDN funktioniert, sieht die Datei so aus:
01.
# /etc/nsswitch.conf 
02.
03.
# Example configuration of GNU Name Service Switch functionality. 
04.
# If you have the `glibc-doc-reference' and `info' packages installed, try: 
05.
# `info libc "Name Service Switch"' for information about this file. 
06.
 
07.
passwd:         compat 
08.
group:          compat 
09.
shadow:         compat 
10.
 
11.
hosts:          files dns 
12.
networks:       files 
13.
 
14.
protocols:      db files 
15.
services:       db files 
16.
ethers:         db files 
17.
rpc:            db files 
18.
 
19.
netgroup:       nis
Wenn man die Linie Hosts folgendermassen anpasst:
01.
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
Bitte warten ..
Neuester Wissensbeitrag
Windows 10

Powershell 5 BSOD

(8)

Tipp von agowa338 zum Thema Windows 10 ...

Ähnliche Inhalte
Debian
Debian 8.6 Absichern? (12)

Frage von Motte990 zum Thema Debian ...

Linux Netzwerk
VPN Server mit Drosselung Linux Debian basiert (4)

Frage von Niklas434 zum Thema Linux Netzwerk ...

Heiß diskutierte Inhalte
Microsoft
Ordner mit LW-Buchstaben versehen und benennen (21)

Frage von Xaero1982 zum Thema Microsoft ...

Netzwerkmanagement
gelöst Anregungen, kleiner Betrieb, IT-Umgebung (18)

Frage von Unwichtig zum Thema Netzwerkmanagement ...

Windows Update
Treiberinstallation durch Windows Update läßt sich nicht verhindern (17)

Frage von liquidbase zum Thema Windows Update ...