[gelöst] systemd-networkd zweite IP DNS

[oln]

Hallo Forum,
da ich nun eine Kiste umgestellt habe auf systemd ist mir folgendes aufgefallen.
Aus Kompatibilitätsgründen hat(te) der Server eine zweite IP. Dies habe ich auch mit einem zweiten Address Eintrag unter systemd herstellen können.
Was nun das Problem ist, dass der Server nun an den DNS ein Update gibt und nun dort beide IPs mit dem gleichen Namen eingetragen werden.
Somit gibt es zwei A-Einträge für ein und die Selbe IP. Das ist aber falsch, weil die zweite(alte IP) einen anderen Namen im DNS hat.
Bei interfaces gab es kein DNS-Update. Kann man das unterbinden? Finde leider nichts in der Doku bzw. weis ich nicht recht nach was ich suchen soll.
Danke im Voraus.

[JTH]

Vielleicht hilft dir die Option SendHostname= weiter? Siehe man systemd.network zu den Details.

[oln]

Vielleicht hilft dir die Option SendHostname= weiter? Siehe man systemd.network zu den Details.

Danke für den Tip. Leider funktioniert das nur bei DHCP. Der Server ist aber static.

[MSfree]

Was nun das Problem ist, dass der Server nun an den DNS ein Update gibt und nun dort beide IPs mit dem gleichen Namen eingetragen werden.

Clients dürfen den DNS nicht einfach mal Updaten, denn dazu ist ein Schlüssel nötig, den die Clients in den meisten Fällen gar nicht kennen. Ich kann mir also nicht vorstellen, daß das Update clientseitig angestossen wurde.

Üblicherweise sorgt der DHCP-Server dafür, daß der DNS aktualisiert wird. Dem DHCP-Server muß man dazu aber den Schlüssel für die DNS-Manipulation konfigurieren. Ein Rechner mit statischer IP, der kein DHCP nutzt, kann also nicht dafür sorgen, daß deine Kiste den DNS aktualisiert. Ich fürchte, du suchst an der falschen Stelle.

Was sagen denn die Logs bzgl. DHCP-Server und DNS-Server?

[oln]

Clients dürfen den DNS nicht einfach mal Updaten, denn dazu ist ein Schlüssel nötig, den die Clients in den meisten Fällen gar nicht kennen. Ich kann mir also nicht vorstellen, daß das Update clientseitig angestossen wurde.

Das Problem gab es bei der interfaces nicht. Also muss es mit systemd zusammen hängen.
Ok ich habe nicht alles geschrieben. Der Server hat einen Bind9 und ist der Second-DNS hier im Netz. Generell ist mein Bind so konfiguriert, dass der DHCP(anderer Server) den DNS aktualisieren darf.
Aber ich habe nun dem Abschnitf [Network] ein DHCP=no hinzugefügt. nun ist der Spuk vorbei. Scheint so als ob der Server trotzdem ein DHCP-Request abgegeben hat obwohl als static konfiguriert.
Leider finde ich keine gescheite Doku zu meinem Thema.
Trotzdem danke an alle Beteiligten.

[JTH]

Dann hätte dir obige Option vielleicht doch auch helfen können

[oln]

Dann hätte dir obige Option vielleicht doch auch helfen können

Ich musste den Thread nochmal aufmachen. Leider besteht das Problem weiter.

In den Logs auf dem Ersten DNS(neptun) habe ich folgendes gefunden:

Code: Alles auswählen

Aug 21 07:30:51 neptun named[361173]: client @0x7fad54039160 192.168.1.221#54251/key pluto\$\@example.COM: updating zone 'example.com/NONE': adding an RR at 'pluto.example.com' A 192.168.1.101
Aug 23 07:30:51 neptun named[361173]: samba_dlz: added rdataset pluto.example.com 'pluto.example.com.#0113600#011IN#011A#011192.168.1.101'
Aug 23 07:30:51 neptun named[361173]: client @0x7fad54039160 192.168.1.221#54251/key pluto\$\@example.COM: updating zone 'example.com/NONE': adding an RR at 'pluto.example.com' A 192.168.1.100
Aug 23 07:30:51 neptun named[361173]: samba_dlz: added rdataset pluto.example.com 'pluto.example.com.#0113600#011IN#011A#011192.168.1.100'
Aug 23 07:30:51 neptun named[361173]: client @0x7fad54039160 192.168.1.221#54251/key pluto\$\@example.COM: updating zone 'example.com/NONE': adding an RR at 'pluto.example.com' A 192.168.1.221
Aug 23 07:30:51 neptun named[361173]: samba_dlz: added rdataset pluto.example.com 'pluto.example.com.#0113600#011IN#011A#011192.168.1.221'

Tja und das sollte eigentlich nicht passieren. Was zur Hölle muss ich ändern? Oder doch zurück zu interfaces?
Ich pack mal meine config mit an den Thread. Vielleicht hab ich ja was falsch gemacht.

Code: Alles auswählen

[root@pluto network]# cat uplink.network
[Match]
Name=eno1

[Network]
Bridge=br0

[root@pluto network]# cat br0.netdev
[NetDev]
Name=br0
Kind=bridge

[root@pluto network]# cat br0.network
[Match]
Name=br0

[Network]
#DNS=192.168.1.225
Domains=example.com
Address=192.168.1.221/24
DHCP=no
#Address=192.168.1.100/24
#Address=192.168.1.101/24
Gateway=192.168.1.1

# old web
[Address]
Label=br0:0
Address=192.168.1.101/24

# old db
[Address]
Label=br0:1
Address=192.168.1.100/24

Die zwei Address-Abschnitte habe ich nur aus Verzweiflung erstellt. Oben sieht man noch die vorherige Config als Comment.

[MSfree]

In den Logs auf dem Ersten DNS(neptun) habe ich folgendes gefunden:

Kannst du dein Log mal nach DHCP durchsuchen:

Code: Alles auswählen

journalctl | grep -i DHCP

P.S.: gelöst hat nicht mit den Schluffsediment Löß zu tun *SCNR*

[oln]

In den Logs auf dem Ersten DNS(neptun) habe ich folgendes gefunden:

Kannst du dein Log mal nach DHCP durchsuchen:

Code: Alles auswählen

journalctl | grep -i DHCP

Da kommt kein Eintrag von dem besagten Server. Also dhcp macht der ersteinmal nicht.

P.S.: gelöst hat nicht mit den Schluffsediment Löß zu tun *SCNR*

[MSfree]

Da kommt kein Eintrag von dem besagten Server. Also dhcp macht der ersteinmal nicht.

Mir ist nicht klar, was du als Server bezeichnest. Offenbar hast du einen Rechner, auf dem ein DHCP-Server läuft und einen, auf dem ein DNS-Sever läuft. Dazu kommt der Rechner, den du als "Server" bezeichnest. Drei Server sind halt etwas verwirrend. Bitte um Aufklärung, was wo läuft.

Jedenfalls sollst du das Log von dem Rechner durchsuchen, auf dem der DHCP-Server läuft, um festzustellen, welche Anfragen der DHCP-Client stellt.

[oln]

Ok, dann kläre ich mal auf.
Pluto das Problemkind:
- Bind9 als Slave
- Domanmitglied
- div. anderes
- umgestellt von interfaces auf systemd
- drei IPs
- update des DNS welches er nicht tun sollte.

Neptun:
- DHCP
- bind9 als Master
- div. anders

Jedenfalls sollst du das Log von dem Rechner durchsuchen, auf dem der DHCP-Server läuft, um festzustellen, welche Anfragen der DHCP-Client stellt.

War mir schon klar. Das habe ich getan ohne Ergebnis.
Aber wie oben zu sehen, schickt er ein Update an den Master-DNS. Und das genau seit der Umstellung.

[mat6937]

War mir schon klar. Das habe ich getan ohne Ergebnis.
Aber wie oben zu sehen, schickt er ein Update an den Master-DNS. Und das genau seit der Umstellung.

Benutzt Du auch systemd-resolved?

Code: Alles auswählen

systemctl status systemd-resolved
resolvectl status

?

[MSfree]

Pluto das Problemkind:
- Bind9 als Slave

Neptun:
- bind9 als Master

Hast du mal die Logs von Pluto und Neptun nach named durchsucht?
Kann es sein, daß Plutos bind9-Slave vom networkd aktualisiert wird und der das nur an Neptun durchreicht?

...Das habe ich getan ohne Ergebnis.

OK, dann ist DHCP wohl auch ziemlich sicher unbeteiligt.

[oln]

Hast du mal die Logs von Pluto und Neptun nach named durchsucht?
Kann es sein, daß Plutos bind9-Slave vom networkd aktualisiert wird und der das nur an Neptun durchreicht?

Ja habe ich. Dort hab ich nur auf dem Neptun den Eintag in den oben genannten Logs gefunden. Das sieht für mich aber so aus, als ob auf dem Pluto ein dhcp-Client läuft. Ist aber nicht.
Auf dem Pluto wird nur ein transfer vom Master(Neptun) auf den Slave(Pluto) angestoßen. Umgekehrt finde ich nichts.

[oln]

Benutzt Du auch systemd-resolved?

Nein. Da static und er selber ja ein DNS ist. Ist fest eingetragen in der /etc/resolv.conf.

[MSfree]

Das sieht für mich aber so aus, als ob auf dem Pluto ein dhcp-Client läuft. Ist aber nicht.

Wenn das der Fall wäre, müßtest du in Neptuns Logs DHCP-Einträge finden.

Auf meinem Internetrouter, auf dem auch der DHCP-Server und ein bind9 laufen, sehe ich regelmässig Einträge der Art:

Code: Alles auswählen

Aug 23 06:41:24 router dhcpd[787]: DHCPREQUEST for 192.168.x.x from 11:22:33:44:55:66 via enp2s0
Aug 23 06:41:24 router dhcpd[787]: DHCPACK on 192.168.x.x to 11:22:33:44:55:66 via enp2s0

Auch in meinen Clients werden die DHCP-Anfragen gelogt, die Logeinträge sehen ähnlich aus wie auf der Serverseite.

Wenn das bei dir nicht der Fall ist, ist auch keine DHCP-Client beteiligt.

Da du auf beiden Rechnern DNS-Server laufen hast, würde ich dort mal auf beiden Rechnern nach Einträgen suchen. Ggfls. mußt du dazu das loglevel der beiden bind9 hochsetzen, um alle Aktivitäten mitzubekommen. Dauerhaft das loglevel hochsetzen ist aber keine gute Idee, weil sonst schnell der Plattenplatz knapp werden kann.

[oln]

Ja stimmt.
Alle anderen Client bekommen ja ein Logeintrag mit einem Request.
Nur wie oder warum wird der DNS aktualisiert?
Könnte das der Bind9 selber sein, da ich ein Listen auf allen drei IPs habe? Das würde in der Doamin auch erklären warum dor auch alle drei IPs als DNS auftauchen.
Merkwürdig nur, dass dies bei interfaces nicht der Fall war. Das komplette Setup läuft hier schon seit einigen Jahren. Und die Probleme tauchen erst nach der Umstellung auf.

[MSfree]

Könnte das der Bind9 selber sein,

Wie gesagt, um bind9 zu manipulieren, also neue Einträge einzufügen oder bestehende Einträge zu löschen, braucht man einen Schlüssel. Bind9 nimmt Änderungsanfragen also nur mit einem gültigen Schlüssel entgegen.

Irgendwas hat also einen Schlüssel, um deine DNS-Einträge zu erzeugen. Typischerweise wäre das eben der DHCP-Server, aber den haben wir ja erstmal ausgeschlossen.

Merkwürdig nur, dass dies bei interfaces nicht der Fall war.

Was soll daran merkwürdig sein, wenn sich ein zwei verschiedene Programme unterschiedlich verhalten? Wobei ich das Verhalten, was du gerade beobachtest, als Bug bezeichnen würde, zumindest, wenn das das Defaultverhalten sein sollte.

Warum betreibst du überhaupt einen (Slave-)DNS auf dem Pluto? Ist der Master-DNS auf dem Neptun denn so schwachbrüstig, daß dem bereits bei ein paar DNS-Abfragen die Luft ausgeht? Das kann ich mir gar nicht vorstellen, denn die Low-End Kiste mit Celeron N3450, die ich hier als Router benutze, langweilt sich zu Tode. CPU-Lasten von mehr als 1% sind fast nicht erreichbar, und da läuft noch einiges mehr als nur DNS und DHCP.

[oln]

Ich setz jetzt mal ne VM auf mit mehren IPs und ohne irgend etwas. Mal sehen was passiert. Nur ein Join in die Active Directory.

[oln]

Ok. Ich habe den Schuldigen gefunden.
Nach restart von sssd wird in der AD der Eintrag(Ticket) aktualisiert und bekommt die zusätzlichen IPs. Da bei einer Active Directory der gejointe Server/PC in den DNS aufgenommen wird, treten meine genannten Probleme auf.

Nur wie kann ich das dem sssd abgewöhnen?
Die manpage schweigt sich dazu aus.
EDIT:
Ok die Lösung ist gefunden.
In die sssd.conf in dem Domainabschnitt das Interface welches für die Domain gelten soll einfügen:
Sieht dann in meinem Fall so aus.

Code: Alles auswählen

dyndns_iface = br0

[mat6937]

Ok die Lösung ist gefunden.

D. h., den sssd hast Du mit der interfaces-Datei nicht benutzt, sondern erst jetzt mit systemd-networkd, oder?

[oln]

D. h., den sssd hast Du mit der interfaces-Datei nicht benutzt, sondern erst jetzt mit systemd-networkd, oder?

Doch. Ohne kein Domainmitglied.
Aber bei Interfaces wurden die br0:0 und br0:1 nicht betrachtet Bei Systemd anscheinend ja.
Woran das liegt werde ich noch heraus bekommen.

[mat6937]

Aber bei Interfaces wurden die br0:0 und br0:1 nicht betrachtet Bei Systemd anscheinend ja.

Dann lass mal die Labels:

Code: Alles auswählen

#Label=br0:0
#Label=br0:1

in der network-Datei weg. Die zusätzlichen IP-Adressen werden auch ohne "Label=" zugewiesen.

[oln]

Das hatte ich am Anfang. Sieht man auch an den auskommentierten Zeilen.
Hat auch nichts gebracht.

[mat6937]

Sieht man auch an den auskommentierten Zeilen.

Welche auskommentierten Zeilen meinst Du? Die in der [Network]-Section? Wenn ja, die meinte ich nicht. Ich meine die Label-Zeilen in der [Address]-Section.

EDIT:

BTW: Poste mal, mit und ohne wirksame Label-Zeilen, die Ausgaben von:

Code: Alles auswählen

ip a
hostname -i
hostname -I
dig -x $(hostname -i) +short
dig -x $(hostname -I) +short