Wechsel der IP-Adresse des Glue-Record bei .at Domain wirkt nicht

  • Customer Control Panel, Domains => DNS,

    ich betreibe meine Domain hitco.at seit Jahren mit drei Dual-Stack IPv4+IPv6 konfigurierten Nameservern.

    Hierzu verwende ich Glue-Records.


    Bedingt durch einen Systemwechsel änderte sich nun meine IPv4 Adresse des ns3.

    Im Webinterface kann ich das zwar eingeben, und wird auch angenommen und im CCP angezeigt, es schlägt sich jedoch nicht in die Datenbank von nic.at durch. Der Zeitstempel des Whois-Records ändert sich, aber die IP-Adresse die im Whois aufscheint und nach einem Reload der nic.at Nameserver weiterhin als Glue-Record aufscheint ist die alte IP-Adresse 23.97.171.64 und nicht die neue 51.116.232.243



    pasted-from-clipboard.png


    Ein Mail an den Support blieb bislang noch ohne Reaktion.

    Hat jemand von euch schon mal bei einer .at Domain die Glue-Records erfolgreich geändert?


    Bevor nun Hinweise kommen, ich solle doch X-stunden warten: Das ist mir bewusst. Mir sind auch die Zeiten bekannt wann NIC.at ihre Nameserver reloaded. Der aktuelle Glue-Record schafft es aber nichteinmal in die NIC.at Whois-Datenbank, und das geht "live".


    Als Workaround habe ich folgende Alternativen erfolglos versucht:


    Versuch die ns3 IPv4 zu entfernen (leer zu lassen):


    Fehler:
    Die Nameserver konnten nicht aktualisiert werden. Domain update at registrar failed. Data management policy violation:
    Frame contains no update operation



    Versuch nur ns1 und ns2 anzugeben und ns3 vorläufig ganz wegzulassen (delete-Button):


    Fehler:
    Die Nameserver konnten nicht aktualisiert werden. Domain update at registrar failed. Command syntax error:
    Parser error at line [0], column [1871]: Element \'{urn:ietf:params:xml:ns:domain-1.0}hostAddr\': This element is not expected. Expected is ( {urn:ietf:params:xml:ns:domain-1.0}hostAttr ).


    Beide Fehlermeldungen erscheinen mir sachlich falsch. Ich vermute hier eher ein Problem mit der API die Netcup bei NIC.at benutzt.


    Meine Nameserver antworten autoritativ mit allen drei Servern:


    Die nic.at Registry hat weiterhin die alte ns3-IPv4 gelistet:

    Die nic.at Nameserver beinhalten weiterhin den falschen Glue-Record:

  • falls Dir das weiterhilft ... (soeben bei mir getestet)

    Code
    C:\>nslookup ns3.hitco.at
    Server:  MEINROUTER
    Address:  IPv6
    
    Non-authoritative answer:
    Name:    ns3.hitco.at
    Addresses:  2001:470:1f0b:ee1::babe
              51.116.232.243

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • gunnarh - einem alten Hasen wie Dir passieren keine Fehler. Für mich sieht es so aus, als ob das, was die netcup-API das EPP bei nic.at mit fehlerhaften XML-Daten anspricht.
    Siehe https://www.metaregistrar.com/…domains/domain-check.html


    Dazu möchte ich allerdings anmerken, dass nic.at die Glue-Records wahrscheinlich auch automatisch von den angegebenen autoritativen NS auflösen kann, Du also versuchen könntest, die IP beim Update gar nicht erst anzugeben. (Zumindest hat das nic.at-eigene Formular das früher so gemacht).


    Bei anderen Registraren kann man Glue-Records auch aktiv löschen (bei 4. Buchstabe im Alphabet² 2-4 etwa).


    Ich selbst bin mittlerweile von Glue-Records abgekommen und habe mir Billig-Domains aus unterschiedlichen Zonen geleistet, die ich jetzt für die Nameserver verwende. So stellt sich das Problem fehlgeschlagener EPP-Updates gar nicht erst.


    Ein Workaround könnte darin bestehen, dass Du ns3 zwar in Deiner Zone definierst, aber einstweilen einen nstemp mit der neuen IP anlegst, dann den ns3-Glue über EPP löschst (löschen lässt), und dann ein weiteres Update veranlasst.


    Eventuell hilft es auch, beim NIC.at-Support direkt anzufragen - wenn sie dort auch nichts für Domains eines Registrars machen werden wollen, so können sie zumindest netcup einen Tip geben, was da schief läuft - oder den Glue für ns3 löschen.


    Für Interessierte Reload-Times sind übrigens momentan alle 2 ungeraden Stunden - nachzulesen in den nic.at FAQ.

    https://www.nic.at/de/so-funkt…archFaqForm&search=reload


    Noch ein paar Debbuging-Daten:


    for i in $(seq 1 3); do dig +short @ns${i}.hitco.at -t soa hitco.at; done

    ns1.hitco.at. dns-admin.hitco.at. 2020102513 1200 600 2419200 1200

    ns1.hitco.at. dns-admin.hitco.at. 2020102513 1200 600 2419200 1200

    ns1.hitco.at. dns-admin.hitco.at. 2020102513 1200 600 2419200 1200


    for i in $(seq 1 3); do dig +short @ns${i}.hitco.at -t ns hitco.at; done

    ns3.hitco.at.

    ns2.hitco.at.

    ns1.hitco.at.

    ns3.hitco.at.

    ns2.hitco.at.

    ns1.hitco.at.

    ns3.hitco.at.

    ns1.hitco.at.

    ns2.hitco.at.


    dig @ns2.univie.ac.at -t NS hitco.at


    ; <<>> DiG 9.16.1-Ubuntu <<>> @ns2.univie.ac.at -t NS hitco.at

    ; (2 servers found)

    ;; global options: +cmd

    ;; Got answer:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45307

    ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 7

    ;; WARNING: recursion requested but not available


    ;; OPT PSEUDOSECTION:

    ; EDNS: version: 0, flags:; udp: 4096

    ; COOKIE: 99d52320d12a68b2010000005f95a884c670471c60a983e1 (good)

    ;; QUESTION SECTION:

    ;hitco.at. IN NS


    ;; AUTHORITY SECTION:

    hitco.at. 10800 IN NS ns3.hitco.at.

    hitco.at. 10800 IN NS ns2.hitco.at.

    hitco.at. 10800 IN NS ns1.hitco.at.


    ;; ADDITIONAL SECTION:

    ns3.hitco.at. 10800 IN A 23.97.171.64

    ns2.hitco.at. 10800 IN A 5.45.107.134

    ns1.hitco.at. 10800 IN A 37.120.174.149

    ns3.hitco.at. 10800 IN AAAA 2001:470:1f0b:ee1::babe

    ns2.hitco.at. 10800 IN AAAA 2a03:4000:6:126c::affe

    ns1.hitco.at. 10800 IN AAAA 2a03:4000:6:71ec::cafe


    ;; Query time: 8 msec

    ;; SERVER: 192.92.125.2#53(192.92.125.2)

    ;; WHEN: So Okt 25 17:32:04 CET 2020

    ;; MSG SIZE rcvd: 251

  • OK, gerade mit einer spare Domain versucht, wobei ich nur die IP des SOA-NS angegeben habe, die anderen beiden nicht:

    Fehler:

    IP des Nameserver dns2.testdomain.at im falschen Format. Bitte geben Sie die IP des Nameservers als IPv4 oder IPv6 an.

    Da der Nameservereintrag innerhalb der bearbeiteten Zone liegt, muss eine IP zum Nameserver angegeben werden (Glue record).

    IP des Nameserver dns3.testdomain.at im falschen Format. Bitte geben Sie die IP des Nameservers als IPv4 oder IPv6 an.

    Da der Nameservereintrag innerhalb der bearbeiteten Zone liegt, muss eine IP zum Nameserver angegeben werden (Glue record).

    Sie können maximal 5 Nameserver für diese Domain angeben. Und müssen mindestens 2 Nameserver für diese Domain angeben.


    "testdomain" ist ein Platzhalter.


    Update 2: netcup scheint aber nicht zu testen, wenn man einen NS, der in der Zone steht, einfach weglässt...

    dns1 und dns2 mit ihren jeweiligen IP-Adressen sind jetzt drinnen. Mehr dazu ab 19 Uhr...

  • gunnarh ich bin jetzt erst dazugekommen. Die Nameserver (IPv4-only) sind so übernommen worden. Jetzt habe ich, gemein wie ich bin, dns2 eine andere IP-Adresse im CCP und eigene Nameserver gegeben - die Änderung wurde nach dem Speichern auch akzeptiert.

    Schauen wir einmal, ob der Wert nach 13 Uhr stimmt.

  • Nach dem Reload um 13 Uhr war die upgedatete IP bei nic.at immer noch nicht richtig.


    Ich habe dann im CCP gemacht:

    Löschen des zweiten Nameservers.

    Hinzufügen eines weiteren Nameservers mit anderem Namen an dieser Stelle: dns3 mit anderer IP (steht auch in der Zone).

    Fehler:

    Die Nameserver konnten nicht aktualisiert werden. Domain update at registrar failed. Command syntax error:

    Parser error at line [0], column [1871]: Element \'{urn:ietf:params:xml:ns:domain-1.0}hostAddr\': This element is not expected. Expected is ( {urn:ietf:params:xml:ns:domain-1.0}hostAttr ).


    Anschließend habe ich auf die netcup-Nameserver gewechselt - OK.

    Zurück auf eigene Nameserver: alle drei Einträge neu angelegt: OK

    Swap der IP von zwei der Nameserver - speichern: OK.


    Also ein einfaches Update scheint nicht zu funktionieren, aber der Wechsel von eigenen auf netcup-Nameserver dürfte das Delete triggern.

    Danach ist das Anlegen möglich.


    Unklar ist mir, wieso dann der Swap von zwei IPs zulässig ist.


    Ab 15 Uhr sehen wir ja, ob die Änderung durch ist.


    Im Whois stehen noch die alten Werte von gestern.


    Wen von netcup könnten wir da „anpingen“ um Licht ins Dunkel zu bringen?

  • Danke eripek für deine Tests.

    Mal sehen was mein geöffnetes Ticket beim Support für Erkenntnisse liefert. Dass da wohl irgend ein API/Script-Problem vorliegt scheint mir mittlerweile recht klar zu sein. Danke für den Tipp mit dem Workaround über den kurzfristigen Wechsel zu den Netcup Nameservern, wenn der Support keine kurzfristig andere Lösung hat werde ich das demnächst auch so versuchen.

  • Bitte gerne! Ich habe auch den Eindruck, dass beim Versuch, die Glue-Records nach dem Prinzip KISS einzubauen, im CCP etwas übersehen worden ist. Bei dem anderen Anbieter, den ich angedeutet habe, wurde für die Glue-Records pro Domain ein eigener Reiter gebaut, wo man die Einträge einzeln bearbeiten kann, wobei man sie auflösen oder manuell eingeben kann, und auch pro Server mehrere IPs registrieren kann.

    Leider ist das bei netcup längst nicht so „sophisticated“.


    Halt mich bitte auf dem laufenden, was Dein Ticket ergeben hat. Es würde mich sehr interessieren.


    Zwischenbericht: Das Update hat natürlich nicht geklappt. ns2.univie.ac.at liefert als additionals immer noch die falschen zwei IPs.

  • Vom Support wurde mit hierzu noch mitgeteilt:

    Quote

    Unsere Entwicklungsabteilung ist informiert.

    Ob und wann das Problem gelöst wird kann ich Ihnen jedoch momentan nicht sagen.


    Für mich ist die Umstellung erledigt, wer eine .at Glue-Record-Änderung in nächster Zeit vor hat, sollte das evtl. vorab schon mal "probieren" solange der alte Server noch läuft, und nötigenfalls 1-2 Tage Zeit für eine allenfalls nötige Support-Ticket-Bearbeitung im geplanten Ablauf mit einkalkulieren.

  • Nur zwecks Dokumentation.... das von mir hier vor fast zwei Jahren beschriebene Problem vom Oktober 2020 ist weiterhin in identischer Form vorhanden.


    Wurde also in den letzten zwei Jahren leider NICHT gelöst.

    Ich habe abermals ein Support-Ticket eingebracht, bislang keine Antwort - rechne auch mit keiner da ich inzwischen einen Workaround gefunden habe.


    Da ich diese Woche abermals 2x meine GLUE-Records der .at Domain anpassen musste (Übersiedelung auf neue Server) konnte ich folgenden Workaround "erarbeiten" und als funktionstüchtig validieren. So entgeht man diesem Bug:


    Vorbereitung: Nachschauen wann die NIC.at Reload-Zeiten sind, sich einen Zeitpunkt suchen zu dem kein Reload stattfindet (Die Reloads finden zu festgelegten Zeiten zur vollen Stunde statt, wenn man den Vorgang also um xx:20 durchführt dann hat man jedenfalls 40 Minuten Zeit bis zum nächsten potentiellen Reload der .at Zonen). Derzeit findet der Reload laut nic.at zu folgenden Zeiten statt: Unsere Reload-Zeiten sind um 1:00, 3:00, 5:00, 7:00, 9:00, 11:00, 13:00, 15:00, 17:00, 19:00, 21:00 und 23:00 Uhr (MEZ) [Anmerkung: Jetzt im Sommer ist es getesteter Weise MESZ und nicht MEZ, oder einfacher ausgedrückt: Zeitzone Vienna].


    Weiters Vorbereitung: Wer DNSSEC benutzt notiert sich vor dem Umschalten die hierfür nötigen Parameter, damit man diese nicht erst nach dem Zurückschalten auf eigene Nameserver dann erst mühsam neu recherchieren werden müssen. Die DNSSEC-Parameter lassen sich nach dem Zurückschalten auf eigene Nameserver erst nach dem Speichern wieder eingeben.


    1. Im CCP bei der .at Domain von eigenen Nameservern auf die Netcup Nameserver umschalten und speichern (man muss dazu nichts befüllen, einfach umschalten und ohne zu befüllen auf speichern drücken reicht aus).

    2. Whois der eigenen .at Domain prüfen - nun sind die Netcup-Nameserver eingetragen, technisch wirksam würde das erst zum nächsten nic.at Reload-Zeitpunkt

    3. Nun wieder auf eigene Nameserver im CCP umstellen und die Daten vollständig neu eintippen, speichern

    3b. Optional: Falls DNSSEC benutzt wird, nun auch diese Daten eingeben und speichern (ist erst nach Speichern der eigenen Namserver-Namen + GlueRecords möglich)

    4. Whois prüfen ... voila - sofort übernommen. Die eigenen Nameserver mit den nun hinterlegten GLUE-Records scheinen im WHOIS auf.

    5. Abwarten bis zum nic.at Reload, dann werden die glue-Records in die .at Zone übernommen.