ubuntuusers.de

Ich bin wieder einen Schritt weiter und habe meine MS-DHCP-Server durch dnsmasq abgelöst. 😊
Natürlich nutze ich dnsmasq auch als DNS-Server, und die DNS-Server im AD laufen dort nur noch auf Sparflamme.

Bei der Konfiguration der DNS-Gesamtkonfiguration bin ich jedoch nicht ganz sicher (NB: Nein, ich möchte aktuell nicht auf bind hochrüsten.)
ich schreibe ml, was ich wie konfiguriert habe bzw. damit erreichen will, und freue mich auf Eure Kommentare... 😇

• Ich habe die zwei durch einen VPN-Tunnel verbundenen Subnetze 192.168.0.0/24 und 192.168.2.0/24

• Im 0er-Netz (Hauptstelle) möchte ich gern zwei DNS-Server laufen haben, in der Filiale im 2er-Netz reicht mir einer

• (NB: AD-integrierte DNS-Serve "sehen" sich ja alle und replizieren sich gegenseitig... so gut das eben bei MS-Sachen funktioniert... anderes Thema.)

• Zunächst die einfache Version, in jedem Subnetz einen DNS-Server:

• Ich richte auf jedem der beiden seine /etc/hosts so ein, dass sie alle statischen Adressen dieses Subnetzes umfasst

• In der dnsmasq.conf trage ich denn den DNS-Server des jeweils anderen Subnetzes mit Domainname als Tag ein, im 0er-Netz z.B. server=/mylan.mydom.de/192.168.2.1.

• Wenn der DNS-Server im 0er-Netz nun einen Hostnamen nicht auflösen kann, der zur Domain mylan.mydom.de gehört, fragt er weiter (DNS-Forwarding).

• Erste Frage: Das scheint zu funktionieren, ist allerdings nicht wirklich schnell. Was passiert intern? Spielen die beiden Pingpong, wenn ein Host nirgendwo bekannt ist? Oder merkt der Server im 2er-Netz, dass er vom Server aus dem 0er-Netz gefragt wird und forward-et nicht an ihn wieder zurück? So scheint es.

• Oder ist meine Konfiguration "falsch", und es geht eleganter, besser oder überhaupt erst einmal "richtig"?

• * Nun die Version mit zwei DNS-Servern im 0er-Netz:

• Es scheint so, dass ich sicherstellen muss, keinen "Ring" zu erzeugen. Wenn Jeder der drei Server an beide anderen forward-et, dann sieht es so aus, als ginge es munter reihum, Server A fragt Server B, der fragt Server C und der wiederum Server A... ohne die Chance, das "Pingpong" zu erkennen und zu beenden.

• Mein Lösungsansatz: 192.168.0.1 und 192.168.0.2 forwarden an 192.168.2.1 (aber nicht gegenseitig), und 192.168.2.1 forward-et an 192.168.0.1 und 192.168.0.2. So kann es nur zwischen je zwei Servern hin und her gehen, aber ein Ringelpetz ist nicht möglich.

• Zweite Frage: Macht das Sinn? Oder ist meine Konfiguration "falsch", und es geht eleganter, besser oder überhaupt erst einmal "richtig"?

... und dann noch ein paar grundsätzliche Fragen:

• Was bedeutet die "Search Domain" in der Netplan-Konfiguration? Ich hab verstanden, dass hinter domain-lose Namen diese Domain gehängt wird? Stimmt das?

• Was bedeutet es, wenn ich per DHCP zwei DNS-Server herausgebe? Wird einer der beiden gefragt? Oder beide? Der zweite, wenn der erste nichts findet? Oder der zweite nur, wenn der erste gar nicht antwortet?

Was passiert intern? Spielen die beiden Pingpong, wenn ein Host nirgendwo bekannt ist?

Vermutlich das. Mit Wireshark kannst du das prüfen.

Was bedeutet die "Search Domain" in der Netplan-Konfiguration? Ich hab verstanden, dass hinter domain-lose Namen diese Domain gehängt wird? Stimmt das?

Genau.

Was bedeutet es, wenn ich per DHCP zwei DNS-Server herausgebe?

Der Client kann sich einen suchen. Manche machen sogar Load-Balancing und fragen abwechselnd. Ist einer nicht erreichbar, wird der andere benutzt, was aber etwas dauern kann, je nach Client.

Was passiert intern? Spielen die beiden Pingpong, wenn ein Host nirgendwo bekannt ist?

Vermutlich das. Mit Wireshark kannst du das prüfen.

War auch meine Befürchtung, aber dann dürfte ein ping doof.mylan.mydom.de doch nicht "zum Ende kommen". Oder?

DJKUhpisse schrieb:

Was bedeutet es, wenn ich per DHCP zwei DNS-Server herausgebe?

Der Client kann sich einen suchen. Manche machen sogar Load-Balancing und fragen abwechselnd. Ist einer nicht erreichbar, wird der andere benutzt, was aber etwas dauern kann, je nach Client.

Ok, danke, dann überlege ich, was hier "Best Practice" wäre? Da beide dnsmasq laufen und beide die statischen Adressen in ihrer /etc/hosts haben, könnte es durchaus Sinn machen, beide anzugeben... für den Fall, dass nach der Adressvergabe mal der eine der beiden ausfällt. Liest sich das sinnvoll?

Ja, Redundanz bei DNS ist sinnvoll. Die müssen dann aber auch grundsätzlich erreichbar sein.

DJKUhpisse schrieb:

Ja, Redundanz bei DNS ist sinnvoll. Die müssen dann aber auch grundsätzlich erreichbar sein.

Das war ja auch meine Frage (zumindest habe ich es mir so gedacht): Wenn einer der beiden ausfällt, schaltet der Client dann "automatisch" auf den anderen um?
In meinem kleinen Netz brauche ich keine Lastverteilung, aber Ausfallsicherheit wäre schon ganz gut... wenn ich z.B. den einen Server neustarte, dann sollte nicht so lange "das Netz stehen".

Kommt auf den Client an, gerade wann der Wechsel stattfindet. Beide müssen aber grundsätzlich erreichbar sein, sonst hast du ständige Timeouts.

Ja, das ist ja die Idee, normal sollen beide laufen - und das tun sie auch auf verschiedenen Hosts. Aber es geht mir eben genau darum, dass nicht alles steht, wenn einer der beiden Server oder "sein" Host neu gestartet werden muss oder gar crasht... Aber dann passt das ja, dann mache ich das so. Danke.

Dann musst du einen DNS-Client nutzen, der schnell umschaltet, z.B. systemd-resolve.

Die /etc/resolv.conf ist dafür im Standardfall ungeeignet, weil da immer der erste angefragt wird. Das Timeout ist glaub 5s bis der nächste genommen wird.

Diese Verzögerung hat man dann vor jeder Abfrage, bis der 1. NS wieder läuft.

Insgesamt scheint mir die Namensauflösung aber recht langsam zu gehen (und da es eher nicht an dnsmasq liegt, muss es meine Konfiguration sein).

Wenn ich ping einHost eingebe, dauert es jedes Mal ziemlich genau 15 (!) Sekunden, und zwar unabhängig davon, ob der Host gefunden wurde oder nicht.
Da ich nicht weiß, wie ich auf meinem Mint-Client die empfangenen "DHCP-Optionen" anzeigen kann, habe ich mal einen Win10-Client gestartet, und das ist ja seltsam:

Auf meine "primären" dnsmasq mit der IP 192.168.0.1 stehen die Optionen

1
2

dhcp-option=option:dns-server,192.168.0.1
dhcp-option=option:dns-server,192.168.0.2

und umgekehrt auf dem "sekundären".

Es sollte also immer derjenige als erster DNS-Server eingestellt sein, von dem das Lease auch kommt.

Auf dem Win10-Client liefert ein ipconfig /all jedoch (gekürzt):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

Ethernet-Adapter Ethernet:

   Verbindungsspezifisches DNS-Suffix: mylan.mydom.de
   Beschreibung. . . . . . . . . . . : Intel(R) PRO/1000 MT Desktop Adapter
   Physische Adresse . . . . . . . . : <...>
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : <...>(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.0.130(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Dienstag, 11. Juli 2023 14:12:59
   Lease läuft ab. . . . . . . . . . : Mittwoch, 12. Juli 2023 02:12:59
   Standardgateway . . . . . . . . . : 192.168.0.99
   DHCP-Server . . . . . . . . . . . : 192.168.0.1
   DHCPv6-IAID . . . . . . . . . . . : 84410407
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-2B-62-8E-EB-08-00-27-AC-76-8E
   DNS-Server  . . . . . . . . . . . : 192.168.0.2
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Es steht also genau der "zweite" DNS-Server dort, und auch nur der!

Wo kann denn da der Fehler liegen? Kann ich irgendwo nachsehen, was mit welchem dnsmasq gesprochen wurde?

DJKUhpisse schrieb:

Dann musst du einen DNS-Client nutzen, der schnell umschaltet, z.B. systemd-resolve.

Da ich "von Windows komme", sind meine Clients normalerweise Mint (Debian und Ubuntu nur zum "mal testen"). Meine Server sind allerdings alle Ubuntu 20.04 und 22.04.

Da jedoch beide dnsmasqs die statische /etc/hosts haben, kann auch das nicht die große Verzögerung erklären. Denn für die (festen) Server-Adressen im lokalen Netz ist kein Forwarding nötig, und beide dnsmasqs laufen zur Zeit. Ich bin ein bisschen ratlos...

Achso, noch ein Nachtrag: der Win10-Client hat null Verzögerung, egal ob Hosts im lokalen Netz oder entfernt durch den Tunnel.
Scheint also am Mint-Client zu liegen... muss ich mal einen Debian starten oder auf einem der Ubuntu-Server gucken... melde mich.

Das Verhalten ist auf einem Ubuntu 22.04 und auf einem aktuellen Debian gleich wie auf Mint: 15s bis zur Namensauflösung, "0s" auf Win10.

Irgend eine Idee, was ich wo nachsehen oder gar reparieren könnte?

Emma2 schrieb:

..., "0s" auf Win10.

BTW: Bei "0s" wird i. d. R. ein DNS-cache benutzt.

Z. B. ohne im cache:

:~$ dig @127.0.0.1 whitehouse.gov | grep msec -A1
;; Query time: 417 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

und sofort danach, mit im cache:

:~$ dig @127.0.0.1 whitehouse.gov | grep msec -A1
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

BTW: Bei "0s" wird i. d. R. ein DNS-cache benutzt.

Scheint mir hier nicht so, zumindest ist er nicht deshalb so schnell:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

C:\Users\localAdmin>ipconfig /flushdns

Windows-IP-Konfiguration

Der DNS-Auflösungscache wurde geleert.

C:\Users\localAdmin>ping svr-lan

Ping wird ausgeführt für svr-lan.mylan.mydom.de [192.168.0.1] mit 32 Bytes Daten:
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64

Ping-Statistik für 192.168.0.1:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum = 1ms, Mittelwert = 0ms

Außerdem ist mir ja sowieso wichtiger, dass meine iXe schneller sind. Die WIn-VM habe ich nur gestartet, um ein Indiz dafür zu bekommen, ob es an meinem dnsmasq liegt. Aber der Antwortet anscheinend schnell (auch wenn ich eine Kiste anpinge, auf die ich vorher noch nicht gezielt habe, die also nicht im Cahce sein kann).

Edit: Mumpitz, gelöscht, mein Fehler, bei dig muss wohl sinnvollerweise der Server angegeben werden:

1
2
3

$ dig @svr-lan svr-com | grep msec -A1
;; Query time: 0 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)

Da steht zwar "0 msec", bis diese Meldung kommt, dauert es aber die bekannten 15 s.