Ich habe einen Multi-Homed-Server „dhcp1“ mit den Netzwerkschnittstellen „192.168.10.151“ (eth0) und „192.168.0.151“ (eth1). Die Maschine versucht, DDNS mit einem Nameserver „ns1“ mit den Netzwerkschnittstellen „192.168.10.131“ (eth0) und „192.168.0.131“ (eth1) zu verwenden. Hoffentlich sind dies die relevanten Abschnitte meiner dhcpd.conf:
ddns-update-style interim;
key DHCP_UPDATER {
algorithm HMAC-MD5;
secret "A6...==";
};
# The 'private' network.
subnet 192.168.10.0 netmask 255.255.255.0 {
zone example.com. {
primary 192.168.10.131;
key DHCP_UPDATER;
}
zone 10.168.192.in-addr.arpa. {
primary 192.168.10.131;
key DHCP_UPDATER;
}
ddns-domainname "example.com.";
ddns-rev-domainname "in-addr.arpa.";
option domain-name "example.com";
host client-private {
hardware ethernet ...;
fixed-address 192.168.10.13;
}
...
}
# The 'public' network.
subnet 192.168.0.0 netmask 255.255.255.0 {
zone example.com. {
primary 192.168.0.131;
key DHCP_UPDATER;
}
zone 0.168.192.in-addr.arpa. {
primary 192.168.0.131;
key DHCP_UPDATER;
}
ddns-domainname "example.com.";
ddns-rev-domainname "in-addr.arpa.";
option domain-name "example.com";
host client-public {
hardware ethernet ...;
fixed-address 192.168.0.13;
}
...
}
Der „ns1“-Server führt zwei Instanzen von „named“ aus – eine lauscht auf den Loopback- und privaten Netzwerkschnittstellen, während die andere Instanz auf der öffentlichen Schnittstelle lauscht.
Das Starten der ersten Instanz ergibt:
May 10 01:24:32 ns1 named[6610]: starting BIND 9.8.1-P1 -u bind
May 10 01:24:32 ns1 named[6610]: built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-geoip=/usr' '--enable-ipv6' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro' 'CPPFLAGS=-D_FORTIFY_SOURCE=2'
May 10 01:24:32 ns1 named[6610]: adjusted limit on open files from 4096 to 1048576
May 10 01:24:32 ns1 named[6610]: found 2 CPUs, using 2 worker threads
May 10 01:24:32 ns1 named[6610]: using up to 4096 sockets
May 10 01:24:32 ns1 named[6610]: loading configuration from '/etc/bind/named.conf'
May 10 01:24:32 ns1 named[6610]: reading built-in trusted keys from file '/etc/bind/bind.keys'
May 10 01:24:32 ns1 named[6610]: using default UDP/IPv4 port range: [1024, 65535]
May 10 01:24:32 ns1 named[6610]: using default UDP/IPv6 port range: [1024, 65535]
May 10 01:24:32 ns1 named[6610]: listening on IPv4 interface lo, 127.0.0.1#53
May 10 01:24:32 ns1 named[6610]: listening on IPv4 interface eth0, 192.168.10.131#53
May 10 01:24:32 ns1 named[6610]: generating session key for dynamic DNS
May 10 01:24:32 ns1 named[6610]: sizing zone task pool based on 7 zones
May 10 01:24:32 ns1 named[6610]: set up managed keys zone for view _default, file 'managed-keys.bind'
May 10 01:24:32 ns1 named[6610]: Warning: 'empty-zones-enable/disable-empty-zone' not set: disabling RFC 1918 empty zones
May 10 01:24:32 ns1 named[6610]: automatic empty zone: 254.169.IN-ADDR.ARPA
May 10 01:24:32 ns1 named[6610]: automatic empty zone: 2.0.192.IN-ADDR.ARPA
May 10 01:24:32 ns1 named[6610]: automatic empty zone: 100.51.198.IN-ADDR.ARPA
May 10 01:24:32 ns1 named[6610]: automatic empty zone: 113.0.203.IN-ADDR.ARPA
May 10 01:24:32 ns1 named[6610]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
May 10 01:24:32 ns1 named[6610]: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
May 10 01:24:32 ns1 named[6610]: automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
May 10 01:24:32 ns1 named[6610]: automatic empty zone: D.F.IP6.ARPA
May 10 01:24:32 ns1 named[6610]: automatic empty zone: 8.E.F.IP6.ARPA
May 10 01:24:32 ns1 named[6610]: automatic empty zone: 9.E.F.IP6.ARPA
May 10 01:24:32 ns1 named[6610]: automatic empty zone: A.E.F.IP6.ARPA
May 10 01:24:32 ns1 named[6610]: automatic empty zone: B.E.F.IP6.ARPA
May 10 01:24:32 ns1 named[6610]: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA
May 10 01:24:32 ns1 named[6610]: command channel listening on 127.0.0.1#953
May 10 01:24:32 ns1 named[6610]: couldn't add command channel ::1#953: address not available
May 10 01:24:32 ns1 named[6610]: zone 0.in-addr.arpa/IN: loaded serial 1
May 10 01:24:32 ns1 named[6610]: zone 127.in-addr.arpa/IN: loaded serial 1
May 10 01:24:32 ns1 named[6610]: zone 10.168.192.in-addr.arpa/IN: loaded serial 2013092337
May 10 01:24:32 ns1 named[6610]: zone 255.in-addr.arpa/IN: loaded serial 1
May 10 01:24:32 ns1 named[6610]: zone localhost/IN: loaded serial 2
May 10 01:24:32 ns1 named[6610]: zone example.com/IN: loaded serial 2013092554
May 10 01:24:32 ns1 named[6610]: managed-keys-zone ./IN: loaded serial 59
May 10 01:24:32 ns1 named[6610]: zone example.com/IN: sending notifies (serial 2013092554)
May 10 01:24:32 ns1 named[6610]: zone 10.168.192.in-addr.arpa/IN: sending notifies (serial 2013092337)
May 10 01:24:32 ns1 named[6610]: running
Das Starten der zweiten Instanz ergibt:
May 10 01:24:54 ns1 named[6635]: starting BIND 9.8.1-P1 -u bind -c /etc/bind/named-1.conf
May 10 01:24:54 ns1 named[6635]: built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-geoip=/usr' '--enable-ipv6' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro' 'CPPFLAGS=-D_FORTIFY_SOURCE=2'
May 10 01:24:54 ns1 named[6635]: adjusted limit on open files from 4096 to 1048576
May 10 01:24:54 ns1 named[6635]: found 2 CPUs, using 2 worker threads
May 10 01:24:54 ns1 named[6635]: using up to 4096 sockets
May 10 01:24:54 ns1 named[6635]: loading configuration from '/etc/bind/named-1.conf'
May 10 01:24:54 ns1 named[6635]: reading built-in trusted keys from file '/etc/bind/bind.keys'
May 10 01:24:54 ns1 named[6635]: using default UDP/IPv4 port range: [1024, 65535]
May 10 01:24:54 ns1 named[6635]: using default UDP/IPv6 port range: [1024, 65535]
May 10 01:24:54 ns1 named[6635]: listening on IPv4 interface eth1, 192.168.0.131#53
May 10 01:24:54 ns1 named[6635]: generating session key for dynamic DNS
May 10 01:24:54 ns1 named[6635]: sizing zone task pool based on 7 zones
May 10 01:24:54 ns1 named[6635]: set up managed keys zone for view _default, file 'managed-keys.bind'
May 10 01:24:54 ns1 named[6635]: Warning: 'empty-zones-enable/disable-empty-zone' not set: disabling RFC 1918 empty zones
May 10 01:24:54 ns1 named[6635]: automatic empty zone: 254.169.IN-ADDR.ARPA
May 10 01:24:54 ns1 named[6635]: automatic empty zone: 2.0.192.IN-ADDR.ARPA
May 10 01:24:54 ns1 named[6635]: automatic empty zone: 100.51.198.IN-ADDR.ARPA
May 10 01:24:54 ns1 named[6635]: automatic empty zone: 113.0.203.IN-ADDR.ARPA
May 10 01:24:54 ns1 named[6635]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
May 10 01:24:54 ns1 named[6635]: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
May 10 01:24:54 ns1 named[6635]: automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
May 10 01:24:54 ns1 named[6635]: automatic empty zone: D.F.IP6.ARPA
May 10 01:24:54 ns1 named[6635]: automatic empty zone: 8.E.F.IP6.ARPA
May 10 01:24:54 ns1 named[6635]: automatic empty zone: 9.E.F.IP6.ARPA
May 10 01:24:54 ns1 named[6635]: automatic empty zone: A.E.F.IP6.ARPA
May 10 01:24:54 ns1 named[6635]: automatic empty zone: B.E.F.IP6.ARPA
May 10 01:24:54 ns1 named[6635]: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA
May 10 01:24:54 ns1 named[6635]: command channel listening on 192.168.0.131#953
May 10 01:24:54 ns1 named[6635]: zone 0.in-addr.arpa/IN: loaded serial 1
May 10 01:24:54 ns1 named[6635]: zone 127.in-addr.arpa/IN: loaded serial 1
May 10 01:24:54 ns1 named[6635]: zone 0.168.192.in-addr.arpa/IN: loaded serial 2013092346
May 10 01:24:54 ns1 named[6635]: zone 255.in-addr.arpa/IN: loaded serial 1
May 10 01:24:54 ns1 named[6635]: zone localhost/IN: loaded serial 2
May 10 01:24:54 ns1 named[6635]: zone example.com/IN: loaded serial 2013092573
May 10 01:24:54 ns1 named[6635]: managed-keys-zone ./IN: loaded serial 59
May 10 01:24:54 ns1 named[6635]: zone example.com/IN: sending notifies (serial 2013092573)
May 10 01:24:54 ns1 named[6635]: zone 0.168.192.in-addr.arpa/IN: sending notifies (serial 2013092346)
May 10 01:24:54 ns1 named[6635]: running
Alle Maschinen sind virtuell und verwenden Ubuntu Server 12.04.
Das Problem
Ich gehe davon aus, dass „dhcp1“ „ns1“ auf der entsprechenden privaten Schnittstelle (also „192.168.10.131“) aktualisiert, wenn der Client eine IP-Adresse im privaten Netzwerk anfordert. Ich erwarte auch, dass „dhcp1“ „ns1“ auf der öffentlichen Schnittstelle „192.168.0.131“ aktualisiert, wenn der Client eine IP-Adresse in diesem Netzwerk anfordert. Obwohl die Reverse-Zone-Updates auf den jeweiligen Schnittstellen erfolgen, initiiert „dhcp1“ immer die Forward-Zone-Updates beider Netzwerke auf der öffentlichen Schnittstelle des Nameservers (also „192.168.0.131“).
Mache ich etwas falsch, ist das ein Fehler im isc-dhcp-server, eine Funktion usw.? Wenn ich nicht genügend spezifische Informationen bereitgestellt habe, lassen Sie es mich bitte wissen. Websuchen nach einem Multi-Homed-Ansatz mit isc-dhcp-server und bind9 haben mir nicht viel gebracht.
Wir sind für alle Informationen dankbar, die Sie uns geben können. Vielen Dank.
Antwort1
Es scheint, dass Zonen innerhalb der Konfiguration eindeutig sein müssen.
Ich konnte dies nicht in den dhcpd.confManpages finden, aber das Durchsuchen des Codes und Herumspielen mit der Konfiguration gibt einen Eindruck von der Serverimplementierung:
- Der „dhcpd“-Analysecode erreicht die erste „example.com.“-Zone im Subnetz „192.168.10.0“ von „dhcpd.conf“ und fügt die Informationen (einschließlich des primären Nameservers) einer Hash-Map hinzu, wobei der Zonenname als Schlüssel verwendet wird.
- Später erreicht die Analyse die zweite „example.com.“-Zone im
192.168.0.0Subnetz. An diesem Punkt werden die vorhandenen „example.com.“-Hashmap-Zonendaten durch die neuen Informationen ersetzt, einschließlich des primären Nameservers. Da die Reverse-Zonen eindeutig sind, wird jede zur Map hinzugefügt. - Sobald der DHCP-Server die Weiterleitungszoneninformationen für eines der Subnetze aktualisieren muss, werden die Aktualisierungen an den primären Nameserver des zuletzt analysierten Subnetzes gesendet, in diesem Fall an den DNS-Server
192.168.0.131.
Das Neuordnen der Subnetzinformationen in der Konfigurationsdatei scheint dies zu bestätigen, da alle Forward-Zone-Updates dann an gesendet wurden 192.168.10.131. Daher erfordert mein Setup möglicherweise einen separaten dhcpdDaemon für jede Schnittstelle, wie ich es für getan habe named. Ich bin immer noch neugierig, ob dieser Multi-Homed-Ansatz für Hochverfügbarkeitsnetzwerke üblich ist und ob ich ihn richtig angehe. Auch wenn meine Frage beantwortet zu sein scheint, ist jeder Rat willkommen.