Ich hatte in den letzten Tagen eine recht umfangreiche DNS Server Übernahme.
DNSServerAlt1 = ns1.servername.domain.tld
DNSServerAlt2 = ns1.servername.domain.tld
zu
DNSServerNeu1 = ns1.servername.domain.tld
DNSServerNeu2 = ns2.servername.domain.tld
Alles klar, ISPConfig3 (kein Master/Slave oder Cluster Setup) auf den 2 neuen Kisten eingerichtet, User-Accounts erstellt die alte Domain aus der /etc/bind/pri.domain.tld ge"cat"tet und ins Apple Text eingefügt (RTF).
Die 2 Maschinen sollen vollständig autonom laufen, sie dienen nur für eine einzige Hauptdomain als DNS Server, zwischen den Kisten findet kein Sync statt und aus Sicherheitsgründen haben sämtliche Useraccounts (linuxuser/ispconfig admin etc.) unterschiedliche Passwörter. SSH läuft nur per Cert-Auth.
Wenn ich also DNS Einträge ändere, muss ich dies auf den 2 Maschinen separat tätigen, was aber kein Problem darstellt.
Ich habe also per "Safari" Browser die TXT mit den 150 Einträge per Interface: DNS -> Zonen Datei Import versucht hochzuladen,
Server 1 listete nur 2 Seiten mit Inhalt auf
Server 2 hingegen 8 Seiten
ich dachte nur: "kann doch nicht sein"
nach etlichem herumspielen hab ich es geschnallt:
das File muss als "reine TxT" hochgeladen werden
Ok, DNS Server laufen, kurz die wichtigsten Einträge überflogen ... passt soweit ... bei der Eurid bescheid gegeben doch bitte mal die Glue Records für die 2 neuen IPv4/IPv6 Adressen abzuändern.
nach 1 Stunde mal einen denic.de check gemacht:
nast: www.denic.de
Ergebnis: Glue Records sind schon aktiv, NS-Server nicht erreichbar.
komisch, also noch einmal die Einträge vom ISPConfig überprüft:
Aufgefallen ist mir: statt "NS = ns1.server.domain.tld" stand nur in der DNS Zone "server.domain.tld"
ebenso statt 2 NS Einträge aufgelistet zu bekommen, konnte ich nur einen finden und dieser hatte eine TTL von Null!
mhh, ich checkte noch einmal die Import Datei:
ich hab es ein paar mal probiert.
Beim importieren wird immer der NS1 Präfix entfernt.
Einverstanden, habe es dann in der DNS Zone abgeändert und manuell die 2 NS Einträge mit vernünftiger TTL auf den ISPConfig Maschinen gesetzt.
Durch dieses mehrfache Import herumspielen hatten dann irgendwie die Domänen unterschiedliche Serien Nummern: ergo haben DNS Checks wie von DNS check tool nach inconsistenten SOA Einträgen geschrien.
Viel Schlimmer war aber, dass der "fehlerhafte" Import, obwohl die Importvorlage ja korrekte Inhalte hatte, zu einem generellen Ausfall der Domain führte:
/etc/bind/pri.domain.tld.err
Das hab ich erst geschnallt als ich ein:
per Console durchführen wollte und merkte, dass eine .err erstellt wurde.
Fazit des Ganzen:
1. Es wäre gut, wenn ISPConfig Interface kurz checkt ob eine .err Datei vorhanden ist, wenn ja ... einen kurzen Hinweis ausspucken.
DNSServerAlt1 = ns1.servername.domain.tld
DNSServerAlt2 = ns1.servername.domain.tld
zu
DNSServerNeu1 = ns1.servername.domain.tld
DNSServerNeu2 = ns2.servername.domain.tld
Alles klar, ISPConfig3 (kein Master/Slave oder Cluster Setup) auf den 2 neuen Kisten eingerichtet, User-Accounts erstellt die alte Domain aus der /etc/bind/pri.domain.tld ge"cat"tet und ins Apple Text eingefügt (RTF).
Die 2 Maschinen sollen vollständig autonom laufen, sie dienen nur für eine einzige Hauptdomain als DNS Server, zwischen den Kisten findet kein Sync statt und aus Sicherheitsgründen haben sämtliche Useraccounts (linuxuser/ispconfig admin etc.) unterschiedliche Passwörter. SSH läuft nur per Cert-Auth.
Wenn ich also DNS Einträge ändere, muss ich dies auf den 2 Maschinen separat tätigen, was aber kein Problem darstellt.
Ich habe also per "Safari" Browser die TXT mit den 150 Einträge per Interface: DNS -> Zonen Datei Import versucht hochzuladen,
Server 1 listete nur 2 Seiten mit Inhalt auf
Server 2 hingegen 8 Seiten
ich dachte nur: "kann doch nicht sein"
nach etlichem herumspielen hab ich es geschnallt:
das File muss als "reine TxT" hochgeladen werden
Ok, DNS Server laufen, kurz die wichtigsten Einträge überflogen ... passt soweit ... bei der Eurid bescheid gegeben doch bitte mal die Glue Records für die 2 neuen IPv4/IPv6 Adressen abzuändern.
nach 1 Stunde mal einen denic.de check gemacht:
nast: www.denic.de
Ergebnis: Glue Records sind schon aktiv, NS-Server nicht erreichbar.
komisch, also noch einmal die Einträge vom ISPConfig überprüft:
Aufgefallen ist mir: statt "NS = ns1.server.domain.tld" stand nur in der DNS Zone "server.domain.tld"
ebenso statt 2 NS Einträge aufgelistet zu bekommen, konnte ich nur einen finden und dieser hatte eine TTL von Null!
mhh, ich checkte noch einmal die Import Datei:
Code:
$TTL 3600
@ IN SOA ns1.server1.domain.tld. service.domain.tld. (
2013042000 ; serial, todays date + todays serial #
3600 ; refresh, seconds
900 ; retry, seconds
604800 ; expire, seconds
86400 ) ; minimum, seconds
;
ns1.server1.domain.tld 86400 A xxx.xxx.xxx.xxx
ns1.server1.domain.tld 86400 AAAA 2a01:xxxx:xxxx::xxxx
ns2.server2.domain.tld 86400 A xxx.xxx.xxx.xxx
ns2.server2.domain.tld 86400 AAAA 2a01:xxxx:xxxx::xxxx
MX …
und der ganze andere Rasselich hab es ein paar mal probiert.
Beim importieren wird immer der NS1 Präfix entfernt.
Einverstanden, habe es dann in der DNS Zone abgeändert und manuell die 2 NS Einträge mit vernünftiger TTL auf den ISPConfig Maschinen gesetzt.
Durch dieses mehrfache Import herumspielen hatten dann irgendwie die Domänen unterschiedliche Serien Nummern: ergo haben DNS Checks wie von DNS check tool nach inconsistenten SOA Einträgen geschrien.
Viel Schlimmer war aber, dass der "fehlerhafte" Import, obwohl die Importvorlage ja korrekte Inhalte hatte, zu einem generellen Ausfall der Domain führte:
/etc/bind/pri.domain.tld.err
Das hab ich erst geschnallt als ich ein:
Code:
named-checkzone domain.tld /etc/bind/pri.domain.tldper Console durchführen wollte und merkte, dass eine .err erstellt wurde.
Fazit des Ganzen:
1. Es wäre gut, wenn ISPConfig Interface kurz checkt ob eine .err Datei vorhanden ist, wenn ja ... einen kurzen Hinweis ausspucken.
Zuletzt bearbeitet:
