ubuntuusers.de

Hallo,

ich habe mir einen DNS Server auf Basis von BIND eingerichtet. (Ubuntu Server 17.10) Es gibt hier z.B. einen Eintrag für einen Server mit Namen "meinserver" in der Domain "zuhause.internal" und der IP 192.168.20.100.

Direkt auf dem eingerichteten Server funktioniert die Namensauflösung mit reinem Hostname, als auch mit FQDN

> nslookup meinserver

Server:		192.168.20.129
Address:	192.168.20.129#53

Name:	meinserver.zuhause.internal
Address: 192.168.20.100

> nslookup meinserver.zuhause.internal

Server:		192.168.20.129
Address:	192.168.20.129#53

Name:	meinserver.zuhause.internal
Address: 192.168.20.100

Auf meinem Desktoprechner (ubuntu 17.10 mit Gnome) funktioniert nur die Abfrage nach dem Hostname. Ich habe schon herausbekommen, dass Ubuntu über den network-manager mit einem eigenen/internen dnsmasq Dienst arbeitet. Dieser scheint auch die Anfragen zu bearbeiten, allerdings ist er nicht in der der Lage die FQDN Abfragen aufzulösen, sondern nur die reinen Hostnamen.

> nslookup meinserver

Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	meinserver
Address: 192.168.20.100

> nslookup meinserver.zuhause.internal

Server:		127.0.0.53
Address:	127.0.0.53#53

** server can't find meinserver.zuhause.internal: NXDOMAIN

Wenn ich meinen "Netwerk-DNS-Server" manuell in die "/etc/resolv.conf" eintrage, dann funktionieren auch beide Abfragen. Ist das der richtige Weg oder kann man den Networkmanager / dnsmasq Dienst dazu bringen auch die FQDN Auflösung durchzuführen bzw. diese weiterzuleiten, wenn er nicht weiter weist.

So sieht die /etc/resolv.conf "normalerweise" aus

nameserver 127.0.0.53
search zuhause.internal

Wenn ich meinen eigenen DNS-Server manuell voranstelle, dann funktionieren auch die DNS Abfragen. Aber ist das richtige Vorgehen?

nameserver 192.168.20.129
nameserver 127.0.0.53
search zuhause.internal

thomaspz schrieb:

... kann man den ... dnsmasq Dienst dazu bringen auch die FQDN Auflösung durchzuführen bzw. diese weiterzuleiten, wenn er nicht weiter weist.

Mit dem dnsmasq ist das möglich, wenn Du den dnsmasq installiert hast, den man auch _richtig konfigurieren_ kann. Z. B.:

:~$ host -t A <hostname>.fritz.box 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases: 

<hostname>.fritz.box has address 192.168.178.21

:~$ sudo netstat -tulpena | grep -i dnsmasq
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      0          13670       1391/dnsmasq    
udp        0      0 127.0.0.1:53            0.0.0.0:*                           0          13669       1391/dnsmasq    
udp        0      0 0.0.0.0:43010           0.0.0.0:*                           0          13674       1391/dnsmasq

:~$ logread | grep -iE 'fritz.box|arpa'
Feb 24 09:16:26 xxxxxx daemon.info dnsmasq[1391]: using local addresses only for domain fritz.box
Feb 24 09:16:26 xxxxxx daemon.info dnsmasq[1391]: using nameserver 192.168.178.1#53 for domain 178.168.192.in-addr.arpa (no DNSSEC)
Feb 24 09:16:26 xxxxxx daemon.info dnsmasq[1391]: using nameserver 192.168.178.1#53 for domain fritz.box (no DNSSEC)

danke für die Antwort.

Laut diesem Wiki Eintrag

https://wiki.ubuntuusers.de/Dnsmasq/

kann man theoretisch einen Domainbereich einen anderen DNS Server zuweisen. Hierfür in der Datei /etc/dnsmasq.conf folgenden Eintrag machen.

server=/zuhause.internal/192.168.20.129

Leider hilft das nicht und die FQDN Abfragen gehen weiterhin ins Leere.

thomaspz schrieb:

Leider hilft das nicht und die FQDN Abfragen gehen weiterhin ins Leere.

Wie sind die Ausgaben von:

ps aux | grep -i [d]nsm
dnsmasq --version
apt-cache policy dnsmasq
ldd $(which dnsmasq)
systemctl status dnsmasq
sudo netstat -tulpena | grep -i dnsm

?

EDIT:

Evtl. ist für deinen dnsmasq, der rebind-Schutz per default aktiv. Denn kannst Du für einen host-domain, in der dnsmasq.conf aufheben mit z. B.:

rebind-domain-ok=meinserver.zuhause.internal

und restarten von dnsmasq.

Evtl. auch mit tcpdump auf dem Client (mit dnsmasq) testen:

sudo tcpdump -vvven host 192.168.20.129 and port 53

danach:

host -t A meinserver.zuhause.internal 127.0.0.1
host -t A meinserver.zuhause.internal 127.0.0.53

Wie ist danach die Ausgabe von tcpdump?

Anscheined hat die Zeile aus meinem Post doch was gebracht. Nach einem Neustart läuft der Ping auch auf dem FQDN.

Ich habe der Vollständigkeit mal die Befehle ausgeführt:

:/$ ps aux | grep -i [d]nsm
:/$ dnsmasq --version
Dnsmasq Version 2.78  Copyright (c) 2000-2017 Simon Kelley
Compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify

Für diese Software wird ABSOLUT KEINE GARANTIE gewährt.
Dnsmasq ist freie Software, und du bist willkommen es weiter zu verteilen
unter den Bedingungen der GNU General Public Lizenz, Version 2 oder 3.
:/$ apt-cache policy dnsmasq
dnsmasq:
  Installiert:           (keine)
  Installationskandidat: 2.78-1
  Versionstabelle:
     2.78-1 500
        500 http://de.archive.ubuntu.com/ubuntu artful/universe amd64 Packages
        500 http://de.archive.ubuntu.com/ubuntu artful/universe i386 Packages
:/$ ldd $(which dnsmasq)
	linux-vdso.so.1 =>  (0x00007fff8015e000)
	libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007fd8e9063000)
	libidn.so.11 => /lib/x86_64-linux-gnu/libidn.so.11 (0x00007fd8e8e2b000)
	libnetfilter_conntrack.so.3 => /usr/lib/x86_64-linux-gnu/libnetfilter_conntrack.so.3 (0x00007fd8e8c0b000)
	libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007fd8e89d3000)
	libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007fd8e879b000)
	libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fd8e851b000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd8e813b000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd8e7f1b000)
	libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007fd8e7c93000)
	libnfnetlink.so.0 => /usr/lib/x86_64-linux-gnu/libnfnetlink.so.0 (0x00007fd8e7a8b000)
	libmnl.so.0 => /lib/x86_64-linux-gnu/libmnl.so.0 (0x00007fd8e7883000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fd8e9513000)
	libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007fd8e7573000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fd8e736b000)
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fd8e7143000)
	liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fd8e6f2b000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fd8e6d03000)
	libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007fd8e6aeb000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd8e68e3000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fd8e666b000)
:/$ systemctl status dnsmasq
Unit dnsmasq.service could not be found.
:/$ sudo netstat -tulpena | grep -i dnsm
:/$ 

Ich vermute das ein "vollständig/richtig" installierter dnsmasq auch als process mit .service Datei installiert wäre. Dies scheint ja nicht der Fall zu sein. Ich habe in unterschiedlichen anderen Foren gelesen, dass der network-manager von ubuntu wohl einen dnsmasq "mitbringt", die eigentliche netwerk konfiguration und Steuerung aber selbst übernimmt. Das würde erklären, warum es keine .service Definition für diesen gibt. Er lässt sich aber trotzdem über bestimmt Konfigurationsdateien beeinflussen (siehe meinen vorherigen Post).