Guten Tag,
wir möchten gerne das DNS-System von LiveConfig nutzen, scheitern aber am NAST-Check der DeNIC. Getestet haben wir die Domain updaix.de mit den Nameservern
- a.webspacepanel.de
- b.webspacepanel.de
- c.webspacepanel.de
Wir haben mehrere Fehler in Form von
[INDENT]Received response does not provide expected records directly (resolver, NS, RR)[/INDENT]
erhalten.
Wir vermuten das Problem darin, dass die Reihenfolge der NS-Einträge zufällig ist:
jf-MBP15:~ jf$ nslookup -type=NS updaix.de a.webspacepanel.de
Server: a.webspacepanel.de
Address: 78.46.63.104#53
updaix.de nameserver = c.webspacepanel.de.
updaix.de nameserver = a.webspacepanel.de.
updaix.de nameserver = b.webspacepanel.de.
jf-MBP15:~ jf$ nslookup -type=NS updaix.de a.webspacepanel.de
Server: a.webspacepanel.de
Address: 78.46.63.104#53
updaix.de nameserver = a.webspacepanel.de.
updaix.de nameserver = b.webspacepanel.de.
updaix.de nameserver = c.webspacepanel.de.
Alles anzeigen
Hat noch jemand dieses Problem, oder liegt der Fehler sogar an etwas ganz anderem?
Unser unschöner Lösungsansatz wäre, sofern das Problem wirklich durch die Rotation der Nameserver kommt und nicht anderweitig gelöst werden kann, die Reihenfolge von NS-Resource-Records per rrset-order (= fixed) zu fixieren.
Das würde aber dazu führen, dass wir in mitgelieferte LUA-Dateien von LiveConfig (insb. /usr/lib/liveconfig/lua/bind.lua) eingreifen müssten, um die Konfigurationsdirektive dauerhaft in die named.conf.options aufnehmen zu können. Ich gehe davon aus, dass die LUA-Datei bei einem LiveConfig-Update überschrieben werden könnte und dann erneut angepasst werden müsste, was natürlich blöd wäre. Der Update-Prozess wird durch diese Lösungsvariante aber auch dadurch gestört, dass das vorkompilierte Bind9-Paket nicht mehr verwendet werden kann, weil bei diesem die fixierte Reihenfolge nicht möglich ist (wurde ohne --enable-fixed-rrset kompiliert).
Eine andere Lösung wäre daher sehr hilfreich.