Moin,
ich habe hier ein nerviges Problem mit DNS-Resolving. Ich kann einen Host mittels dig/nslookup auflösen, aber dann nicht pingen/anbrowsen:
root@haka:~# nslookup confluence.amasol.local Server: 127.0.0.1 Address: 127.0.0.1#53
Non-authoritative answer: Name: confluence.amasol.local Address: 192.168.42.37
root@haka:~# dig confluence.amasol.local
; <<>> DiG 9.10.3-P4-Debian <<>> confluence.amasol.local ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20118 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;confluence.amasol.local. IN A
;; ANSWER SECTION: confluence.amasol.local. 3478 IN A 192.168.42.37
;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Nov 20 10:12:58 CET 2017 ;; MSG SIZE rcvd: 68
---> Ping/getent geht aber nicht
root@haka:~# ping confluence.amasol.local ping: confluence.amasol.local: Name or service not known root@haka:~# getent hosts confluence.amasol.local root@haka:~#
---> Ping/getent gegen Hostname geht aber.
root@haka:~# ping confluence PING confluence.amasol.local (192.168.42.37) 56(84) bytes of data. ^C64 bytes from 192.168.42.37: icmp_seq=1 ttl=63 time=39.8 ms
--- confluence.amasol.local ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 39.809/39.809/39.809/0.000 ms root@haka:~# getent hosts confluence 192.168.42.37 confluence.amasol.local
<snip>
In der resolv.conf steht:
# Generated by NetworkManager search amasol.local fritz.box
Liegt es daran, daß er .local nicht als TLD erkennt, dann immer die Search-Extension(s) (versuchsweise) anhängt und dann auf die Nase fliegt? Wo kann ich custom-TLDs konfigurieren?
Danke!
Hilmar
On 20.11.2017 10:46, Hilmar Preuße wrote:
Moin,
In der resolv.conf steht:
# Generated by NetworkManager search amasol.local fritz.box
Sorry, das ist irreführend: hier die komplette resolv.conf
hille@haka:~$ less -X /etc/resolv.conf # Generated by NetworkManager search amasol.local fritz.box nameserver 127.0.0.1
Auf 127.0.0.1 lauscht ein dnsmasq. Aber auch vorher, als ich in der resolv.conf meine 3 DNS-Server drin hatte, hatte ich das Problem.
H.
Hilmar Preuße hille42@web.de (Mo 20 Nov 2017 11:15:09 CET):
# Generated by NetworkManager search amasol.local fritz.box nameserver 127.0.0.1
Wenn der `nameserver` Eintrag fehlt, dann wird 127.0.0.1 unterstellt, insofern war Deine vorher gepostete Version auch korrekt :)
Hilmar Preuße hille42@web.de (Mo 20 Nov 2017 10:46:46 CET):
Moin,
ich habe hier ein nerviges Problem mit DNS-Resolving. Ich kann einen Host mittels dig/nslookup auflösen, aber dann nicht pingen/anbrowsen:
root@haka:~# nslookup confluence.amasol.local
Auf nslookup würde ich nicht viel geben, das hat zu viel Magie eingebaut.
root@haka:~# dig confluence.amasol.local
…
confluence.amasol.local. 3478 IN A 192.168.42.37
Ok, das war eine ordentlich DNS-Query incl. der Antwort. (Im konkreten Fall ist nslookup auch nicht falsch, aber man weiß ja nie…)
---> Ping/getent geht aber nicht
root@haka:~# ping confluence.amasol.local ping: confluence.amasol.local: Name or service not known root@haka:~# getent hosts confluence.amasol.local
`getent` macht nicht zwingend DNS. Ebenso wie `ping`, welches auch nur getent (bzw. die Library-Entsprechnungen (gethostbyname(3)…) dafür benutzt)¹
---> Ping/getent gegen Hostname geht aber. root@haka:~# ping confluence PING confluence.amasol.local (192.168.42.37) 56(84) bytes of data. ^C64 bytes from 192.168.42.37: icmp_seq=1 ttl=63 time=39.8 ms
# Generated by NetworkManager search amasol.local fritz.box
Liegt es daran, daß er .local nicht als TLD erkennt, dann immer die
Wer ist ER? Warum sollten TLDs hier eine Rolle spielen?
In Deiner nsswitch.conf steht vermutlich mdns mit drin. Multicast-DNS wird von .local getriggert.
$ getent ahosts confluence.amasol.local -> mdns springt an, kann aber aus irgendwelchen Gründen den Namen nicht auflösen. Jetzt müsste die Auflösung eigentlich durchfallen zum DNS und dann doch funktionieren. Wie sieht die hosts-Zeile in der nsswitch.conf bei Dir aus?
$ getent ahosts confluence -> hier springt das mdns in der nsswitch.conf nicht an, weil kein .local hinten dran hängt! -> dns (aus der nsswitch.conf) fühlt sich verantwortlich, liest noch die resolv.conf ein (denn das ist die Konfiguration für libnss_dns) und kann das mit der angehängten .amasol.local-Endung dann auflösen.
Du möchtest für Deine eigenen Domain eigentlich nie .local verwenden, weil das im Zusammenhang mit AVAHI/Zeroconf/MDNS verwendet wird. Alternativ weißst Du, was Du tust :)
¹) In Wirklichkeit sollten moderne Programme inzwischen nicht mehr gethostbyname() verwenden, sondern getaddressinfo(), das CLI pendant dazu wäre dann `getent ahosts …`
Best regards from Dresden/Germany Viele Grüße aus Dresden Heiko Schlittermann
On 20.11.2017 11:27, Heiko Schlittermann wrote:
Hilmar Preuße hille42@web.de (Mo 20 Nov 2017 10:46:46 CET):
Moin,
---> Ping/getent geht aber nicht
root@haka:~# ping confluence.amasol.local ping: confluence.amasol.local: Name or service not known root@haka:~# getent hosts confluence.amasol.local
`getent` macht nicht zwingend DNS. Ebenso wie `ping`, welches auch nur getent (bzw. die Library-Entsprechnungen (gethostbyname(3)…) dafür benutzt)¹
Schon klar. Wollte nur demonstrieren, daß dies auch nicht geht. Da die /etc/hosts aber keine Einträge (bis auf loopback) enthält würde ich kein anderes Ergebnis als bei dig(1) erwarten.
---> Ping/getent gegen Hostname geht aber. root@haka:~# ping confluence PING confluence.amasol.local (192.168.42.37) 56(84) bytes of data. ^C64 bytes from 192.168.42.37: icmp_seq=1 ttl=63 time=39.8 ms
# Generated by NetworkManager search amasol.local fritz.box
Liegt es daran, daß er .local nicht als TLD erkennt, dann immer die
Wer ist ER? Warum sollten TLDs hier eine Rolle spielen?
DER Computer. Das mit den TLD's war nur eine wilde Theorie.
In Deiner nsswitch.conf steht vermutlich mdns mit drin. Multicast-DNS wird von .local getriggert.
$ getent ahosts confluence.amasol.local -> mdns springt an, kann aber aus irgendwelchen Gründen den Namen nicht auflösen. Jetzt müsste die Auflösung eigentlich durchfallen zum DNS und dann doch funktionieren. Wie sieht die hosts-Zeile in der nsswitch.conf bei Dir aus?
hille@haka:~$ getent ahosts confluence.amasol.local hille@haka:~$ grep -v # /etc/nsswitch.conf |grep -v ^$ passwd: compat group: compat shadow: compat hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns mdns4 networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis
Ich kann micht nicht erinnern, daß je angefaßt zu haben.
Du möchtest für Deine eigenen Domain eigentlich nie .local verwenden, weil das im Zusammenhang mit AVAHI/Zeroconf/MDNS verwendet wird. Alternativ weißt Du, was Du tust :)
Die Entscheidung liegt bei der IT-Administration meines Arbeitgebers. Gibt es einen RfC als Argumentationshilfe?
Danke!
Hilmar
Hilmar Preuße hille42@web.de (Mo 20 Nov 2017 16:37:32 CET):
Schon klar. Wollte nur demonstrieren, daß dies auch nicht geht. Da die /etc/hosts aber keine Einträge (bis auf loopback) enthält würde ich kein anderes Ergebnis als bei dig(1) erwarten.
Eben doch. Dig als DNS-Client interessiert sich überhaupt nicht für nsswitch.conf und *eigentlich* auch nicht für resolv.conf. (Er nimmt dort nur den zu fragenden Nameserver raus.)
In Deiner nsswitch.conf steht vermutlich mdns mit drin. Multicast-DNS
…
hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns mdns4
…
Ich kann micht nicht erinnern, daß je angefaßt zu haben.
Vermutlich hast Du avahi oder so Kram installiert (kommt meistens mit den Desktops). Damit handelt man sich das ein. Kannst ja den mdns-Teil wieder entfernen.
Du möchtest für Deine eigenen Domain eigentlich nie .local verwenden, weil das im Zusammenhang mit AVAHI/Zeroconf/MDNS verwendet wird. Alternativ weißt Du, was Du tust :)
Die Entscheidung liegt bei der IT-Administration meines Arbeitgebers. Gibt es einen RfC als Argumentationshilfe?
Guck mal in diesem Internet, da gibt es viele Artikel über Zeroconf und AVAHI.
On Mon, November 20, 2017 17:24, Heiko Schlittermann wrote:
Du möchtest für Deine eigenen Domain eigentlich nie .local
verwenden,
weil das im Zusammenhang mit AVAHI/Zeroconf/MDNS verwendet wird. Alternativ weiÃt Du, was Du tust :)
Die Entscheidung liegt bei der IT-Administration meines Arbeitgebers. Gibt es einen RfC als Argumentationshilfe?
Guck mal in diesem Internet, da gibt es viele Artikel über Zeroconf und AVAHI.
https://en.wikipedia.org/wiki/.local https://tools.ietf.org/html/rfc6762 (Seite 6)
Konrad
On 20.11.2017 17:24, Heiko Schlittermann wrote:
Hilmar Preuße hille42@web.de (Mo 20 Nov 2017 16:37:32 CET):
Hallo Heiko, hallo Konrad,
In Deiner nsswitch.conf steht vermutlich mdns mit drin. Multicast-DNS
…
hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns mdns4
…
Ich kann micht nicht erinnern, daß je angefaßt zu haben.
Vermutlich hast Du avahi oder so Kram installiert (kommt meistens mit den Desktops). Damit handelt man sich das ein. Kannst ja den mdns-Teil wieder entfernen.
Nun, den mdns-Teil hat mir jemand Anderes eingebrockt:
hille@haka:~$ less -X /var/lib/dpkg/info/libnss-mdns:amd64.postinst <snip> sub insert { # this also splits on tab my @bits=split(" ", shift); # do not break configuration if the "hosts" line already references # mdns if (grep { $_ eq "mdns4_minimal" || $_ eq "mdns4" || $_ eq "mdns" || $_ eq "mdns_minimal" || $_ eq "mdns6" || $_ eq "mdns6_minimal"} @bits) { return join " ", @bits; } # change "dns" or "resolve", whichever comes first, into # "mdns4_minimal [NOTFOUND=return] dns|resolve" foreach my $bit (@bits) { if ($bit eq "dns" || $bit eq "resolve") { $bit = "mdns4_minimal [NOTFOUND=return] $bit"; last; } } return join " ", @bits;
Ich habe jetzt etwas getestet. Das war meine alte Zeile:
# hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns mdns4
Alleine nur die mdns-Einträge entfernen hat nicht geholfen, es mußte auch das "[NOTFOUND=return]" weg, damit er auf den DNS-Server springt. Wenn der Eintrag weg ist, kann ich auch die beiden mdns-Einträge wieder einfügen. Nach Wiedereinfügen von "mdns4_minimal" gibt es einen leichten Delay (weil er noch die nicht-funktionierende Methode probiert), aber prinzipiell geht jetzt alles.
Spätestens beim nächsten dist-upgrade ist aber wieder Ruhe. Sauber wäre also, den TLD .local durch einen nicht-reservierten Namen zu ersetzen.
...oder ich schmeiße das Plugin einfach weg:
root@haka:~# apt-get --purge remove libnss-mdns Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: libnss-mdns* 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. After this operation, 110 kB disk space will be freed. Do you want to continue? [Y/n] n Abort.
Spricht was dagegen?
Guck mal in diesem Internet, da gibt es viele Artikel über Zeroconf und AVAHI.
OK, danke!
Danke auch an Konrad für seine beiden Links!
Hilmar
Hilmar Preuße hille42@web.de (Di 21 Nov 2017 10:10:07 CET): …
# hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns mdns4
Alleine nur die mdns-Einträge entfernen hat nicht geholfen, es mußte auch das "[NOTFOUND=return]" weg, damit er auf den DNS-Server springt.
Das [NOTFOUND=return] gehört zum davorstehenden Eintrag (nsswitch.conf(5) gibt etwas Auskunft darüber.)
root@haka:~# apt-get --purge remove libnss-mdns Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: libnss-mdns* 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. After this operation, 110 kB disk space will be freed. Do you want to continue? [Y/n] n Abort.
Spricht was dagegen?
Nee, wenn Du es nicht brauchst, dann weg. Kann aber sein, daß andere Clients in Deinem Netz ähnlich konfiguriert sind, deshalb ist Plan A, keine .local TLD zu verwenden, außer man möchte genau das, was Du da gerade als störend empfindest.
On 21.11.2017 17:26, Heiko Schlittermann wrote:
Hilmar Preuße hille42@web.de (Di 21 Nov 2017 10:10:07 CET):
Moin,
# hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns mdns4
Alleine nur die mdns-Einträge entfernen hat nicht geholfen, es mußte auch das "[NOTFOUND=return]" weg, damit er auf den DNS-Server springt.
Das [NOTFOUND=return] gehört zum davorstehenden Eintrag (nsswitch.conf(5) gibt etwas Auskunft darüber.)
Ja, korrekt: https://ubuntuforums.org/showthread.php?t=971693 (dritter Post).
[root@haka:~# apt-get --purge remove libnss-mdns]
Nee, wenn Du es nicht brauchst, dann weg. Kann aber sein, daß andere Clients in Deinem Netz ähnlich konfiguriert sind, deshalb ist Plan A, keine .local TLD zu verwenden, außer man möchte genau das, was Du da gerade als störend empfindest.
So, das Paket ist jetzt weg (purge), die nsswitch.conf sieht so aus, wie ich sie erst händisch gebaut hatte und es läuft jetzt. Ich werde mal die .local-Problematik ansprechen; mal sehn, ob sich was tut. Wir sind zwar eine Technologiefirma, aber die meisten Clients laufen auf Windows und damit scheint es keine Probleme zu geben. In meinem Netzwerk (@home) gibt es nur einen Rechner, der die VPN-Verbindung nutzt, damit ist die Lösung ein Paket zu purgen ausreichend.
Thread wird hiermit geschlossen, vielen Dank an alle Beteiligten!
Hilmar
On 21.11.2017 17:26, Heiko Schlittermann wrote:
Moin,
[root@haka:~# apt-get --purge remove libnss-mdns]
Spricht was dagegen?
Nee, wenn Du es nicht brauchst, dann weg. Kann aber sein, daß andere Clients in Deinem Netz ähnlich konfiguriert sind, deshalb ist Plan A, keine .local TLD zu verwenden, außer man möchte genau das, was Du da gerade als störend empfindest.
So, klappt doch nicht. Der Drucker in meinem Netz meldet sich mit .local. Also steht im Cups:
"Unable to locate printer BRN00807710C80F.local"
...und da BRN00807710C80F.local nicht aufgelöst werden kann, brauche ich wohl mdns...alternativ ein Eintrag in /etc/hosts. Klappt.
So, jetzt: EOT.
Hilmar
lug-dd@mailman.schlittermann.de
-
Heiko Schlittermann -
Hilmar Preuße -
Konrad Rosenbaum