lokale Namensauflösung
lokale Namensauflösung
Internet <- Fritzbox(lokal01: 192.168.178.0 bzw. fritz.box) <- RPi4b -> DLINK (lokal02: 192.168.251.0 bzw. Home.stue)
Der RPi hängt per eth0 an der Fritzbox und hat Zugriff auf 192.168.178.0 und Internet
Der RPi hängt per wlan0 am DLINK und hat Zugriff auf 192.168.251.0
RPi erreicht Geräte aus beiden Netzen. Geräte aus lokal01 und lokal02 können sich selbstverständlich nicht erreichen (ist auch nicht gewollt).
Fritzbox dient als DHCP+DNS-Server für lokal01
DLINK hat DHCP deaktiviert und keine Internetverbindung eingerichtet
RPi4b hat isc-dhcp installiert
/etc/dhcpcd.conf
interface wlan0
static ip_address=192.168.251.200/24
/etc/default/isc-dhcp-server
INTERFACESv4="wlan0"
/etc/dhcp/dhcpd.conf
default-lease-time 600;
max-lease-time 7200;
ddns-update-style none;
authoritative;
subnet 192.168.251.0 netmask 255.255.255.0 {
range 192.168.251.5 192.168.251.99;
option domain-name-servers 192.168.251.200;
option domain-name "stue.home";
option routers 192.168.251.200;
option broadcast-address 192.168.251.255;
}
Problem:
vom RPi4b: ping -c 2 192.168.178.199 = erfolgreich
vom RPi4b: ping -c 2 fritz.box = erfolgreich
vom RPi4b: ping -c 2 192.168.251.199 = erfolgreich
vom RPi4b: ping -c 2 home.stue = "Der Name oder der Dienst ist nicht bekannt" (so wie bei allen Hostnamen aus dem netz)
gewünscht:
Der Client ausm lokal02 holt sich beim RPi4b IP und DNS-Server-IP; RPi speichert IP und Hostname und kann auf Abruf vom Hostname die IP vermitteln.
Der DLINK stellt nur das WLAN-Signal zur Verfügung (DHCP von RPi4b).
Fritzbox und lokal01 bleiben unberührt (RPi4b ist über LAN angeschlossen und hat Internet-Verbindung) (das funzt auch)
Fragen:
Was stimmt beim isc-dhcp-configs nicht?
Reicht es beim DLINK einfach DHCP zu deaktivieren? Die DNS-Server IP bekommen die Clients doch während der DHCP-Anfrage, oder?
Muss (kann) ich beim RPi4b die Schnittstellen so konfigurieren, dass eine DNS-Abfrage (z.B. ping hostname) erst über wlan0 und dann über eth0 rausgeht?
Ich hoffe, dass sind nicht zu viel bzw zu wenig Details.
MfG
Stue
Der RPi hängt per eth0 an der Fritzbox und hat Zugriff auf 192.168.178.0 und Internet
Der RPi hängt per wlan0 am DLINK und hat Zugriff auf 192.168.251.0
RPi erreicht Geräte aus beiden Netzen. Geräte aus lokal01 und lokal02 können sich selbstverständlich nicht erreichen (ist auch nicht gewollt).
Fritzbox dient als DHCP+DNS-Server für lokal01
DLINK hat DHCP deaktiviert und keine Internetverbindung eingerichtet
RPi4b hat isc-dhcp installiert
/etc/dhcpcd.conf
interface wlan0
static ip_address=192.168.251.200/24
/etc/default/isc-dhcp-server
INTERFACESv4="wlan0"
/etc/dhcp/dhcpd.conf
default-lease-time 600;
max-lease-time 7200;
ddns-update-style none;
authoritative;
subnet 192.168.251.0 netmask 255.255.255.0 {
range 192.168.251.5 192.168.251.99;
option domain-name-servers 192.168.251.200;
option domain-name "stue.home";
option routers 192.168.251.200;
option broadcast-address 192.168.251.255;
}
Problem:
vom RPi4b: ping -c 2 192.168.178.199 = erfolgreich
vom RPi4b: ping -c 2 fritz.box = erfolgreich
vom RPi4b: ping -c 2 192.168.251.199 = erfolgreich
vom RPi4b: ping -c 2 home.stue = "Der Name oder der Dienst ist nicht bekannt" (so wie bei allen Hostnamen aus dem netz)
gewünscht:
Der Client ausm lokal02 holt sich beim RPi4b IP und DNS-Server-IP; RPi speichert IP und Hostname und kann auf Abruf vom Hostname die IP vermitteln.
Der DLINK stellt nur das WLAN-Signal zur Verfügung (DHCP von RPi4b).
Fritzbox und lokal01 bleiben unberührt (RPi4b ist über LAN angeschlossen und hat Internet-Verbindung) (das funzt auch)
Fragen:
Was stimmt beim isc-dhcp-configs nicht?
Reicht es beim DLINK einfach DHCP zu deaktivieren? Die DNS-Server IP bekommen die Clients doch während der DHCP-Anfrage, oder?
Muss (kann) ich beim RPi4b die Schnittstellen so konfigurieren, dass eine DNS-Abfrage (z.B. ping hostname) erst über wlan0 und dann über eth0 rausgeht?
Ich hoffe, dass sind nicht zu viel bzw zu wenig Details.
MfG
Stue
- unitra
- Beiträge: 638
- Registriert: 15.06.2002 21:09:38
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: 127.128.129.130
Re: lokale Namensauflösung
Zeig mal bitte die Ausgabe von
am RPi wenn beide Schnittstellen aktiv sind.
Code: Alles auswählen
ip route
Code: Alles auswählen
ip add
Code: Alles auswählen
cat /proc/sys/net/ipv4/ip_forward
Re: lokale Namensauflösung
Welchen DNS Server hast du denn für die Zone "stue.home" eingerichtet? In deiner Beschreibung steht nur was von DHCP
Re: lokale Namensauflösung
Wie sind die Ausgaben von:Stue hat geschrieben:31.03.2020 00:42:45
option domain-name "stue.home";
vom RPi4b: ping -c 2 home.stue = "Der Name oder der Dienst ist nicht bekannt" (so wie bei allen Hostnamen aus dem netz)
Code: Alles auswählen
host -t A stue.home
host -t A stue.home 192.168.251.200
Code: Alles auswählen
ping -c 2 stue.home
ping -c 2 192.168.251.200
Re: lokale Namensauflösung
host -t A stue.home = Host stue.home not found: 3(NXDOMAIN)
host -t A stue.home 192.168.251.200 = ;; connection timed out; no servers could be reached
ip route =
default via 192.168.178.1 dev eth0 proto dhcp src 192.168.178.4 metric 202
192.168.178.0/24 dev eth0 proto dhcp scope link src 192.168.178.4 metric 202
192.168.251.0/24 dev wlan0 proto dhcp scope link src 192.168.251.200 metric 303
ip add =
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether dc:a6:32:4f:ad:81 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.4/24 brd 192.168.178.255 scope global dynamic noprefixroute eth0
valid_lft 816054sec preferred_lft 708054sec
inet6 fe80::741e:f6d8:968c:33e3/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether dc:a6:32:4f:ad:82 brd ff:ff:ff:ff:ff:ff
inet 192.168.251.200/24 brd 192.168.251.255 scope global noprefixroute wlan0
valid_lft forever preferred_lft forever
inet6 fe80:
caaa:c68b:cb86/64 scope link
valid_lft forever preferred_lft forever
cat /proc/sys/net/ipv4/ip_forward = 0
option domain-name-servers 192.168.251.200;
option domain-name "stue.home";
...in der /etc/dhcp/dhcpd.conf
host -t A stue.home 192.168.251.200 = ;; connection timed out; no servers could be reached
ip route =
default via 192.168.178.1 dev eth0 proto dhcp src 192.168.178.4 metric 202
192.168.178.0/24 dev eth0 proto dhcp scope link src 192.168.178.4 metric 202
192.168.251.0/24 dev wlan0 proto dhcp scope link src 192.168.251.200 metric 303
ip add =
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether dc:a6:32:4f:ad:81 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.4/24 brd 192.168.178.255 scope global dynamic noprefixroute eth0
valid_lft 816054sec preferred_lft 708054sec
inet6 fe80::741e:f6d8:968c:33e3/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether dc:a6:32:4f:ad:82 brd ff:ff:ff:ff:ff:ff
inet 192.168.251.200/24 brd 192.168.251.255 scope global noprefixroute wlan0
valid_lft forever preferred_lft forever
inet6 fe80:
valid_lft forever preferred_lft forever
cat /proc/sys/net/ipv4/ip_forward = 0
Ich dachte der RPi übernimmt diesen Dienst mit der Angabe...bluestar hat geschrieben:31.03.2020 08:14:23
Welchen DNS Server hast du denn für die Zone "stue.home" eingerichtet? In deiner Beschreibung steht nur was von DHCP
option domain-name-servers 192.168.251.200;
option domain-name "stue.home";
...in der /etc/dhcp/dhcpd.conf
Re: lokale Namensauflösung
Nein damit sagst du deinem DHCP-Server lediglich, welche Informationen er bekanntgeben soll.Stue hat geschrieben:31.03.2020 13:08:47Ich dachte der RPi übernimmt diesen Dienst mit der Angabe...
option domain-name-servers 192.168.251.200;
option domain-name "stue.home";
...in der /etc/dhcp/dhcpd.conf
Den passenden DNS-Server musst du schon selbst installieren und einrichten.
Re: lokale Namensauflösung
Ok, ich hatte mich schon gewundert, dass isc-dhcp so wenig DNS-Angaben haben will.
Dann werd ich der Domain mal nen Server schenken... Manchmal sucht man die Fehler wirklich an der völlig falschen Stelle...
Dann werd ich der Domain mal nen Server schenken... Manchmal sucht man die Fehler wirklich an der völlig falschen Stelle...
Re: lokale Namensauflösung
Soweit, so ...nicht... gut
Nachdem ich mich mit bind9 und isc-dhcp-server vertraut gemacht habe und beides fehlerfrei am laufen habe stellt sich nun folgendes Problem dar:
setze ich in /etc/dhcpcd.conf
funktioniert nur die Namensauflösung von dem 192.168.251.0-Netz (z.B. ping -c 2 stue.home)
setze ich jedoch in /etc/dhcpcd.conf
funktioniert nur die Namensauflösung von dem 192.168.178.0-Netz (z.B. ping -c 2 fritz.box)
Wie,wo,was muss ich denn anpassen, damit der Raspberry Geräte in beiden Netzen per Hostname ansprechen kann?
nochmal zur Veranschaulichung:
![2633](https://debianforum.de/forum/app.php/gallery/image/2633/mini)
EDIT:
nur der RPi soll die Namensauflösung machen können, nicht alle Geräte aus 192.168.251.0
Nachdem ich mich mit bind9 und isc-dhcp-server vertraut gemacht habe und beides fehlerfrei am laufen habe stellt sich nun folgendes Problem dar:
setze ich in /etc/dhcpcd.conf
Code: Alles auswählen
interface wlan0
metric 200
setze ich jedoch in /etc/dhcpcd.conf
Code: Alles auswählen
interface eth0
metric 100
Wie,wo,was muss ich denn anpassen, damit der Raspberry Geräte in beiden Netzen per Hostname ansprechen kann?
nochmal zur Veranschaulichung:
EDIT:
nur der RPi soll die Namensauflösung machen können, nicht alle Geräte aus 192.168.251.0
Re: lokale Namensauflösung
Ich fange mal an bei dem was mir so an Veränderungen einfallen würde:
1) RasPi mit fester IP im 192.168.178.0 LAN einrichten.
2) auf der Fritzbox eine Route für das Netz 192.168.251.0 / 255.255.255.0 auf die feste IP des RasPI einrichten.
3) auf dem RasPi in /etc/resolv.conf nur 127.0.0.1 als Nameserver eintragen.
4) der Bind9 auf deinem RasPi benötigt eine Forward-Zone für die Domäne "fritz.box", diese sieht wie folgt aus:
Wenn du möchtest, dann erkläre ich das noch mal ausführlicher, morgen.
1) RasPi mit fester IP im 192.168.178.0 LAN einrichten.
2) auf der Fritzbox eine Route für das Netz 192.168.251.0 / 255.255.255.0 auf die feste IP des RasPI einrichten.
3) auf dem RasPi in /etc/resolv.conf nur 127.0.0.1 als Nameserver eintragen.
4) der Bind9 auf deinem RasPi benötigt eine Forward-Zone für die Domäne "fritz.box", diese sieht wie folgt aus:
Code: Alles auswählen
zone "fritz.box" {
type forward;
forward only;
forwarders { 192.168.178.1; };
};
Re: lokale Namensauflösung
schnelle Antwort und dann morgen weiter:
zu 1) und 2):
Das hört sich grundsätzlich gut an, aber scheint nicht zu 100% nötig, da die Namensauflösung ja funzt, wenn eth0 priorisiert ist.
zu 3)
hab die /etc/resolvconf.conf genommen und ausschließlich 127.0.0.1 angegeben -> keine Verbesserung
zu 4)
würde das nicht bedeuten, dass alle Geräte aus 192.168.251.0 auf fritz.box zugreifen können? Das würde ich gerne vermeiden.
Mein Gedanke war, dass ich dem RPi manuell mitteile, wer DNS-Server ist
(1. Anfrage an bind9 bzw. 192.168.251.200
2. Anfrage an fritz.box bzw. 192.168.178.1)
zu 1) und 2):
Das hört sich grundsätzlich gut an, aber scheint nicht zu 100% nötig, da die Namensauflösung ja funzt, wenn eth0 priorisiert ist.
zu 3)
hab die /etc/resolvconf.conf genommen und ausschließlich 127.0.0.1 angegeben -> keine Verbesserung
zu 4)
würde das nicht bedeuten, dass alle Geräte aus 192.168.251.0 auf fritz.box zugreifen können? Das würde ich gerne vermeiden.
Mein Gedanke war, dass ich dem RPi manuell mitteile, wer DNS-Server ist
(1. Anfrage an bind9 bzw. 192.168.251.200
2. Anfrage an fritz.box bzw. 192.168.178.1)
Re: lokale Namensauflösung
Zu 4)
du kannst nicht zwei Nameserver für unterschiedliche Domänen, so wie du es dir vorstellst verwenden.
Du kannst aber in dem forward zone block mit allow-query .... die Nutzung auf das 192.168.251.0/24 Netz und auf 127.0.0.1 einschränken
du kannst nicht zwei Nameserver für unterschiedliche Domänen, so wie du es dir vorstellst verwenden.
Du kannst aber in dem forward zone block mit allow-query .... die Nutzung auf das 192.168.251.0/24 Netz und auf 127.0.0.1 einschränken
Re: lokale Namensauflösung
Nachdem ich mehrere Anpassungen in /etc/bind/named.conf.options vorgenommen habe funktioniert es wie gewollt.
Vorweg möchte ich auf deine Ratschläge eingehen:
zu 1) und 2)
wie bereits geschrieben habe ich noch keine Probleme bekommen, deswegen werde ich vorerst den Raspberry per DHCP von der Fritzbox (192.168.178.1) seine IP beziehen lassen und keine Route in der Fritzbox Richtung 192.168.251.200 einrichten.
zu 3)
hab ich nach bestem Wissen und Gewissen umgesetzt
zu 4)
ne forwardzone hab ich nicht eingerichtet, jedoch in /etc/bind/named.conf.options folgende Einstellungen getroffen.
Da mir der Überblick fehlt, welche Werte ich genau angepasst habe nenne ich einfach mal alle Einstellungen. Vielleicht fallen dir trotz Funktionstüchtigkeit Fehler/Unstimmigkeiten/"unsaubere" Lösungen auf:
Hierbei ist zu erwähnen, dass "forwarders { 192.168.178.1; };" wahrscheinlich einer der keyfacts ist. kommentiere ich dieses aus, funktioniert die Namensauflösung nur in einem Netz. Ist diese Option wirksam, funktioniert die Namensauflösung vom RPi aus in beiden Netzen. Clients aus den einzelnen Netzen haben keinen Zugriff auf Clients im jeweils anderen Netz. Nur der RPi hat Zugriff in beide Netze.
Vorweg möchte ich auf deine Ratschläge eingehen:
zu 1) und 2)
wie bereits geschrieben habe ich noch keine Probleme bekommen, deswegen werde ich vorerst den Raspberry per DHCP von der Fritzbox (192.168.178.1) seine IP beziehen lassen und keine Route in der Fritzbox Richtung 192.168.251.200 einrichten.
zu 3)
hab ich nach bestem Wissen und Gewissen umgesetzt
zu 4)
ne forwardzone hab ich nicht eingerichtet, jedoch in /etc/bind/named.conf.options folgende Einstellungen getroffen.
Da mir der Überblick fehlt, welche Werte ich genau angepasst habe nenne ich einfach mal alle Einstellungen. Vielleicht fallen dir trotz Funktionstüchtigkeit Fehler/Unstimmigkeiten/"unsaubere" Lösungen auf:
Code: Alles auswählen
acl "acl_trusted_transfer" { none; };
acl "acl_trusted_clients" {
127.0.0.0/8; // localhost (RFC 3330) - Loopback-Device addresses 127.0.0.0 - 127.255.255.255
192.168.0.0/16; // Private Network (RFC 1918) - e. e. LAN 192.168.0.0 - 192.168.255.255
};
options {
directory "/var/cache/bind";
pid-file "/var/run/named/named.pid";
version "not currently available";
listen-on-v6 { none; };
listen-on { any; };
notify no;
allow-query {
acl_trusted_clients;
};
allow-query-cache {
acl_trusted_clients;
};
allow-recursion {
acl_trusted_clients;
};
allow-transfer {
none;
};
allow-update {
none;
};
dnssec-validation yes;
auth-nxdomain no; # conform to RFC1035
empty-zones-enable yes;
recursion yes;
forwarders {
// Router DNS
192.168.178.1;
};
};
Re: lokale Namensauflösung
Bei (4) muss ich sagen, ja die Lösung funktioniert auch ... Birgt allerdings die Einschränkung, dass die Clients im 192.168.251.0 nicht über den RasPi-DNS Internet-Hosts auflösen können -> Ich vermute mal das war/ist von dir so gewünscht.
Re: lokale Namensauflösung
Ja das war gewünscht. Im Prinzip wollte ich ein separates Netz für Geräte, die einfach keinen Internetzugang benötigen. Da der Uralt-DLINK irgendwie nicht das machen wollte, was ich mir vorgestellt habe, wollte ich mal eben DNS und DHCP über den RPi bereitstellen... naja das Ergebnis gefällt mir, auch wenn der Aufwand ganz schön groß war ![Thumbs Up :THX:](./images/smilies/thumbup.gif)
![Thumbs Up :THX:](./images/smilies/thumbup.gif)
Re: lokale Namensauflösung
Leider muss ich hier erneut ansetzen.
Vorerst die nochmal die Netzwerkstruktur skiziert:
![4394](https://debianforum.de/forum/app.php/gallery/image/4394/mini)
gewünschtes Ziel:
DeviceA1 ist in DomainA
RasPi führt "ping -c 2 DeviceA1" erfolgreich aus
DeviceA1 wechselt in DomainB
RasPi führt "ping -c 2 DeviceA1" erfolgreich aus
Problem:
mit Bookworm hat /etc/dhcpcd.conf scheinbar nicht mehr die bisherigen Auswirkungen
Fehlerbild:
vermutete Ursache:
- Seit Bookworm hat /etc/dhcpcd.conf scheinbar nicht mehr die bisherigen Auswirkungen
- die statische IP für wlan0 muss jetzt über nmtui eingestellt werden
- inwiefern metering ne rolle spielt hab ich noch nicht ganz durchblickt, (wlan0 und eth0 auf 100 setzen gab keine Änderung)
bisherige Änderungen:
/etc/dhcpcd.conf gelöscht
Fragen:
1. Warum fragt der RasPi nicht erst beim NS von DomainA "kennst du die IP von DeviceA1?" und bei negativer Antwort nochmal beim NS von DomainB?
2. Welche Dienste müssen angepasst werden? bind9, isc-dhcp, Netzwerkvorgaben per nmtui? (DNS und DHCP-Vergabe in den jeweiligen Netzen funzt ja wie gewünscht)
Vorerst die nochmal die Netzwerkstruktur skiziert:
gewünschtes Ziel:
DeviceA1 ist in DomainA
RasPi führt "ping -c 2 DeviceA1" erfolgreich aus
DeviceA1 wechselt in DomainB
RasPi führt "ping -c 2 DeviceA1" erfolgreich aus
Problem:
mit Bookworm hat /etc/dhcpcd.conf scheinbar nicht mehr die bisherigen Auswirkungen
Fehlerbild:
Code: Alles auswählen
arp -a
? (192.168.251.15) at c4:bb:11:11:11:63 [ether] on wlan0
DeviceA2.DomainA (192.168.178.3) at 80:aa:11:11:11:c4 [ether] on eth0
------
ip neighbour
192.168.251.15 dev wlan0 lladdr c4:bb:11:11:11:63 STALE
192.168.178.3 dev eth0 lladdr 80:aa:11:11:11:c4 REACHABLE
------
ping DeviceA1
ping: DeviceA1: Name or service not known
------
ping DeviceA1.DomainB
ping: DeviceA1: Name or service not known
------
ping 192.168.251.15
PING 192.168.251.15 (192.168.251.15) 56(84) bytes of data.
64 bytes from 192.168.251.15: icmp_seq=1 ttl=255 time=4.06 ms
------
ping DeviceA2
PING DeviceA2.DomainA (192.168.178.3) 56(84) bytes of data.
64 bytes from DeviceA2.DomainA (192.168.178.3): icmp_seq=1 ttl=255 time=37.8 ms
- Seit Bookworm hat /etc/dhcpcd.conf scheinbar nicht mehr die bisherigen Auswirkungen
- die statische IP für wlan0 muss jetzt über nmtui eingestellt werden
- inwiefern metering ne rolle spielt hab ich noch nicht ganz durchblickt, (wlan0 und eth0 auf 100 setzen gab keine Änderung)
bisherige Änderungen:
/etc/dhcpcd.conf gelöscht
Code: Alles auswählen
sudo nmtui->Edit a connection->Wi-Fi>StuesDomainB>Edit
Profile name StuesDomainB
Device wlan0 (DC:11:11:11:11:82)
SSID StuesDomainB
Mode <Client>
Security <WPA & WPA2 Personal>
Password ***************
BSSID ________________________________________
Cloned MAC address
MTU __________ (default)
IPv4 CONFIGURATION <Manual>
Addresses 192.168.251.200/24
Gateway _________________________
DNS servers 192.168.251.200
Search domains <Add...>
Routing (No custom routes)
[ ] Never use this network for default route
[ ] Ignore automatically obtained routes
[ ] Ignore automatically obtained DNS parameters
[ ] Require IPv4 addressing for this connection
----------------------------------------------------------
Ethernet>Wired connection 1>Edit
Profile name Wired connection 1
Device eth0 (DC:A6:32:4F:AD:81)
═ ETHERNET
═ 802.1X SECURITY
╤ IPv4 CONFIGURATION <Automatic>
Addresses <Add...>
Gateway _________________________
DNS servers 192.168.178.1
Search domains <Add...>
Routing (No custom routes)
[ ] Never use this network for default route
[ ] Ignore automatically obtained routes
[ ] Ignore automatically obtained DNS parameters
[ ] Require IPv4 addressing for this connection
1. Warum fragt der RasPi nicht erst beim NS von DomainA "kennst du die IP von DeviceA1?" und bei negativer Antwort nochmal beim NS von DomainB?
2. Welche Dienste müssen angepasst werden? bind9, isc-dhcp, Netzwerkvorgaben per nmtui? (DNS und DHCP-Vergabe in den jeweiligen Netzen funzt ja wie gewünscht)