Auflösungsprobleme

[BlackEye]

Hallo!

Ich bin neu im Thema Debian (komme von Gentoo) und habe hier aktuell ein Problem mit der Auflösung bestimmter Hostnames. DNS funktioniert grundsätzlich. Also internet z.B. is kein Problem. Aber bei manchen Domänen die unser Windows-Server via bedingter weiterleitung auflöst, bekomme ich hier irgendwie Probleme.

Folgendes z.B. geht:

Code: Alles auswählen

dig rechner.domain.intra

Hier bekomme ich die IP Adresse korrekt mitgeteilt.

Folgendes z.B. geht nicht:

Code: Alles auswählen

ping rechner.domain.intra
ping: unknown host rechner.domain.intra

Daraus folgt z.B. jetzt auch, dass eine Verbindung mittles krdc (rdp) auf diesen Rechner nicht funktioniert. Wenn ich einen ping auf die IP setze funktioniert es natürlich. Auch eine krdc Verbindung mittels IP funktioniert.

Hat da jemand eine passende Idee? Ich weiss hier gar nicht wo ich ansetzen soll. Hatte sowas noch nie...

Schöne Grüße
Martin

[Cae]

Komisch. Per FQDN sollte es eigentlich immer gehen; falls nur der Hostname nicht tun wuerde, waere der search- bzw. domain-Eintrag in der /etc/resolv.conf unter die Lupe zu nehmen. Evtl. ist die /etc/nsswitch.conf vermurkst, denn dig macht imho immer DNS, ping benutzt aber die normale inet_aton(3)-Routine, welche per nsswitch.conf(5) bestimmt wird.

Willkommen im Forum!

Gruss Cae

[BlackEye]

Guten Morgen und Danke für die Begrüßung

Mit der nsswitch.conf kenne ich mich leider gar nicht aus. Die resolv.conf ist korrekt eingerichtet.

Code: Alles auswählen

# cat /etc/resolv.conf
domain my.company.intra
search my.company.intra
nameserver 10.0.0.5

Code: Alles auswählen

# cat /etc/nsswitch.conf
# /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

Auf einem Server von mir (der unter Gentoo läuft) sieht diese Datei so aus:

Code: Alles auswählen

# cat /etc/nsswitch.conf
# /etc/nsswitch.conf:
# $Header: /var/cvsroot/gentoo/src/patchsets/glibc/extra/etc/nsswitch.conf,v 1.1 2006/09/29 23:52:23 vapier Exp $

passwd:      compat winbind
shadow:      compat winbind
group:       compat winbind

# passwd:    db files nis
# shadow:    db files nis
# group:     db files nis

hosts:       files dns
networks:    files dns

services:    db files
protocols:   db files
rpc:         db files
ethers:      db files
netmasks:    files
netgroup:    files
bootparams:  files

automount:   files
aliases:     files

Also könnte hier das Problem zu finden sein? Ich kenne mich mit den Einträgen mal null aus. Aber ich vermute es liegt am "hosts" Eintrag in dieser Konfiguration?

Vielen Dank und Grüße
Martin

[Cae]

Aber ich vermute es liegt am "hosts" Eintrag in dieser Konfiguration?

Ja, der sieht komisch aus. Kommentiere die Zeile mal aus und ergaenze

Code: Alles auswählen

hosts:	files dns

-- also ohne diese ominoesen mdns4-Eintraege. Vermutlich sorgt insbesondere das [NOTFOUND=return] dafuer, dass das DNS nie gefragt wird.

Ob Kerberos dann noch funktioniert oder ob das ueberhaupt voneinander abhaengig ist, weiss ich nicht.

Gruss Cae

[habakug]

Hallo!

Der Eintrag

Code: Alles auswählen

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4

ist in Debian Standard wenn libnss-mdns und somit Avahi/Zeroconf installiert ist. Hier [1] ist das nochmal alles erklärt.
In Windows-Domänen hat man es oft mit Problemen beim unicast/multicast DNS zu tun. Man kann die Avahi-Konfiguration aber anpassen [2].

Gruss, habakug

[1] https://gist.github.com/leommoore/5990718
[2] http://www.lowlevelmanager.com/2011/09/ ... local.html

[BlackEye]

Krass... was es alles für Fallstricke im Leben gibt..
Also es liegt ganz klar an diesem Avahi wegen der .local Domains.

Leider hat die Anpassung der avahi-daemon.conf mit "domain-name=alocal" (siehe [1]) nicht den gewünschten Erfolg gebracht.
Mit der Holzhammermethode und dem Umschreiben der nsswitch.conf ging es dann. Aber mit dem erwähnten Nebeneffekt, dass die Auflösung der .local Domains irgendwie ziemlich lange dauert (bitte der abschließenden Zeit von 10078ms beim Ping auf domain.local Beachtung schenken):

Code: Alles auswählen

$ ping -c 3 domain.local
PING domain.local (10.0.21.3) 56(84) bytes of data.
64 bytes from 10.0.21.3: icmp_req=1 ttl=125 time=40.4 ms
64 bytes from 10.0.21.3: icmp_req=2 ttl=125 time=30.7 ms
64 bytes from 10.0.21.3: icmp_req=3 ttl=125 time=31.6 ms

--- domain.local ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 10078ms
rtt min/avg/max/mdev = 30.784/34.275/40.437/4.370 ms

$ ping -c 3 10.0.21.3
PING 10.0.21.3 (10.0.21.3) 56(84) bytes of data.
64 bytes from 10.0.21.3: icmp_req=1 ttl=125 time=30.1 ms
64 bytes from 10.0.21.3: icmp_req=2 ttl=125 time=28.8 ms
64 bytes from 10.0.21.3: icmp_req=3 ttl=125 time=42.9 ms

--- 10.0.21.3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 28.848/33.993/42.949/6.359 ms

Also beim Ping auf den Hostnamen vergeht deutlich Zeit. Der Ping auf die IP ist wesentlich schneller.

Wäre natürlich schön, wenn ich das irgendwie 'vernünftig' hin bekäme. Aber lieber funktioniert es grundsätzlich als gar nicht

[1] Im Blog steht eigentlich, dass man "domain-name=.alocal" (also mit dem Punkt) angeben soll. Aber das führte zu einem Fehler und ich konnte den Daemon so nicht neu starten. Also muss ich es ohne den Punkt schreiben.

Besten Dank und Grüße
Martin

[dufty2]

Also beim Ping auf den Hostnamen vergeht deutlich Zeit. Der Ping auf die IP ist wesentlich schneller.

Tja, sorry, aber das ist immer so:
Selbst wenn der dns-server bei Dir lokal auf den Rechner laufen würde, würde eine Abfrage eine gewisssen Zeit in Anspruch nehmen als wenn "ping" die IP gleich direkt übernehmen kann.

Du könntest Dir mal die "Query time"-Zeile bei der Ausgabe von "dig ..." anschauen,
ob die DNS-Auflösung selbst schon recht langsam vor sich geht.

[Cae]

Also beim Ping auf den Hostnamen vergeht deutlich Zeit. Der Ping auf die IP ist wesentlich schneller.

Tja, sorry, aber das ist immer so:
Selbst wenn der dns-server bei Dir lokal auf den Rechner laufen würde, würde eine Abfrage eine gewisssen Zeit in Anspruch nehmen als wenn "ping" die IP gleich direkt übernehmen kann.

Aber knapp 8 Sekunden Overhead fuer eine einzelne Query...? Das ist zwei bis drei Zehnerpotenzen langsamer als fuer normale DNS-Anfragen, selbst wenn die nach extern gehen.

Gruss Cae

[dufty2]

Aber knapp 8 Sekunden Overhead fuer eine einzelne Query...? Das ist zwei bis drei Zehnerpotenzen langsamer als fuer normale DNS-Anfragen, selbst wenn die nach extern gehen.

Mit der Interpretation der "time"-Zeile beim ping muss man etwas vorsichtig sein,
es gibt nämlich auch so was:

Code: Alles auswählen

$ time ping heiss.de -c 3
PING heiss.de (80.67.17.208) 56(84) bytes of data.
64 bytes from montafon.ispgateway.de (80.67.17.208): icmp_seq=1 ttl=56 time=3728 ms
64 bytes from montafon.ispgateway.de (80.67.17.208): icmp_seq=2 ttl=56 time=2757 ms
64 bytes from montafon.ispgateway.de (80.67.17.208): icmp_seq=3 ttl=56 time=1777 ms

--- heiss.de ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 1777.715/2754.716/3728.436/796.381 ms, pipe 3

real    0m3.785s
user    0m0.004s
sys     0m0.004s

Oder noch schöner:

Code: Alles auswählen

$ time ping zdf.de -c 1
PING zdf.de (91.197.28.69) 56(84) bytes of data.
64 bytes from 91.197.28.69: icmp_seq=1 ttl=117 time=87.1 ms

--- zdf.de ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 87.112/87.112/87.112/0.000 ms

real    0m3.722s
user    0m0.008s
sys     0m0.000s

[BlackEye]

Also die Auflösung ist definitiv "zu" lang. Ein ping auf heise oder google geht um Welten schneller als diese .local Geschichte. Ich hätte es auch mit dem time veranschaulichen können.
Aber damit ihr es auch glaubt

Code: Alles auswählen

$ time ping -c 3 domain.local
PING domain.local (10.0.21.3) 56(84) bytes of data.
64 bytes from 10.0.21.3: icmp_req=1 ttl=125 time=28.3 ms
64 bytes from 10.0.21.3: icmp_req=2 ttl=125 time=30.5 ms
64 bytes from 10.0.21.3: icmp_req=3 ttl=125 time=27.5 ms

--- domain.local ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 10088ms
rtt min/avg/max/mdev = 27.500/28.790/30.526/1.289 ms

real    0m11.122s
user    0m0.000s
sys     0m0.004s

$ time ping -c 3 google.de
PING google.de (173.194.44.56) 56(84) bytes of data.
64 bytes from muc03s08-in-f24.1e100.net (173.194.44.56): icmp_req=1 ttl=55 time=29.5 ms
64 bytes from muc03s08-in-f24.1e100.net (173.194.44.56): icmp_req=2 ttl=55 time=26.3 ms
64 bytes from muc03s08-in-f24.1e100.net (173.194.44.56): icmp_req=3 ttl=55 time=26.2 ms

--- google.de ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 26.268/27.375/29.543/1.544 ms

real    0m2.054s
user    0m0.000s
sys     0m0.000s

Man sieht hier beim Ping richtig lange Pausen nach jedem Reply. Eben weil diese .local Auflösung erst auf irgend einen Timeout läuft ehe der DNS abgefragt wird.
Irgendwie so ähnlich steht es auch hier: http://www.lowlevelmanager.com/2011/09/ ... local.html

We could side-step the problem by removing mdns4_minimal from the hosts search path, but this will lead to potentially long dns timeouts from mistyped .local addresses. (Ok, that's not a very bad side effect, but still let's fix it correctly).

Grüße
Martin

PS: Es ist halt wie es ist Ich bin aber schon froh, dass es nun überhaupt wieder geht

[dufty2]

Man sieht hier beim Ping richtig lange Pausen nach jedem Reply. Eben weil diese .local Auflösung erst auf irgend einen Timeout läuft ehe der DNS abgefragt wird.

Das "time" in der Zeile "x packets transmitted, ..." ist der Abstand vom ersten gesendeten packet bis zum letzten abgesendeten, dies ist im Normalfall 1 Sekunde, so dass bei 3 pings 2 "Zwischensekunden" resp. 2000 ms entstehen.

Das jetzt ping jedesmal nach einem Paketversand den Name nach IP erneut auflöst, kann ich gar nicht glauben, ich sehe auch nur ein
gethostbyname()
in der Source-datei ping.c.
Das wär ansonsten ziemlich uneffizient.

Aus irgendeinen Grund wird bei Deiner local-Geschichte als Intervall 5 Sekunden genommen, so daß
Du am Schluß die 10000 ms siehst.

[habakug]

Hallo!

Im Blog steht eigentlich, dass man "domain-name=.alocal" (also mit dem Punkt) angeben soll. Aber das führte zu einem Fehler und ich konnte den Daemon so nicht neu starten. Also muss ich es ohne den Punkt schreiben.

Der Punkt ist schon sehr wichtig. Du solltest zunächst schauen, wie ".local" aufgelöst wird:

Code: Alles auswählen

$ dig local. SOA
$ dig @10.0.0.5 local. SOA

Wenn der DNS die local-Domäne auflöst, möchte Avahi nicht mehr starten. Du könntest dem Client auch erlauben einen externen DNS (OpenDNS) in der resolv.conf zu haben.
Es könnte auch versucht werden in den Tiefen des Windows-Servers das Häkchen in dem Kontrollkästchen "Keine Rekursion für diese Domäne verwenden." zu setzen. Die "bedingten Weiterleitungen" bieten eine Fülle von Möglichkeiten Fehler einzubauen. Ich würde empfehlen sich auch mit dem Tool "dnscmd" vertraut zu machen und die Sache auch vom Windows-Server aus betrachten.

Gruss, habakug

[BlackEye]

.local wird nicht durch den DNS aufgelöst. Das ist also nicht das Problem.

Ich habe mal in die Logs geschaut:

Code: Alles auswählen

Mar  9 17:36:00 mfe avahi-daemon[5683]: Found user 'avahi' (UID 106) and group 'avahi' (GID 115).
Mar  9 17:36:00 mfe avahi-daemon[5683]: Successfully dropped root privileges.
Mar  9 17:36:00 mfe avahi-daemon[5683]: avahi-daemon 0.6.31 starting up.
Mar  9 17:36:00 mfe avahi-daemon[5683]: Successfully called chroot().
Mar  9 17:36:00 mfe avahi-daemon[5683]: Successfully dropped remaining capabilities.
Mar  9 17:36:00 mfe avahi-daemon[5683]: Loading service file /services/udisks.service.
Mar  9 17:36:00 mfe avahi-daemon[5683]: Failed to create server: Invalid domain name
Mar  9 17:36:00 mfe avahi-daemon[5683]: avahi-daemon 0.6.31 exiting.

Sobald ich den Eintrag

Code: Alles auswählen

domain-name=.alocal

in /etc/avahi/avahi-daemon.conf eintrage hat er keine Lust mehr. Kommentiere ich den Eintrag wieder aus is alles supi..
Ein googeln brachte auch nichts weiter an Informationen und die MAN-Page von avahi sagt ja

Code: Alles auswählen

domain-name= Set the default domain name avahi-daemon tries to register
       its host name and services on  the  LAN  in.  If  omitted  defaults  to
       ".local".

Aber selbst wenn ich hier "domain-name=.local" eintrage versagt er den Dienst.
Irgendwie mag er mich heute nicht

[dufty2]

domain-name=".alocal"

[BlackEye]

Ah danke - damit funktioniert es! Zumindest avahi geht damit wieder zu starten. Das ganze Auflösungsproblem bleibt aber auch so leider weiterhin bestehen. Ich komme um die Anpassung der nsswitch.conf leider nicht umhin.

Seis drum. Es funktioniert - ich betrachte das Thema damit als abgehakt. Will hier ja nicht mehr arbeit produzieren als damit jemals an Zeit gewonnen werden könnte

Besten Dank und Grüße
Martin