ubuntuusers.de

Hallo,

ich bin dabei meinen Server neue Software zu verpassen. Die alte war 8 Jahre alt ☺ Dabei bin ich auf ein Problem mit den DNS Server Bind9 und systemd-resolved gestoßen, was ich noch nicht genau verstehe.

Wenn ich mittels dig die DNS Auflösung lokal am Server teste erhalte ich folgende unterschiedliche Ergebnisse:

• dig @127.0.0.1 client1.duda.local ⇒ alles OK

user@rechner:~$ dig @127.0.0.1 client1

; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> @127.0.0.1 client1.duda.local
; (1 server found)
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27480
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 8094d86c21d10e2d16a1e3875ca21cd663ccf4b1ba5dae1d (good)
;; QUESTION SECTION:
;client1.duda.local.		IN	A

;; ANSWER SECTION:
client1.duda.local.	172800	IN	A	192.168.0.3

;; AUTHORITY SECTION:
duda.local.		172800	IN	NS	dns.duda.local.

;; ADDITIONAL SECTION:
dns.duda.local.	172800	IN	A	192.168.0.2

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Apr 01 16:14:46 CEST 2019
;; MSG SIZE  rcvd: 126

• dig @127.0.0.1 client1 ⇒ geht nicht

user@rechner:~$ dig @127.0.0.1 client1.duda.local

; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> @127.0.0.1 client1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 57798
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d138499f64bb1c49686a6f1b5ca21ee21e988b3ce71eb9aa (good)
;; QUESTION SECTION:
;client1.				IN	A

;; AUTHORITY SECTION:
.			10251	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2019040100 1800 900 604800 86400

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Apr 01 16:23:30 CEST 2019
;; MSG SIZE  rcvd: 138

• dig client1.duda.local ⇒ geht nicht

user@rechner:~$ dig client1.duda.local

; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> client1.duda.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43373
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;client1.duda.local.		IN	A

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Apr 01 16:25:26 CEST 2019
;; MSG SIZE  rcvd: 44

Ich habe die Konfiguration von DNSSEC noch nicht angefasst. Die Konfigurationen der Zone ist vom alten System. Da konnte ich von überall aus mit ping (mit Rechner Name oder vollem DNS Namen) drauf zugreifen. Nutze ich den DNS Server von einem anderen Rechner funktioniert der ping mit den vollen DNS Namen, lokal leider nicht. Kann mir jemand einen Tip geben, wo das Problem steckten könnte. Für mich sieht das so aus, als ob systemd-resolved für die DNS Abfrage genutzt wird. Ich hatte auch nach Web dieses deaktiviert. Dann ging mein Netzwerk überhaupt nicht mehr. Auf dem Server selber will ich doch nur den Bind9 nutzen. Einen zweiten DNS Cache oder so, brauche ich da nicht. In der /etc/resolv.conf konnte ich früher das lokale Verhalten beeinflussen:

domain duda.local
search duda.local
nameserver 127.0.0.1

Jetzt wird diese Datei durch Skripte erzeugt. Da steht jetzt nur noch folgendes drin:

nameserver 127.0.0.1

Und zu den Konfigurations Skripte lese ich immer nur "ich weiß nicht warum aber anders geht es nicht" oder so.

Danke für Eure Hilfe, Bernd

BBernd schrieb:

In der /etc/resolv.conf konnte ich früher das lokale Verhalten beeinflussen:

domain duda.local
search duda.local
nameserver 127.0.0.1

Jetzt wird diese Datei durch Skripte erzeugt. Da steht jetzt nur noch folgendes drin:

nameserver 127.0.0.1

Es gibt die Option "Domains= " für systemd-resolved, via resolved.conf für den Eintrag in die /etc/resolv.conf.

Danke lubux, habe in man nachgeschaut was da alles drin stehen darf. Es gibt da viele Orte wo diese Datei stehen kann. Ich habe diese hier gefunden

• /etc/systemd/resolved.conf

nachdem ich folgendes eingetragen habe:

DNS=127.0.0.1 192.168.0.2
Domain=dudu.local

erhalte ich mit nslookup ein Ergebnis

> nslookup client1.dudu.local
Server:   127.0.0.53
Address:  127.0.0.53:53

Non-authoritative answer:
Name:  client1.dudu.local
Address: 192.168.0.3

die Kurzform funktioniert hiert immer noch nicht:

> nslookup client1.dudu.local
Server:   127.0.0.53
Address:  127.0.0.53:53

** server can't find client1: SERVERFAIL

Mit dig erhalte ich das selbe Ergebnis. Hier funktioniert es jetzt ohne Angabe der DNS Addresse.

> dig client1.dudu.local

der Status von systemd-resolve hat sich auch geändert:

Global
     DNS Servers: 127.0.0.1
                  192.168.0.2
     DNS Domain: dudu.local

Was mich wundert ist, das bei allen Anfragen die Antwort von 127.0.0.53 kommen, obwohl ich 127.0.0.1 konfiguriert habe. Die Kurzform (also ohne '.' im Namen) funktioniert mit dig und nslookup immer noch nicht. Dafür war früher die Konfiguration "Search dudu.local" verantwortlich. Mit full Domain Namen kann ich mit dig und nslookup lokal den Namen auflösen. Leider mit "ping client1.dudu.local" immer noch nicht.

Die Überprüfung mittels:

> sudo named-checkconf
> sudo named-checkzone dudu.local db.dudu.local
> sudo named-checkzone 192.168.0.in-addr.arpa db.0.168.192

ergeben keine Fehler.

Die /etc/resolv.conf hat sich leider nicht geändert. Wie kann ich den Server selber mitteilen, das er Lokal den eigenen DNS Server verwenden soll. Das systemd-resolve ist ja ein DNS Cache, welchen ich auf einem Rechner wo ein Bind9 Server läuft nicht unbedingt brauche. Wen fragt der systemd-resolve für DNS nun an? Es ist nicht mein Bind9 Server, sonst würde ja ping genauso funktionieren wie dig oder nslookup. Und wieso funktionieren die Kurzformen nicht? Gibt es da einen neuen Konfigurationswert wo man das erst aktivieren muss?

Soweit ich das verstanden habe kommt die komplette Netzwerkkonfiguration aus netplan.io. Da ist bei mir in the /etc/netplan nur eine Datei mit folgendem Inhalt vorhanden:

network:
  version: 2
  renderer: NetworkManager

Die Netzwerkeinstellung der Netzwerkkarte habe ich über die GUI zur Netzwerkeinstellungen gemacht (Manuell, IP: 192.168.0.2, NM: 255.255.255.0, Gateway: 192.168.01). Die Einstellungen vom DNS Server werden da ignoriert.

Gibt es noch eine Idee die ich überprüfen, anschauen kann?

Danke im Vorraus, Bernd

BBernd schrieb:

Die Netzwerkeinstellung der Netzwerkkarte habe ich über die GUI zur Netzwerkeinstellungen gemacht (Manuell, IP: 192.168.0.2, NM: 255.255.255.0, Gateway: 192.168.01). Die Einstellungen vom DNS Server werden da ignoriert.

Warum benutzt du den NM und eine GUI auf deinem Server?

Wie sind z. Zt. die Ausgaben von:

cat /etc/resolvconf.conf
cat /etc/resolv.conf
cat /etc/systemd/resolved.conf
sudo netstat -tulpena | grep -i 53
cat /etc/nsswitch.conf

?

Wenn du Networkmanager benutzt, dann sind die Einstellungen dazu hier

1

/etc/NetworkManager/system-connections/

dns-search=

Aber wie lubux schon gesagt hat, ich würde auf einen Server kein NM laufen.

@dajohb

Ja ich wollte zuerst die Server version installieren und darauf GNOME. Leider gibt es da zuviele unlösbare Probleme nach der GNOME Installation. Und ja, normalerweise wird der Rechner nur mit Konsole starten. Leider brauche ich für bestimmte Tätigkeiten einen Webbrowser.

Hier die Ausgabe der einzelnen Dateien:

cat /etc/resolvconf.conf = diese Datei exisitert bei mir nicht

cat /etc/resolv.conf

# Generated by NetworkManager
nameserver 127.0.0.53

cat /etc/systemd/resolved.conf

[Resolve]
DNS=127.0.0.1 192.168.0.2
#FallbackDNS=
Domains=dudu.local
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes

sudo netstat -tulpena | grep -i 53

tcp        0      0 192.168.0.2:53          0.0.0.0:*               LISTEN      122        22342      980/named           
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      122        22024      980/named           
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      101        17819      725/systemd-resolve 
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN      122        22027      980/named           
udp        0      0 192.168.0.2:53          0.0.0.0:*                           122        22341      980/named           
udp        0      0 127.0.0.1:53            0.0.0.0:*                           122        22022      980/named           
udp        0      0 127.0.0.53:53           0.0.0.0:*                           101        17818      725/systemd-resolve 
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           116        20370      840/avahi-daemon: r 
udp6       0      0 :::5353                 :::*                                116        20371      840/avahi-daemon: r

cat /etc/nsswitch.conf

passwd:         compat systemd
group:          compat systemd
shadow:         compat
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname
networks:       files

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

netgroup:       nis

Da ist also der systemd-resolve immer noch auf 127.0.0.53 und die /etc/resolv.conf verweist auf 127.0.0.53. Die Reihenfolge von netstat wird doch auch genutzt?

Sollte ich da den bind9 auch auf 127.0.0.53 konfigurieren? Das wäre aber auch nr ein Heftpflaster auf das Problem.

Grüße, Bernd

BBernd schrieb:

cat /etc/resolv.conf

# Generated by NetworkManager
nameserver 127.0.0.53

cat /etc/systemd/resolved.conf

[Resolve]
DNS=127.0.0.1 192.168.0.2
#FallbackDNS=
Domains=dudu.local
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes

sudo netstat -tulpena | grep -i 53

tcp        0      0 192.168.0.2:53          0.0.0.0:*               LISTEN      122        22342      980/named           
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      122        22024      980/named           
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      101        17819      725/systemd-resolve 
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN      122        22027      980/named           
udp        0      0 192.168.0.2:53          0.0.0.0:*                           122        22341      980/named           
udp        0      0 127.0.0.1:53            0.0.0.0:*                           122        22022      980/named           
udp        0      0 127.0.0.53:53           0.0.0.0:*                           101        17818      725/systemd-resolve 
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           116        20370      840/avahi-daemon: r 
udp6       0      0 :::5353                 :::*                                116        20371      840/avahi-daemon: r

cat /etc/nsswitch.conf

passwd:         compat systemd
group:          compat systemd
shadow:         compat
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname
networks:       files

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

netgroup:       nis

Da ist also der systemd-resolve immer noch auf 127.0.0.53 und die /etc/resolv.conf verweist auf 127.0.0.53. Die Reihenfolge von netstat wird doch auch genutzt?

Sollte ich da den bind9 auch auf 127.0.0.53 konfigurieren? Das wäre aber auch nr ein Heftpflaster auf das Problem.

Nein, noch nichts ändern an bind9. Ändere die Zeile:

hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname

in der nsswitch.conf-Datei, in:

hosts:          files dns mdns4_minimal [NOTFOUND=return] myhostname

Wenn Du avahi nicht brauchst, dann den avahi-daemon deinstallieren, schon deshalb weil Du "local" als domain benutzen willst.

Via 127.0.0.53 sollte ja z. Zt. bind9 (named) mit systemd-resolved verwendet werden. Evtl. mal testen mit tcpdump:

sudo tcpdump -c 100 -vvveni lo host 127.0.0.1 and port 53

danach lokal:

host -t A loc.gov

und im (W)LAN:

sudo tcpdump -c 100 -vvveni <Interface> host 192.168.0.2 and port 53

(Interface anpassen und ohne spitze Klammern).

host -t A bund.de 192.168.0.2

Wichtig für den Test mit tcpdump, ist eine Auflösung für etwas das noch nicht im dns-cache ist.

@lubux Sorry, vorherige Antwort war für auf Deine Frage 😉

@dajohb

Danke, habe da meine Einstellungen gemacht, leider ändert sich das Verhalten nicht.

Ich hatte auch schon Versucht den NM zu deaktivieren.Leider waren da die Probleme noch größer und die Konfiguration ist irgendwie ... (naja ich schweige lieber).

Ich finde das es ein Grundsätzliches Problem ist. Wenn ich einen DNS Server lokal laufen habe brauche ich systemd-resolve überhaupt nicht. Zumindest kenne ich keinen Grund warum der da noch aktive ist. Auch das deaktivieren der Generierung der /etc/resolv.conf war negative. diese wurde weiterhin überschrieben.

Die Konfiguration von Linux ist in letzten Jahren so schlimm geworden. Es werden Konfigurationsdateien durch Scripte mit Konfigurationsdateien erzeugt wo kaum noch jemand Durchblick hat. Und das nur um klickibunti zu realisieren. Das war früher ein Grund auf Linux umzusteigen, da waren die Konfigurationen nach einem Standard an einer Stelle und man konnte diese mit vi ändern. Und das hat auf allen Linux/Unix Distri funktioniert. Das ist leider Vergangenheit.

Mit Bind9 kommen ja noch mehr Probleme die ich lösen will. Es wird neuerdings die syslog vollgemüllt unter dem Motte 'Du hast die GeoIP nicht gekauft' usw.. Auch wenn dieser Kauf nicht für die Funktionalität nötig ist. Sowas gehört nicht in den syslog, da gehen die wichtigen Punkte unter und man sucht sich die Finger wund.

Also deswegen will ich erstmals das die Grundfunktion sauber laufen und dann kommt der nächste Schritt.

BBernd schrieb:

... Antwort war für auf Deine Frage 😉

Siehe oben meinen Beitrag vom:

3. April 2019 10:55 Uhr (zuletzt bearbeitet: 3. April 2019 10:57 Uhr)

EDIT:

Wie sind die Ausgaben von:

sudo find /etc -iname '*resolvconf*'
ls -la /etc/resolv.conf

?

EDIT 2:

BTW: Wenn Du mal (evtl. nur temporär) ohne systemd-resolved testen/probieren willst, dann versuch mal mit:

sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved
sudo systemctl mask systemd-resolved
sudo rm /etc/resolv.conf

jetzt kannst Du mit z. B. nano (oder gleichwertig) die /etc/resolv.conf-Datei erstellen und editieren und wenn fertig dann mit chattr, vor Änderungen/Überschreiben "schützen":

sudo chattr +i /etc/resolv.conf

rebooten und testen.

Jetzt bin ich verwirrt. Ich habe das mal Deine Punkte ausgeführt. Das deaktivieren werde ich in etwa einer Stunde testen können.

nsswitch.conf geändert!

sudo tcpdump -c 100 -vvveni lo host 127.0.0.1 and port 53 (auf anderer Konsole ping digades.de)

tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
12:18:08.369419 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 64, id 14398, offset 0, flags [DF], proto UDP (17), length 56)
    127.0.0.1.40549 > 127.0.0.53.53: [bad udp cksum 0xfe6b -> 0x3a04!] 35014+ A? digades.de. (28)
12:18:08.369976 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 64, id 14399, offset 0, flags [DF], proto UDP (17), length 56)
    127.0.0.1.40549 > 127.0.0.53.53: [bad udp cksum 0xfe6b -> 0x55c1!] 27886+ AAAA? digades.de. (28)
12:18:09.270118 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 81: (tos 0x0, ttl 64, id 30176, offset 0, flags [DF], proto UDP (17), length 67)
    127.0.0.1.56371 > 127.0.0.1.53: [bad udp cksum 0xfe42 -> 0xa3fa!] 47132+ [1au] A? digades.de. ar: . OPT UDPsize=512 (39)
12:18:10.613621 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 97: (tos 0x0, ttl 64, id 30187, offset 0, flags [none], proto UDP (17), length 83)
    127.0.0.1.53 > 127.0.0.1.56371: [bad udp cksum 0xfe52 -> 0x5fe6!] 47132 q: A? digades.de. 1/0/1 digades.de. [1h] A 89.110.155.211 ar: . OPT UDPsize=4096 (55)
12:18:10.613743 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 64, id 54220, offset 0, flags [DF], proto UDP (17), length 72)
    127.0.0.53.53 > 127.0.0.1.40549: [bad udp cksum 0xfe7b -> 0xf5fd!] 35014 q: A? digades.de. 1/0/0 digades.de. [1h] A 89.110.155.211 (44)
12:18:10.613870 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 64, id 54221, offset 0, flags [DF], proto UDP (17), length 56)
    127.0.0.53.53 > 127.0.0.1.40549: [bad udp cksum 0xfe6b -> 0xd540!] 27886 q: AAAA? digades.de. 0/0/0 (28)
12:18:10.642824 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 87: (tos 0x0, ttl 64, id 14849, offset 0, flags [DF], proto UDP (17), length 73)
    127.0.0.1.37438 > 127.0.0.53.53: [bad udp cksum 0xfe7c -> 0x10f6!] 13421+ PTR? 211.155.110.89.in-addr.arpa. (45)
12:18:12.270058 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 30211, offset 0, flags [DF], proto UDP (17), length 84)
    127.0.0.1.34564 > 127.0.0.1.53: [bad udp cksum 0xfe53 -> 0xa870!] 42528+ [1au] PTR? 211.155.110.89.in-addr.arpa. ar: . OPT UDPsize=512 (56)
12:18:15.647914 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 87: (tos 0x0, ttl 64, id 15946, offset 0, flags [DF], proto UDP (17), length 73)
    127.0.0.1.37438 > 127.0.0.53.53: [bad udp cksum 0xfe7c -> 0x10f6!] 13421+ PTR? 211.155.110.89.in-addr.arpa. (45)
12:18:18.520053 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 31514, offset 0, flags [DF], proto UDP (17), length 84)
    127.0.0.1.40972 > 127.0.0.1.53: [bad udp cksum 0xfe53 -> 0x8f68!] 42528+ [1au] PTR? 211.155.110.89.in-addr.arpa. ar: . OPT UDPsize=512 (56)
12:18:20.644090 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 32025, offset 0, flags [none], proto UDP (17), length 84)
    127.0.0.1.53 > 127.0.0.1.34564: [bad udp cksum 0xfe53 -> 0x19ee!] 42528 ServFail q: PTR? 211.155.110.89.in-addr.arpa. 0/0/1 ar: . OPT UDPsize=4096 (56)
12:18:20.644163 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 32026, offset 0, flags [none], proto UDP (17), length 84)
    127.0.0.1.53 > 127.0.0.1.40972: [bad udp cksum 0xfe53 -> 0x00e6!] 42528 ServFail q: PTR? 211.155.110.89.in-addr.arpa. 0/0/1 ar: . OPT UDPsize=4096 (56)
12:18:20.644586 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 87: (tos 0x0, ttl 64, id 32027, offset 0, flags [DF], proto UDP (17), length 73)
    127.0.0.1.40972 > 127.0.0.1.53: [bad udp cksum 0xfe48 -> 0x91a8!] 42528+ PTR? 211.155.110.89.in-addr.arpa. (45)
12:18:20.644815 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 87: (tos 0x0, ttl 64, id 32028, offset 0, flags [none], proto UDP (17), length 73)
    127.0.0.1.53 > 127.0.0.1.40972: [bad udp cksum 0xfe48 -> 0x1126!] 42528 ServFail q: PTR? 211.155.110.89.in-addr.arpa. 0/0/0 (45)
12:18:20.645320 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 87: (tos 0x0, ttl 64, id 55298, offset 0, flags [DF], proto UDP (17), length 73)
    127.0.0.53.53 > 127.0.0.1.37438: [bad udp cksum 0xfe7c -> 0x9073!] 13421 ServFail q: PTR? 211.155.110.89.in-addr.arpa. 0/0/0 (45)
12:18:20.645607 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 87: (tos 0x0, ttl 64, id 55299, offset 0, flags [DF], proto UDP (17), length 73)
    127.0.0.53.53 > 127.0.0.1.37438: [bad udp cksum 0xfe7c -> 0x9073!] 13421 ServFail q: PTR? 211.155.110.89.in-addr.arpa. 0/0/0 (45)

host -t A loc.gov

host -t A loc.gov
loc.gov has address 104.16.246.35
loc.gov has address 104.16.247.35
loc.gov has address 104.16.248.35
loc.gov has address 104.16.244.35
loc.gov has address 104.16.245.35

im LAN: sudo tcpdump -c 100 -vvveni eno1 host 192.168.0.2 and port 53 (auf anderer Konsole ping tagesschau.de)

tcpdump: listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
tcpdump: listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
12:23:07.285021 f0:1f:af:45:ee:20 > 00:19:db:b9:f0:eb, ethertype IPv4 (0x0800), length 84: (tos 0x0, ttl 64, id 7553, offset 0, flags [DF], proto UDP (17), length 70)
    192.168.0.101.38599 > 192.168.0.2.53: [bad udp cksum 0x81fb -> 0xd958!] 33238+ [1au] A? tagesschau.de. ar: . OPT UDPsize=512 (42)
12:23:07.285125 f0:1f:af:45:ee:20 > 00:19:db:b9:f0:eb, ethertype IPv4 (0x0800), length 84: (tos 0x0, ttl 64, id 7554, offset 0, flags [DF], proto UDP (17), length 70)
    192.168.0.101.55280 > 192.168.0.2.53: [bad udp cksum 0x81fb -> 0x95d5!] 26928+ [1au] AAAA? tagesschau.de. ar: . OPT UDPsize=512 (42)
12:23:07.530936 00:19:db:b9:f0:eb > f0:1f:af:45:ee:20, ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 64, id 55204, offset 0, flags [none], proto UDP (17), length 86)
    192.168.0.2.53 > 192.168.0.101.38599: [udp sum ok] 33238 q: A? tagesschau.de. 1/0/1 tagesschau.de. [1d] A 88.215.213.26 ar: . OPT UDPsize=4096 (58)
12:23:07.530963 00:19:db:b9:f0:eb > f0:1f:af:45:ee:20, ethertype IPv4 (0x0800), length 142: (tos 0x0, ttl 64, id 55205, offset 0, flags [none], proto UDP (17), length 128)
    192.168.0.2.53 > 192.168.0.101.55280: [udp sum ok] 26928 q: AAAA? tagesschau.de. 0/1/1 ns: tagesschau.de. [3h] SOA ns1.dunkel.de. hostmaster.dunkel.de. 2018100201 10000 1250 2419200 86400 ar: . OPT UDPsize=4096 (100)
12:23:07.558555 f0:1f:af:45:ee:20 > 00:19:db:b9:f0:eb, ethertype IPv4 (0x0800), length 97: (tos 0x0, ttl 64, id 7609, offset 0, flags [DF], proto UDP (17), length 83)
    192.168.0.101.58042 > 192.168.0.2.53: [bad udp cksum 0x8208 -> 0x523f!] 52835+ [1au] PTR? 26.213.215.88.in-addr.arpa. ar: . OPT UDPsize=512 (55)
12:23:11.468080 00:19:db:b9:f0:eb > f0:1f:af:45:ee:20, ethertype IPv4 (0x0800), length 157: (tos 0x0, ttl 64, id 55472, offset 0, flags [none], proto UDP (17), length 143)
    192.168.0.2.53 > 192.168.0.101.58042: [udp sum ok] 52835 NXDomain q: PTR? 26.213.215.88.in-addr.arpa. 0/1/1 ns: 213.215.88.in-addr.arpa. [3h] SOA ns1.dunkel.de. hostmaster.dunkel.de. 2017060101 10000 7200 2419200 86400 ar: . OPT UDPsize=4096 (115)

im LAN: host -t A bund.de 192.168.0.2

Using domain server:
Name: 192.168.0.2:53
Address: 192.168.0.2:53
Aliases:

bund.de has address 77.87.229.48

BBernd schrieb:

Jetzt bin ich verwirrt.

Warum bist Du verwirrt? Hast Du den avahi-daemon auch schon deinstalliert oder brauchst Du avahi auf deinem Server?

Hi lubux,

ich sehe ja das der Bind9 läuft und mir auch die Antworten mit den vollen DNS Namen gibt. Die Kurzform funktioniert nicht. Ich kann diesen aber nur nutzen, wenn ich ihn direkt anspreche.

Jetzt habe ich nachgelesen was avahi-deamon so macht. Da ist ja noch einer da der die DNS Auslösung macht. Jetzt habe ich ihn deinstalliert und siehe da lokal funktioniert

> nslookup client1.dudu.local
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	client1.dudu.local
Address: 192.168.0.3

> nslookup client1
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	client1.dudu.local
Address: 192.168.0.3

> ping client1.dudu.local
PING client1.dudu.local (192.168.0.3) 56(84) bytes of data.

> ping client1
PING client1.dudu.local (192.168.0.3) 56(84) bytes of data.

Gefühlt ist die Namensauflösung langsamer geworden. Jetzt wird auch die Kurzform sauber aufgelöst, so wie ich es gewohnt bin.

Im LAN (auch Ubuntu 18.04) habe ich meinen DNS Server über NM konfiguriert und dieser wird da nicht verwendet. Meine Vermutung ist, dass zu viele die Namensauflösung machen wollen. Und es ist wie mit der Suppe und den Köchen, zu viel Salz drin.

Zu Deiner Frage resolveconf (der systemd-resolve läuft noch):

> sudo find /etc -iname '*resolvconf*'
/etc/resolvconf
> ls -la /etc/resolv.conf
-rw-r--r-- 1 root root 68 Apr  4 08:02 /etc/resolv.conf

Grüße, Bernd

Hi lubux,

so jetzt habe ich den systemd-resolved, so wie Du es beschrieben hast, deaktiviert. Und siehe da die Namensauflösung funktioniert überhaupt nicht mehr. Der symb. Link von /etc/resolv.conf ist nicht mehr da, dennoch wird diese Datei beim Starten überschrieben.

Ist bei der Server Installation der systemd-resolved, avahi usw. nicht mit installiert? Also gibt es da diese Probleme von Anfang an nicht? Bekomme ich bei der Server Version dann die gleichen Probleme, wenn ich GNOME nachinstalliere?

Und wie sieht das bei den Ubuntu 18.04 als Clients im Netzwerk aus? Die DNS Einstellungen über NM werden ja sehr gut ignoriert.

Grüße, Bernd

BBernd schrieb:

so jetzt habe ich den systemd-resolved, so wie Du es beschrieben hast, deaktiviert. Und siehe da die Namensauflösung funktioniert überhaupt nicht mehr. Der symb. Link von /etc/resolv.conf ist nicht mehr da, dennoch wird diese Datei beim Starten überschrieben.

Dann hast Du nicht das gemacht was ich geschrieben habe. In deinem Beitrag von heute 08:20 Uhr hast Du doch schon gezeigt, dass die resolv.conf (warum auch immer) kein symlink ist:

> sudo find /etc -iname '*resolvconf*'
/etc/resolvconf
> ls -la /etc/resolv.conf
-rw-r--r-- 1 root root 68 Apr  4 08:02 /etc/resolv.conf

Wie war der Inhalt der resolv.conf als die Namensauflösung nicht funktioniert hat? Hast Du das überschreiben der resolv.conf verhindert, mit chattr?

EDIT:

BTW: Wenn Du die domain "local" in deinem (W)LAN benutzen willst, dann solltest Du auch auf allen deinen Clients (Linux, Windows, Android, ...) avahi deinstallieren (wenn überhaupt möglich auf Win und Android). Wenn das nicht möglich ist, dann diese "local" domain besser nicht benutzen oder ändern in "lokal".

Scharfes Auge gehabt, ja ich hatte vergessen das Schreiben zu verhindern. Jetzt geht ohne systemd-resolved die Namensauflösung mit vollen DNS Namen. Nur der Rechnername geht nicht. Vorher hat der NM diese Konfiguration überschrieben.

Ich hatte mich bewusst für local im Domain Namen entschieden, da dieses nicht nach außen gereicht wird. Ich habe auch eine de Domain, aber dort mein Lokales Netzwerk mit reinzubringen fand ich nicht gut? Verhindert auch der systemd-resolved den local?

Ich habe jetzt als DNS Namen bei mir:

• www.name.de

• client1.name.local

Ich wollte nicht client1.name.local in client1.name.de ändern.

Muss ich jetzt bei jeden Ubuntu Client die Änderungen machen? Oder wäre es einfacher .local in irgendwas anderes zu ändern (zBsp.: .net)?