Hallo zusammen,
leider kam zu meiner Frage keine Antwort aus dem Forum, deshalb habe ich die “schnelle” anstelle der “eleganten” Lösung umgesetzt. Das Thema ist damit gelöst.
Da die Suchmaschinen zu “ucs also-notify” oder “ucs hidden primary” inzwischen diesen Post als ersten Treffer liefern, hier noch quick&dirty die Vorgehensweise für einen hidden Master erklärt, damit sich der nächste suchende etwas Zeit spart.
Das eigentliche Ziel meiner Frage war ja, einen UCS Bind als Hidden Primary für einige Zonen zu konfigurieren. Somit können auch extern erreichbare Domains wie “example.org” mit einem UCS-Server intern gepflegt werden, ohne diesen UCS-Server direkt aus dem Internet erreichbar und damit angreifbar machen zu müssen.
Mit der folgend vorgestellten Lösung ist es nur möglich, den UCS bind für alle eingerichteten Zonen als hidden primary zu konfigurieren, er wird die vorgeschalteten DNS-Server also immer und bei jeder Änderung an irgend einer der verwalteten Zonen benachrichtigen. Es hat sich herausgestellt das dies kein größeres Problem darstellt, da die vorgeschalteten DNS-Server leicht so konfiguriert werden können, den notify für nicht zuständige Zonen zu ignorieren, hier im Beispiel wäre dies z.B. example.lan. Im folgenden schildere ich auch nur die Arbeiten am Univention Server selbst, auf weitergehende Arbeiten wie Firewall, Absicherung des Transfers oder Arbeiten an den vorgeschalteten DNS-Servern wird nicht eingegangen.
Das Beispiel geht von der Domain example.org aus, für die ein hidden DNS Master eingerichtet werden soll. Die externen Nameserver sind ns1.provider.com. [IP: 1.2.3.4] sowie ns2.provider.com [IP: 2.3.4.5]. Die vorhandenen internen Univention Server bzw. Clients (Interne Domain ist example.lan, Netzwerk 192.168.1.0/24 sowie 192.168.3.0/25) sollen wie bisher den UCS DNS Server abfragen, also nicht umkonfiguriert werden müssen oder sonstig beeinträchtigt werden.
Da die externen DNS-Server den UCS Bind zwingend netzwerktechnisch erreichen müssen, sollte aus Sicherheitsgründen als erste Arbeit der Zugriff auf den DNS des UCS auf erlaubte IP-Adressen sowie das interne Netz beschränkt werden. Dies passiert auf dem Server selbst über die ucr Konfigurationsvariablen “dns/allow/query” sowie “dns/allow/transfer”. Dort kann entweder eine Liste der IP-Adressen/Netze eingetragen werden, oder eine ACL, die vorher in der Datei /etc/bind/named.conf konfiguriert wurde. Ich habe mich für die ACL entschieden, damit ist dem Beipiel angepasst folgende Konfiguration notwendig:
[code]Datei: “/etc/bind/local.conf”
add local zones here
// IP address(es) that are allowed to transfer (copy) the zone information from the server
// These adress(es) also allowed to query the DNS server
acl zone-transfer-hosts {
127.0.0.0/24; # localnet
192.168.1.0/24; # internal network
192.168.3.0/25; # internal network
1.2.3.4; # external nameserver ns1.provider.com
2.3.4.5; # external nameserver ns2.provider.com
};[/code]
[code]Datei: “/etc/bind/local.conf.proxy”
add local zones here
include “/etc/bind/local.conf”;
[/code]
Danach aktivieren Sie die soeben erstellte ACL, sowie vorübergehend auch ein debuging des DNS-Servers, mittels der Befehle:
~# ucr set dns/allow/query='zone-transfer-hosts'
~# ucr set dns/allow/transfer='zone-transfer-hosts'
~# ucr set dns/debug/level=2
~# service bind9 restart
Damit ist Abfrage sowie Zonentransfer des DNS-Servers nur noch von denen in der acl zone-transfer-hosts definierten Hosts aus möglich, ein nicht in dieser acl definierter Rechner wird ab sofort nicht mehr “bedient”. Die Protokollierung erfolgt in der Datei “/var/log/syslog”. Prüfen Sie die acl, indem Sie von einem nicht in den acl definierten Client eine DNS-Abfrage an den UCS DNS Server starten. Sie müssen ein " status: REFUSED", bzw. ein “Host … not found: 5(REFUSED)” als Antwort bekommen. Der UCS-Server protokolliert diese Anfrage mit einem “denied”. Prüfen Sie das. (In etwa folgende Zeilen der Datei “/var/log/syslog”, wichtig ist den Status “denied” zu bekommen)
Jan 4 13:24:20 ucsmaster named[13987]: client <external_IP>#43634: query 'ucsmaster.example.com/A/IN' denied
Jan 4 13:24:20 ucsmaster named[13987]: client <external_IP>#58235: query (cache) 'ucsmaster.example.com/A/IN' denied
Als nächstes konfigurieren Sie in der univention management console unter “Domäne --> DNS” die Zone “example.org”. Fügen Sie unter dem Punkt “Allgemein” die Namen der externen Nameserver ns1.provider.com und ns2.provider.com hinzu und speichern Sie ab. Die Änderungen werden quasi sofort übernommen. Sie können das auf der Kommandozeile durch Abfrage der Nameserver prüfen.
~# dig -t ns example.org @127.0.0.1
Die Ausgabe des Befehls sollte in etwa so aussehen:
[code]; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -t ns example.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27054
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;example.org. IN NS
;; ANSWER SECTION:
example.org. 10800 IN NS ns1.provider.com.
example.org. 10800 IN NS ns2.provider.com.
…schnipp…[/code]
Als nächstes konfigurieren Sie den Notfify an den oder die externen Nameserver. Momentan (UCS 4.0-0 errata17) ist das noch nicht direkt mit UCS-Mitteln möglich, ich werde dazu aber einen Bugreport schreiben, so dass dies in Zukunft hoffentlich ohne Modifikationen der Templates möglich sein wird. Editieren Sie die Datei “/etc/univention/templates/files/etc/bind/named.conf”. Ab Zeile 8 sieht diese Datei im Original so aus:
options {
directory "/var/cache/bind";
also-notify {
127.0.0.1;
};
@!@
val = 'none'
if configRegistry.is_true('dns/ipv6', True ):
Ändern Sie den Abschnitt des Templates wie folgt ab:
[code]options {
directory “/var/cache/bind”;
@!@
notify
notify=configRegistry.get(‘dns/notify’)
if notify:
print ‘\talso-notify { 127.0.0.1; %s; };’ % notify
else:
print ‘\talso-notify { 127.0.0.1; };’
ipv6
val = ‘none’
if configRegistry.is_true(‘dns/ipv6’, True ):[/code]
Konfigurieren Sie die zu benachrichtigenden Nameserver in der ucr Variable “dns/notify”:
~# ucr set dns/notify='1.2.3.4; 2.3.4.5'
~# ucr commit /etc/bind/named.conf
~# service bind9 restart
Bind wird ab sofort auch zusätzlich die externen Nameserver ns1.provider.com und ns2.provider.com benachrichtigen, wenn sich der Inhalt einer verwalteten Zone ändert, damit diese einen neuen Zonentransfer veranlassen. Somit können auch extern erreichbare Domains wie “example.org” mit einem UCS-Server gepflegt werden, ohne diesen UCS-Server direkt aus dem Internet erreichbar machen zu müssen. Den erfolgreichen notify sowie Transfer kann man aus der Logdatei /var/log/syslog ablesen: (Die letzten beiden Zeilen zeigen den erfolgreichen Transfer zum externen Server 1.2.3.4)
Jan 4 10:09:34 ucsmaster named[10917]: refresh_callback: zone example.org/IN: enter
Jan 4 10:09:34 ucsmaster named[10917]: refresh_callback: zone example.org/IN: serial: new 201501041560, old 201501041559
Jan 4 10:09:34 ucsmaster named[10917]: zone example.org/IN: sending notifies (serial 201501041560)
Jan 4 10:09:34 ucsmaster named[10917]: client 1.2.3.4#43913: transfer of 'example.org/IN': AXFR-style IXFR started
Jan 4 10:09:34 ucsmaster named[10917]: client 1.2.3.4#43913: transfer of 'example.org/IN': AXFR-style IXFR ended
Weiterhin lässt sich über eine “SOA” Abfrage prüfen, ob die geänderte Zone auf den externen Nameserver übertragen wurde. Im Erfolgsfall ist die Seriennummer der Zone gleich, egal ob intern oder extern abgefragt wird. Hier in diesem Fall ist alles in Ordnung, da in allen Fällen die Seriennummer “201501041560” gleich ist:
~# ## externe Sichtweise:
~# host -4 -C -t soa example.org.
Nameserver 1.2.3.4:
example.org has SOA record ns1.provider.com. dnsadmin.provider.com. 201501041560 43200 7200 2592000 10800
Nameserver 2.3.4.5:
example.org has SOA record ns1.provider.com. dnsadmin.provider.com. 201501041560 43200 7200 2592000 10800
~# ## interne Sichtweise:
~# host -4 -t soa example.org. 127.0.0.1
example.org has SOA record ns1.provider.com. dnsadmin.provider.com. 201501041560 43200 7200 2592000 10800
Beachten Sie bei Ihren Tests bitte, dass Änderungen an den Zonen nicht in Echtzeit übertragen werden können: Besonders stark ausgelastete DNS-Server versuchen in der Regel mehrere notify Anfragen über einen kleinen Zeitraum zu sammeln, es kann also typischerweise 30 Sekunden bis 3 Minuten dauern, bis Sie die Änderung der Seriennummer auch vom externen Nameserver übernommen wurde. Sollte es jedoch länger als 5 Minuten dauern und Sie in dieser Zeit keinen Logdateieintrag “client 1.2.3.4#43913: transfer of ‘example.org/IN’: AXFR-style IXFR started” finden, so kontaktieren Sie den Betreiber der externen Nameserver, mit dem Verdacht des ignorierens der notify Meldungen bzw. prüfen Sie Ihre Firewall.
Ein anderer typischer Fehler: Wenn neue oder geänderte DNS-Einträge erst nach mehreren Stunden, in etwa identisch zum eingestellten Aktualisierungsintervall der jeweiligen Zone, auf die externen Nameserver übertragen werden: Auch in diesem Fall funktioniert der notify-Mechanismus nicht, und der externe Nameserver bemerkt Änderungen an der Zone nur durch das Ablaufen des maximalen Aktualisierungsintervalls.
Wenn alles wie gewünscht funktioniert, bevor Sie Sich entspannt zurücklehnen und Ihren Feierabendtee geniesen, setzen Sie als letzte Arbeit den Debuglevel des Bind zurück:
~# ucr set dns/debug/level=0
~# service bind9 restart
