DNSSEC mit externem Nameserver - Wohin mit dem Hashtype?

    Für meine bei Netcup gekaufte Domain ist seit gestern ein externer Nameserver zuständig, und normales DNS funktioniert. Allerdings scheint DNSSEC nicht zu kooperieren. Der externe Nameserver gibt mir drei verschiedene öffentliche Schlüssel für die Hashtypes 1, 2 und 4. Allerdings weiß ich nicht, welchen Hashtype Netcup jetzt möchte, und es gibt auch keine Möglichkeit, diesen in der DNSSEC-Konfiguration für externe Server einzutragen. Ich habe gestern Abend (vor mehr als 12 Stunden) beide Schlüssel für Hashtype 2 und 4 eingetragen und laut Verisign/dnsviz fehlt nur noch der DS-Record, den Netcup an die .eu Nameserver weitergeben muss.


    Jedenfalls wäre meine Frage, welchen Hashtype Netcup möchte? Oder ob das eigentlich egal sein sollte und DNSSEC in Netcup anderweitig kaputt ist. Hab im Forum und auf den Supportseiten (z.B. hier) nichts gefunden.


    Ich verwende übrigens Algorithmus 15 (ED25519), weil dieser mit Abstand am besten von allem nicht-post-quantum-sicheren ist. (Warum unterstützt Netcup überhaupt so verflucht unsichere Dinge wie DSA und RSASHA1?)

    Zeig doch mal ein paar Screenshots. Was genau gibt dein Nameserver vor. Was genau hast du für Optionen im CCP (je nach TLD kann das unterschiedlich aussehen).


    Den Algorithmus gibt dir auch der Nameserver vor. Du kannst nicht einfach irgendwas bei netcup wählen.

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | VPS 500 ARM


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

    Mein DNS-Provider ist ein experimenteller Service (servfail.network), wobei DNSSEC dort bekanntermaßen mit anderen Domain-Providern funktioniert. Die DNSSEC-Daten, die ich erhalte, sehen so aus:

    pasted-from-clipboard.png


    Insbesondere handelt es sich eben um eine .eu-Domain und nicht um .de. Bei mir taucht das Hashtype-Feld nirgendwo auf.

    pasted-from-clipboard.png


    Ich habe den korrekten Algorithmus, hier 15, sowohl in servfail (siehe Screenshot) als auch in Netcup eingetragen. Das sollte nicht das Problem sein. Genauso handelt es sich hier nicht um einen Zone-Signing-Key bzw. Key-Singing-Key, daher sollten die Flags mit 0 korrekt sein.


    Auf Verisign kann man auch erkennen, dass der DNS-Provider die DNSSEC-Konfiguration korrekt vorgenommen hat, nur ist diese eben nicht von .eu aus verifiziert.

    Quote from filmroellchen

    Mein DNS-Provider ist ein experimenteller Service (servfail.network), wobei DNSSEC dort bekanntermaßen mit anderen Domain-Providern funktioniert. Die DNSSEC-Daten, die ich erhalte, sehen so aus:

    Das sind die Digests, also Fingerprints des Schlüssels - die Algorithmen dazu (SHA1, SHA256 etc.) sind der Hash Type. Das sind die DS Records.


    Netcup will hier allerdings den Schlüssel und keinen Fingerprint des Schlüssels (DNSKEY Record). Werden dir die Daten angeboten bei deinem Provider?


    Normalerweise kann man DNSKEY in DS umrechnen, aber nicht umgekehrt.

    $ dig +short filmroellchen.eu dnskey

    257 3 15 uvfreAyBCM/OWvvVByYHdHMXcX5awD4bDsxYXWQL8t8=


    257 ist bei "Flags" anzugeben (KSK bzw. CSK)

    Die 3 besagt nur, dass es sich hier um DNSSEC handelt

    15 ist der verwendete Algorithmus (ED25519). Der gehoert in das entsprechende Feld im CCP.

    Der Rest ist der oeffentliche Schluessel.


    ED25519 wird bei .de Domains nicht unterstuetzt. Wie das bei .eu aussieht, weiss ich nicht.

    Generell ist ED25519 in RFC8624 nur RECOMMENDED, nicht MUST. Ich wuerde einen "MUST" Algorithmus nehmen.

    Quote

    Netcup will hier allerdings den Schlüssel und keinen Fingerprint des Schlüssels (DNSKEY Record). Werden dir die Daten angeboten bei deinem Provider?

    Das war auch schon die Vermutung meiner Administrator*in. Aktuell gibt es dafür kein öffentliches Interface, sie kümmert sich aber in nächster Zeit darum. Danke für den Hinweis jedenfalls!

    Quote

    ED25519 wird bei .de Domains nicht unterstuetzt. Wie das bei .eu aussieht, weiss ich nicht.

    Generell ist ED25519 in RFC8624 nur RECOMMENDED, nicht MUST. Ich wuerde einen "MUST" Algorithmus nehmen.

    Die 25519-Kurve wird bei .eu unterstützt, ansonsten wäre sie ja wohl nicht in der Liste von Netcup bezüglich dieser TLD und man könnte sie (hoffentlich) in der Maske nicht auswählen. Warum sie bei DE nicht unterstützt wird: Laut Aussage einer befreundeten DENIC-Mitarbeiterin ist der Algorithmus seit 2015 im Backlog und sie kommen aus [NDA]-Gründen nicht dazu. (Also eigentlich sollte das dann mal passieren.) Was der RFC sagt ist mir ziemlich egal, bekanntlich ist die Kurve genauso sicher wie RSA (d.h. sicher unter der Annahme der Schwierigkeit des diskreten Logarithmus, und damit auch nicht post-quantum-sicher) bei kürzeren Schlüssellängen, also immer RSA vorzuziehen.

    Es ging mir nicht um die Sicherheit, sondern um die Interoperrabilitaet. "Sicher genug" sind die Algorithmen wohl alle. Aber ob auch alle verifizierenden Resolver alle Algorithmen implementieren, ist eine andere Frage.

    Die meisten Resolver werden den Algorithmus wohl implementieren, aber manche vielleicht nicht. Sie "müssen" es ja laut RFC auch nicht, es ist nur empfohlen. Also muss einem bei Verwendung dieses Algorithmus bewusst sein, dass eventuell nicht alle Resolver damit klarkommen und in der Konsequenz die Zone als unsicher betrachten. Das ist meist nicht allzu schlimm, aber man muss sich darüber zumindest Gedanken machen und sich überlegen, ob das für den konkreten Anwendungsfall ein Problem sein könnte oder nicht.