DNS: Konfiguration Notify Mechanismus (bind, also-notify)

Hallo zusammen,

Frage zum Einbau von “also-notify” in einen UCS Bind-Server.

Der UCS Bind soll als Hidden Primary für einige Zonen konfiguriert werden.
Damit das bei einem “Wald-Wiese Bind-Server” gut funktioniert muss folgendes erfüllt sein:

1.) externe NS müssen für den Transfer frei geschaltet werden (allow-transfer)
2.) externe NS müssen bei Änderungen an der Zone benachrichtigt werden (also-notify)

Eine klassische Konfiguration für die Domäne example.com sieht damit sinngemäß in etwa so aus:

zone "example.com" IN { type master; file "example.com"; notify yes; allow-transfer { external-nameservers; }; also-notify { external-nameservers; }; };

Punkt 1, also das erlauben von Zonentransfers kann mit UCS Mitteln abgebildet werden, da ist mir nur die Syntax nicht ganz klar. Im Wiki habe ich dazu eine zweite und imho bessere Möglichkeit in der Kategorie Cool Solutions gefunden, die jedoch nur im Zusammenspiel mit Samba funktioniert, und damit bei uns leider wegfällt. Aber Egal, Punkt 1 ist gelöst, da existieren mindestens zwei funktionierende Ansätze.

Punkt 2, die Integration des “also-notify” Mechanismus macht mir Kopfzerbrechen, ich habe keine dokumentierte Möglichkeit gefunden wie so etwas nativ mit UCS funktionieren kann. Daher der Gedanke: Mach es selbst. Wenn es gut funktioniert dann reiche es bei Univention als Verbesserungsvorschlag für die nächste Version ein. Dafür brauche ich etwas Starthilfe, deshalb dieses Posting mit einigen Gedanken dazu.

Die Zonendateien selbst liegen ja im ldap, die zum Beispiel oben passende Konfigurationsdatei für den Bind müsste also auf einem UCS Server unter /etc/bind/univention.conf.d/example.com liegen und wie folgt aussehen, damit ein also-notify Mechanismus funktionieren kann: (Nur eine eingefügte Zeile mehr, optimalerweise abhängig von der jeweiligen Zone)

zone "example.com" { type master; notify yes; also-notify { external-nameservers; }; database "ldap ldap://127.0.0.1:7389/zoneName=example.com,cn=dns,dc=...usw..."; };

Meine Fragen:
Gibt es bereits eine Möglichkeit, nativ so etwas (ähnliches) mit UCS zu erreichen? Wenn ja dann kann ich mir weiteres Kopfzerbrechen sparen.
Wenn Nein: Gibt es ein prinzipielles Interesse für eine Lösung “DNS Hidden Primary” mit UCS-Mitteln? Als “Cool Solution” könnte ich mir so etwas bspw. gut vorstellen.
Wenn auch hier Nein: Dann baue ich mir das selbst und verzichte zugunsten einer schnellen auf eine elegante Lösung.

Wenn Ja auf eine der Fragen: Ich freue mich auf Eure/Ihre Rückmeldung.
Lutz Willek

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

Zur Sicherheit: Im ersten Post ist ein Syntax-Fehler im gebrachten Beispiel, ich konnte den Post jedoch nicht mehr editieren…

[quote=“lutz.willek”]…
Eine klassische Konfiguration für die Domäne example.com sieht damit sinngemäß in etwa so aus:

zone "example.com" IN { type master; file "example.com"; notify yes; allow-transfer { external-nameservers; }; also-notify { external-nameservers; }; };
[/quote]

Richtig ist: Bind erwartet im Eintrag “also-notify” immer eine Liste von IP-Adresse(n) und akzeptiert keine ACL.

Falsch, wie im Ursprungspost dargestellt:

 also-notify { external-nameservers; }; 

Richtig:

 also-notify { 127.0.0.1; 192.168.0.5; 1.2.3.4; 2.3.4.5; }; 

Mit freundlichen Grüßen
Lutz Willek

Hallo zusammen,

Wie versprochen wurde der Bugreport unter forge.univention.org/bugzilla/s … i?id=37425 erstellt.

Sollte das vorgestellt Setup für Sie prinzipiell spannend sein, so fügen Sie sich bitte per cc dem Bugreport hinzu, oder voten Sie für diesen Bugreport.
Damit kann Univention auch besser einschätzen wie viele Benutzer bzw. Setups potentiell Interesse an dieser Lösung haben. Der Vorteil: Sie können so die im Posting vorgestellte Konfiguration in Zukunft ohne Änderungen an Templates nachbauen.

Mit freundlichen Grüßen
Lutz Willek

Hallo,

vielen Dank für die Ausführliche Beschreibung Ihrer Lösung!
Ich würde, ohne das jetzt im Detail geprüft zu haben, sagen, dass das sowohl die “schnelle” als auch die “elegante” Lösug für das Problem ist da “also-notify” aktuell nicht per UCR vorgegeben werden kann.

Mit freundlichen Grüßen
Janis Meybohm

Mastodon