Funktioniert so Hidden Primary? (Verständnisfrage)

greystone

greystone

Active Member
Hallo,

ich habe mal die Frage, ob mein Verständnis bzgl. DNS und Hidden Primary korrekt ist:

Szenario:

Ich habe einen primären DNS-Server(Plesk), den ich aus Stabilitätsgründen nicht für externe Namensauflösung verwenden möchte, aber auch nicht einfach ersetzen kann. Deswegen möchte ich den Plesk-Server als Hidden Primary Setup einsetzen, damit ein Ausfall dessen, die Namensauflösung nicht beeinträchtigt. Weiterhin auch, wenn man den mal Upgraden möchte, dass ein zeitweiser Ausfall problemlos möglich ist.

Geplante Server / Bind9 - Komponenten
  • server-a1 primärer DNS-Server(Plesk)
  • server-b1 Docker Bind 9 Secondary DNS - dedizierte VM - wird normalerweise nie rebooted
  • server-b2 Docker Bind 9 Secondary DNS - läuft auf einem dedicated server mit, wird vielleicht ab und an mal rebooted
  • server-b3 Docker Bind 9 Secondary DNS - läuft auf einem (anderen) dedicated server mit, wird vielleicht ab und an mal rebooted
Mein Verständnis der Situation
  • server-b1 ist der nach außen sichtbare erste DNS-Server
  • Als DNS-Server für alle Domains werden beim Registrar server-b1,server-b2,server-b3 konfiguriert.
  • server-a1 tritt nach aussen nicht in Erscheinung und bedient keinerlei DNS-Anfragen. Jegliche öffentliche eingehende Anfrage(Port 53/tcp+udp) kann also per Paketfilter unterbunden werden.
  • server-b1 kann problemlos als MNAME im SOA-Record aller Domains eingetragen werden, da kein DDNS zum Einsatz kommt.
  • server-b1,server-b2,server-b3 sind als DNS-Server in allen Domains per NS-Record eingetragen
  • Fällt der primäre DNS-Server(Plesk) nur kurz aus, dann läuft die DNS-Auflösung der Secondary Server weiter
  • Fällt der primäre DNS-Server(Plesk) länger als Zeit X aus, dann hört die DNS-Auflösung auf zu funktionieren, wobei X der Expire Wert aus dem SOA-Record ist.
  • Der primäre DNS-Server(Plesk) sollte deswegen also überwacht werden und Störungen sollten umgehend behoben werden. Ein gängiger Standwardwert für X ist 1 Woche. Die Empfehlung von der RIPE NCC für kleine/stabile Zonen ist 1000 Stunden => ~41 Tage, was hier durchaus vorteilhaft ist.
Danke für Rückmeldung dazu, ob ich das alles korrekt verstanden habe.
Weitere Frage: Hat ein hoher Expire-Wert auch Nachteile?
 
Last edited:
Grundsätzlich ja, ein paar Punkte sind allerdings zu korrigieren.

Du solltest dir Gedanken darüber machen, wie die Zonen Daten vom Hidden Primary zu den Public Primary kommen. Die Lehrbuch Variante ist AXFR/IXFR. Dies setzt allerdings voraus, dass dein Hidden Primary zumindest mal DNS Traffic von deinen Public Primarys annimmt. Denn irgendwie muss er die AXFR Anfragen ja beantworten. Port muss an der Stelle nicht zwingend TCP/UDP 53 sein, könnte man variieren, wenn man möchte. Wenn aber eh eine IP Whitelist davor liegt, kann man es auch beim Standard-Port belassen.
Fällt in diesem Szenario der Hidden Primary aus, cachen die Public Primarys die Zonen Daten so lang wie eingestellt. Wenn du willst, auch mehrere Wochen. Nach Ablauf dieser Zeit werden sie die Zonen Daten verwerfen und entsprechend nicht mehr antworten.

Die Alternative ist eine DNS unabhängige Übermittlung der Zonen Daten. Jede Instanz kennt nur sich selbst und denkt sie wäre eine Standalone-Umgebung. Ich weiß gerade nicht was Plesk als Nameserver nutzt, aber wenn da auch Bind dahinter steckt, könnte man die Zone Files auch per rsync an die Public Primarys übertragen.
Kommt etwas moderneres als ein bind zum Einsatz, bspw. ein PowerDNS mit SQL Backend könnte man auch auf entsprechende Replikationsmethoden im MySQL/Postgres setzen.
In beiden Fällen wäre die Dauer eines Ausfalls des Hidden Primarys völlig unerheblich. Theoretisch könntest du den dann auch nur einschalten, wenn es Änderungen an den Zonen gibt. ;)

Edit:
Viele Hoster nehmen immer mehr Abstand von AXFR innerhalb ihrer eigenen Umgebungen und bieten das ihren Kunden nur noch für Fremdumgebungen an. Da hängen im Hosting-Betrieb einfach mehr Nachteile dran, als wenn man die Rohdaten (Zonen Dateien von bind, oder SQL Repli) verteilt.
AXFR ist daher eher zum Notnagel geworden, wenn man Zonen Transfers braucht, ohne beide Seiten des Transfers unter eigener Kontrolle zu haben.

Auch ein Blick auf dnsdist (DNS Loadbalancer) könnte ein Blick wert sein, der hat an der Stelle ein paar wunderschöne Logik-Optionen für Balancing, ACLs, Throttling, etc.
 
Zonenänderungen laufen bei Plesk über RDNS. Ob die initiale Provisionierung auch so läuft, weiß ich noch nicht. Aus der Dokumentation ersehe ich das auch nicht. Ich sehe auch keinen Zonenfiles auf dem primären DNS-Server rumliegen. Aktuell habe ich da noch keinen Zugang, zum Plesk-Admin-Webinterface. Meinen eigenen DNS-Server habe ich auch mit nativer MySQL-Replikation unter PowerDNS am laufen, aber das gewünschte Setup ist hier anders.
 
Last edited:
greystone said:
Zonenänderungen laufen bei Plesk über RDNS.
Click to expand...

Öhm, ich bin eigentlich der Meinung ich kenne die meisten Abkürzungen im Bereich DNS und "RDNS" steht üblicherweise für "Reverse DNS" und damit sind PTR Records gemeint. Damit bekommst du weder Zoneninhalte geändert, noch auf einen anderen Nameserver übertragen.

Man möge mich bitte aufschlauen, falls es irgendeine derartige Logik unter gleichem Kürzel im DNS Standard geben sollte. Aber ich befürchte hier liegt irgendwo ein Denkfehler vor. ;)
 
Meines Wissens nutzt Bind9 AXFR und IXFR für den Zonentransfer (voll bzw. inkrementell) - der rndc ist ja nur das Steuerungstool, um beim Bind bestimmte Aktioenn anzustossen. Per rndc wird also ein neuer Eintrag in die Zone auf dem Primary geschrieben und von da aus dann i.d.R. ohne zusätzliche Eingriffe der Zonentransfer angestossen. Man kann mit rndc auch den Transfer manuell anstossen, aber den eigentlichen Transfer macht danach der Bind.
 
Das mit der Synchronisation ist mir gerade ziemlich egal. Das kriege ich dann schon irgendwie hin, bzw. Ich teste dass einfach erst mal aus, wenn ich den Zugriff dann habe. Wenn ich da nicht weiter komme, würde ich mich dann separat noch mal melden.

Viel wichtiger ist für mich die Info, ob das, was ich oben geschrieben habe, tatsächlich so zutrifft. Falls also jemand zu meinem ursprünglichen Anliegen sich noch äußern mag, wäre das eine große Hilfe für mich.
 
Firewire2002 said:
Grundsätzlich ja, ein paar Punkte sind allerdings zu korrigieren.
Click to expand...

Was willst du denn noch?

greystone said:
Weitere Frage: Hat ein hoher Expire-Wert auch Nachteile?
Click to expand...

Ich habe dir erklärt wie die unterschiedlichen Techniken zur Übertragung der Zonendaten sich auswirken. Entsprechend spielt der Expire-Wert im SOA eine große oder gar keine Rolle. Da du dich nicht auf eine Technik festlegen willst, kann man auch nichts konkreteres sagen, als da oben steht.

Oder soll ich nun die Erklärung aus Wikipedia dazu zitieren? ;)

Letztendlich muss der Expire so groß sein, wie du Ausfällzeiten deines Hidden-Primarys erwartest. Fällt er länger aus, ist alles offline. Fertig.
Ein zu hoher Wert führt einzig dazu, dass du potentiell Datenmüll ansammelst, weil er auch Zonen die schon gar nicht mehr existieren, nicht verwirft. Aber auch dies hängt nun wieder davon ab, wie man dem Slave die Slave-Zonen überhaupt bekannt macht. Auch zum Aufräumen gibt es natürlich vielfältige Möglichkeiten, als sich nur auf den Expire zu verlassen.
 
Den Wikipedia-Artikel habe ich natürlich selbst schon gelesen.

Meine Unsicherheit besteht noch darin, dass ich nicht weiss, ob da von Registrarseite noch irgendwelche Bedingungen erfüllt werden müssen. Dass der DNS auf irgendwelche Requests von außen antworten können muss, was vielleicht nur der primäre Server kann.

Ich weiss auch nicht genau was der MNAME im SOA-Record evtl. noch für Auswirkungen hat. In der passenden RFC habe ich dazu auch nix mehr erfahren.

Insgesamt ist da der Wunsch, das zu verstehen, um nicht letztlich durch Unwissen zu verursachen, dass auf einmal die DNS-Auflösung nicht mehr funktioniert. Vor allem wenn ich so etwas nicht ganz 0815-mässiges wie Hidden-Primary aufsetze. Aktuell sieht es für mich aber so aus, dass es da keine weiteren Dinge mehr zu beachten sind.

---

Was das Nebenthema Datenreplikation betrifft, dass wird, wie hier schon geschrieben vermutlich per AXFR/IXFR passieren, weil's halt der Default von BIND ist. Da das ganze eine eher übersichtliche Zahl an Domains betrifft und eine geringe Änderungshäufigkeit, sehe ich dabei auch kein Problem.
 
Mir wäre kein Registrar bekannt, der irgendwelche Wünsche an deinen Zoneninhalt bzw. konkret an den SOA stellt.
Viele haben die Anforderung, dass du mindestens 2 Nameserver bei denen hinterlegen musst, die bei einigen Registraren auch nicht im gleichen /24 stehen dürfen. Aber ansonsten bist du da völlig frei, was du mit deinen Nameservern veranstaltest.

Ich habe die letzten Monate die Authoritativen Nameserver eines großen deutschen Hosting Unternehmens neugebaut. Hidden-Primary Cluster + Public Instanzen an 3 Standorten mit Loadbalancern und horizontaler Skalierungsmöglichkeit.
Wie die meisten Admins rennt man an der Stelle gegen Wände bei der Geschäftsführung, weil es natürlich ein so ultimativ wichtiger Service ist, dass der 100% Erreichbarkeit aufweisen muss. Jeder Admin weiß: unmöglich und jede 9 mehr hinter dem Komma der 99,9% Verfügbarkeit treibt die Kosten drastisch in die Höhe.

Das DNS Konstrukt an sich ist völlig banal an der Stelle. Viel Interessanter ist die Betrachtung vor welchen Einflüssen willst du dich absichern und was bist du bereit an Budget da zu investieren.
 
Ich habe es jetzt mit einem normalen bind secondary gemacht als docker der auf zwei dedizierten Servern mitläuft und per AXFR/IXFR die Updates überträgt. Bei der geringen Menge an Domains ist das akzeptabel. Plesk-seitig läuft das mit dem Plugin Slave-DNS-Manager.

docker-compose.yml
Code: 
version: "3.0"

services:
  ns2_bind:
    image: internetsystemsconsortium/bind9:9.18
    container_name: ns2_bind
    restart: always
    networks:
      - default
    ports:
      - "53:53/udp"
# 53/tcp braucht man für Pakete, die nicht in die max. UDP-Paketgröße(512 Bytes) passen.
      - "53:53/tcp"
      - "953:953/tcp"
    volumes:
      - ./data/etc:/etc/bind
      - ./data/cache:/var/cache/bind
      - ./data/lib:/var/lib/bind
      - ./data/log:/var/log

named.conf
Code: 
options {
        directory "/var/cache/bind";
        listen-on { any; }; /* hier war die Vorgabe 0.0.0.0/0, was nicht funktioniert hat. */
        listen-on-v6 { ::1; };
        allow-recursion { none; };
        allow-transfer  { none; };
        allow-update    { none; };
        allow-new-zones yes;
};

key "rndc-key" {
  algorithm hmac-md5;
  secret "abcdefghijklmn==";
  /* Das ist der Key mir das Plesk Slave-DNS-Manager Plugin erzeugt hat. */
};

controls {
    inet * port 953 allow { 1.2.3.4; 127.0.0.1; } keys { "rndc-key"; };
    /* 1.2.3.4 ist der Master-DNS-Server, der hier per rndc zugreift */
};

Vor den Port 953/tcp kam noch eine Firewallregel davor, dass auch auf Netzwerkebene nur der Master dort darf.
Die Docker-Container werden per Monitoring überwacht. Zusätzlich gab's noch ein dediziertes Monitoring-Plugin,
dass mir den DNS-Service testet...

bind_ns2_docker
Code: 
#!/bin/bash
#
# Check_MK local check for local bind secondary server within docker
#
export LC_ALL=C
export PATH=/bin:/usr/bin:/usr/local/bin
export TEST_DOMAIN=meinetestdomain.de
STATUS=0
STATUS_TEXT="Alles OK"
CONTAINER=ns2_bind

if docker exec $CONTAINER rndc status 2>&1 | grep -q "server is up and running"; then
        BIND_RUNNING=1
else
        BIND_RUNNING=0
        STATUS=1
        STATUS_TEXT="bind server not up(!) "
fi

RES=$(dig +short "$TEST_DOMAIN" @localhost 2>/dev/null)

if [ -z "$RES" ] ; then
        STATUS=1
        STATUS_TEXT="${STATUS_TEXT}ns query for $TEST_DOMAIN not successful(!) "
fi

echo $STATUS bind_ns2_docker - "$STATUS_TEXT"

...und damit war es das, für den Preis, was der Kunde bereit ist zu zahlen.

EDIT-1 53/tcp ins docker-compose.yml nachgetragen.
 
Last edited:
TCP/53 würde ich lieber nicht abschalten. DNS Antworten die zu groß sind für ein einzelnes DNS UDP Paket (512 Byte) bekommen einen Redirect auf TCP. Vorallem bei TXT Records ist das schnell mal erreicht. ;)
 
Da noch nicht erwähnt würde ich vorschlagen, Notify auf den beteiligten Servern einzusetzen.
Ohne fragen die sekundären Server zyklisch nach Ablauf der Refresh-Zeit den Master an, vergleichen die Serial im SOA-Record und leiten eine Zonenübertragung ein, wenn diese unterschiedlich ist. Mit Notify wird bei jeder Änderung der Zone am Master ein Paket an die Slaves geschickt, welche dann sofort (binnen Sekunden) ihre lokale Kopie aktualisieren. So kann man die Propagation von Zonenänderungen beschleunigen und inkonsistente Antworten der einzelnen Server vermeiden.

Mir wäre kein Registrar bekannt, der irgendwelche Wünsche an deinen Zoneninhalt bzw. konkret an den SOA stellt.
Click to expand...
Die DENIC macht einen sogenannten Predelegation-Check, bei dem geprüft wird, ob die Zone auf den Namservern vorhanden und inhaltlich stimmig ist. Soweit ich die Dokumentation verstehe, werden om SOA-Record aber nur die TTLs eingehend geprüft.
 
You must log in or register to reply here.
Back
Top