Serverumzug + DNSSEC -> Probleme mit mehreren Domains

    Guten Morgen zusammen,

    erst einmal sorry für den unspezifischen Titel, aber da sich mittlerweile mehrere Baustellen auftun, bin ich ein bisschen "lost".

    Ich habe vor mehreren Monaten von meinem alten netcup-vServer auf einen neueren - ebenfalls bei netcup - migriert.

    Ich betreibe seit Jahren eine eigene bind-Instanz, welche sich um meine Domains kümmern. Die Domains liegen ebenfalls bei netcup. Ich habe vor rund 8 Jahren DNSSEC für meine Domains eingerichtet und soweit lief das auch alles jahrelang ordentlich vor sich hin.

    Beim Umzug habe ich bind dann auch endlich mal auf eine aktuellere Version geupdatet und nutze seitdem den neuen Parameter "dnssec-policy", über welchen das Management von KSK und ZSK vereinfacht und durch bind übernommen werden soll.

    Aktuell habe ich mit mehreren Problemen zu kämpfen:

    • Für ormanns.net sind laut https://dnsviz.net/d/ormanns.net/dnssec/ u.a. veraltete Glue-Records hinterlegt. Im CCP habe ich aber schon vor Monaten die aktuellen Adressen meiner Nameserver eingetragen - einmal als Hostname, einmal in IPv4 und einmal in IPv6. Woher kommen die veralteten Einträge?
    • Laut https://dnsviz.net/d/ormanns.net/dnssec/ reagieren nicht alle hinterlegten Nameserver auf Anfragen - das ist korrekt, denn die dort abgefragten Nameserver sind ja zum Teil außer Betrieb. Wo hakt es, wo werden die Infos nicht korrekt durchgereicht?
    • syncookie.de kann aufgelöst werden, hier hakt es aber nach wie vor an der sauberen DNSSEC-Implementierung (siehe https://dnsviz.net/d/syncookie.de/dnssec/). bind liefert mir für diese Domain keinen ZSK und KSK mehr, sondern einen CSK, der die beiden Keys kombiniert.
      • Den Status des Keys rufe ich wie folgt ab:
        # rndc dnssec -status syncookie.de
        dnssec-policy: default
        current time: Sat Apr 26 08:32:10 2025

        key: 64045 (ECDSAP256SHA256), CSK
        published: yes - since Thu Feb 13 18:44:12 2025
        key signing: yes - since Thu Feb 13 18:44:12 2025
        zone signing: yes - since Thu Feb 13 18:44:12 2025

        No rollover scheduled
        - goal: omnipresent
        - dnskey: omnipresent
        - ds: omnipresent
        - zone rrsig: omnipresent
        - key rrsig: omnipresent
      • Wenn ich mir dann das Keyfile anschaue, erhalte ich meinem Verständnis nach den Pubkey (ist das wirklich der öffentliche Schlüssel?) sowie ein paar Parameter:
        ; This is a key-signing key, keyid 64045, for syncookie.de.
        ; Created: 20250213174412 (Thu Feb 13 18:44:12 2025)
        ;Publish: 20250213174412 (Thu Feb 13 18:44:12 2025)
        ; Activate: 20250213174412 (Thu Feb 13 18:44:12 2025)
        ; SyncPublish: 20250214184912 (Fri Feb 14 19:49:12 2025)
        syncookie.de. 3600 IN DNSKEY 257 3 13 FIQP1EVPR[...]5UQ==
      • Heißt für mich: 257 = KSK, 13 = verwendeter Algorithmus und dahinter der Pubkey. Diese Parameter trage ich im CCP für diese Domain ein und speichere sie.
      • Ein "delv syncookie.de" liefert mir dann aber lokal auf dem Nameserver folgendes:
        ;; validating syncookie.de/A: no valid signature found
        ; unsigned answer syncookie.de. 60 IN A 37.120.174.123
        syncookie.de. 60 IN RRSIG A 13 2 60 20250504192639 20250420191653 64045
        syncookie.de. wYiSJYjmvIwrOjh+[...]w==
      • Welcher Schlüssel ist das, der hier ausgegeben wird?
    • row-records.de wird seit einiger Zeit nicht mal mehr korrekt aufgelöst, je nachdem welchen Nameserver man nutzt. Wenn ich meine Nameserver direkt abfrage, klappt alles. Der NAST Predelegation Check bei der DENIC liefert "Prüfung erfolgreich" und gibt mir die beiden Nameserver aus, welche ich im CCP für diese Domain hinterlegt habe. Rufe ich aber 1.1.1.1 oder 8.8.8.8 ab, bekomme ich einen SERVFAIL. Irgendwo in der Kette scheint die Domain also nicht korrekt weitergereicht zu werden, so ist zumindest mein Verständnis.
    • Allerdings ist hier auch noch ein Dnskey angegeben, welchen ich vorgestern aus dem CCP gelöscht habe. Ich will die Domain erstmal ordentlich auflösen lassen, bevor ich mich auch hier mit DNSSEC herumschlage.

    Daraus ergeben sich für mich folgende Fragen:

    • Hat netcup öffentlich verfügbare Nameserver, an welche ich testweise meine Queries richten kann? 46.38.225.230 und 46.38.252.230 scheinen keine Anfragen von außerhalb zuzulassen. Ich habe aber bei mehreren Domains das Problem, dass veraltete DNS-Informationen kursieren und würde gerne herausfinden, an welcher Stelle es klemmt.
    • Wie kann ich einen CSK ordentlich im CCP einbinden? Auf meine Anfrage beim Support kam nach 9 Tagen die Antwort "CSK Sollte gültig sein, solange das CCP das zulässt." - das hilft mir aktuell leider nicht weiter.
    • Ist das für syncookie.de beschriebene Vorgehen aus eurer Sicht korrekt? Wenn ja, dann sollte ich dieses ja theoretisch auf weitere .de-Domains übertragen können...

    Sicherlich werden hier noch Infos fehlen - diese reiche ich bei Bedarf gerne zeitnah nach.

    Viele Grüße

    Aleph

    Die alten Glue Records werden von den Nameservern der .net TLD verbreitet. Wenn die Daten aus dem CCP nicht übernommen werden, stimmt vielleicht etwas damit nicht. Die IPv6 Addressen mit :: am Ende sind z.B. streng genommen nicht korrekt. Das ist die Subnet-Router Anycast Adresse. Vielleicht stört sich (neuerdings) irgendwas daran und die Werte werden deshalb nicht übernommen. Vielleicht ist es auch einfach nur ein Bug. Korrigiere möglichst die Adressen und setz sie nochmal neu.

    Dass die eine Domain nicht aufgelöst werden kann, liegt am fehlenden DNSKEY. Die externen Resolver weigern sich deshalb.

    Hallo NaN,

    danke für deine Antwort.

    Ich habe bei der .net-TLD jetzt den dritten Nameserver rausgenommen, dieser liegt bei einem anderen Hoster und hat anscheinend ein IPv6-Problem. Nachdem ich die DNS-Settings im CCP gespeichert habe, ist jetzt auch die entsprechende Warnung bei DNSViz verschwunden. Die Warnung bzgl. der Glue-Records bleibt aber.

    Aktuell sind im CCP für die .net-TLD jetzt folgende Nameserver hinterlegt:

    ns1.ormanns.net 37.120.174.123 2a03:4000:6:70dd::

    ns2.ormanns.net 185.16.60.59 2a03:4000:a:52::

    Ich verstehe deine Rückmeldung so, dass diese IPv6-Adressen streng genommen nicht korrekt sind. Allerdings wird bei DNSViz jetzt nur noch folgende Warnung ausgegeben:

    • net to ormanns.net: The glue address(es) for ns1.ormanns.net (2a03:4000:6:43f3::) differed from its authoritative address(es) (2a03:4000:6:70dd::). See RFC 1034, Sec. 4.2.2.
    • net to ormanns.net: The glue address(es) for ns1.ormanns.net (37.120.165.116) differed from its authoritative address(es) (37.120.174.123). See RFC 1034, Sec. 4.2.2.

    Ich schließe daraus, dass die dort angegebenen Adressen so schon verarbeitet werden können, denn sonst müsste ja auch eine Warnung für ns2 ausgegeben werden. Oder verstehe ich dein Posting falsch?

    Viele Grüße
    Aleph

    Zitat von Aleph

    ns1.ormanns.net 37.120.174.123 2a03:4000:6:70dd::

    Zitat von Aleph

    The glue address(es) for ns1.ormanns.net (2a03:4000:6:43f3::) differed from its authoritative address(es) (2a03:4000:6:70dd::)

    "Authoritative address" is die, die dein Nameserver selbst nennt. "Glue address" ist die, die die .net Nameserver nennen. Dein Nameserver nennt die 70dd:: am Ende, und die hast du auch als Glue im CCP eingetragen, aber die wird aus irgendeinem Grund nicht von den .net Servern übernommen. Dieser Grund könnte sein, dass das keine korrekte Adresse ist, weil der Interface Identifier komplett Null ist. Dieser Interface Identifier ist als Subnet-Router Anycast reserviert. Der Grund könnte auch etwas ganz anderes sein, aber wenn du auf Fehlersuche bist, dann gib deinem Nameserver eine korrekte IPv6 Adresse und versuche, die externen Nameserver und Glue Records neu zu setzen. Du könntest auch die IPv6 Adressen testweise gar nicht als Glue Records angeben, um zu sehen, ob die Einträge dann vom CCP zu den .net Servern übernommen werden.