Feature-Wünsche für die DNS-Verwaltung

  • Moin,


    mir fehlen bislang einige (meines Erachtens teils essenzielle) Features in der DNS-Verwaltung im CCP. Ich schreibe hier ausschließlich aus der Perspektive "nackte Domain über Netcup registriert bzw. zu Netcup transferiert", ohne irgendwelche zusätzlichen Netcup-Produkte, die möglicherweise noch am DNS dranhängen könnten.


    Essenzielle Features, um Migrationen ohne Downtime zu ermöglichen:

    • Möglichkeit, die Netcup-Nameserver schon vor dem eigentlichen Domaintransfer so weit zu konfigurieren, dass beim Domaintransfer wirklich nur noch die NS-Records in der TLD-Zone geändert werden müssen (inkl. DNSSEC-Signaturen, nur halt ohne die entsprechenden Einträge in der TLD-Zone). Um Missbrauch vorzubeugen, könnte man z.B. den eigentlichen Domaintransfer zeitlich hinter den Klick auf den "kostenpflichtig bestellen"-Button verlagern. Ohne dieses Feature kann man Domains nicht ohne Downtime zu Netcup umziehen.
    • Möglichkeit, schon vor der Umstellung einer Domain von den Netcup-Nameservern auf eigene/externe Nameserver zusätzliche DS-Records und Glue Records in der jeweiligen TLD-Zone eintragen zu lassen.
    • Ne dreckige und unvollständige Alternative zu den beiden o.g. Features wäre u.U. noch die Möglichkeit, den Netcup-Nameservern für eine Domain eigene Private Keys als DNSSEC-KSK zu geben, bzw. den Private Key des KSK im CCP-Webinterface herunterladen zu können, wenn man von den Netcup-Nameservern auf externe Nameserver umstellen will.

    Mit "Downtime" ist hier gemeint "Hosts im Internet behandeln die Domain als nicht existent". Beispiel: Wenn im Rahmen einer eines Domainumzugs auf die Netcup-Nameserver die DNSSEC-Signaturkette der Zone kaputtgeht, weil man nicht vorhersehen konnte welchen DNSKEY die Netcup-Nameserver als KSK für die Zone erzeugen/verwenden werden, dann kriegt man für Einträge in der Zone von validierenden DNS-Resolvern nur noch ein "SERVFAIL" zurück. Wenn ein Mailserver versucht, an so eine Domain Emails auszuliefern, dann wird er die Emails nicht zwischenspeichern und warten bis die Domain wieder verfügbar ist, sondern die Emails schlicht verwerfen, und dem Absender ne Fehlermeldung à la "Die Domain gibt’s nicht" schicken. Sowas macht natürlich besonders viel Freude, wenn Nutzer von Emailadressen unter dieser Domain z.B. auf eine größere Anzahl Mailinglisten abonniert sind. Aber selbst wenn da nur ein einzelner Nutzer dranhängt, risikiert man immer noch ne Downtime von 24h, denn bei vielen DNS-Anbietern kann man die TTL des SOA-Records und der ganzen DNSSEC-Einträge nicht beeinflussen - da steht öfter mal ein Wert von irgendwo zwischen einer Stunde und einem Tag drin. Daher ist das IMHO auch klar ein essenzielles Feature, und nicht bloß ne "nice to have"-Geschichte.


    Ansonsten hätte ich auch noch ein paar "Nice-to-have"-Feature-Vorschläge:

    • Import und Export von BIND-Zonefiles (damit man sich nicht für jeden einzelnen DNS-Record im Webinterface dumm und dämlich klicken muss)
    • Unterstützung für Dynamic Updates (abgesichert per TSIG- oder SIG0-Keys, optimalerweise granulierbar bis runter zum einzelnen Record/Record-Typen, so wie das bei Bind z.B. mit "update-policy" möglich ist)
    • Möglichkeit, einzelne Records für DynDNS über HTTP(S) zu verwenden, wenn man die Netcup-Nameserver nutzt
    • Möglichkeit, die Netcup-Nameserver als Slaves zu benutzen (damit man nicht extra nen zweiten Server nur als Fallback-Nameserver braucht, wenn man sein seine Zone komplett selber verwalten möchte)
    • Möglichkeit, den/die DNSSEC-Signaturalgorithmen für die eigene Zone auszuwählen, wenn man die Netcup-Nameserver nutzt (optimalerweise inkl. der Möglichkeit, eigene Private Keys zu konfigurieren)
    • Für die Hardcore-Nerds: Möglichkeit, die NSEC3-Parameter zu konfigurieren
    • Import und Export von BIND-Zonefiles (damit man sich nicht für jeden einzelnen DNS-Record im Webinterface dumm und dämlich klicken muss)
    • Möglichkeit, einzelne Records für DynDNS über HTTP(S) zu verwenden, wenn man die Netcup-Nameserver nutzt

    Zu mindestens diese beiden Punkte könntest Du über die CCP/DNS API selbst lösen: https://www.netcup-wiki.de/wiki/DNS_API


    Für Letzteres gibt es auf GitHub schon etwas: https://github.com/stecklars/dynamic-dns-netcup-api


    Für den ersten Punkt gibt es derzeit maximal Scripte für ein allgemeines Backup. Ein direkter Import von Bind-Konfigurationsdateien ist damit afaik noch nicht möglich. Das müsste erst jemand programmieren.

  • Zu mindestens diese beiden Punkte könntest Du über die CCP/DNS API selbst lösen: https://www.netcup-wiki.de/wiki/DNS_API


    Für Letzteres gibt es auf GitHub schon etwas: https://github.com/stecklars/dynamic-dns-netcup-api


    Für den ersten Punkt gibt es derzeit maximal Scripte für ein allgemeines Backup. Ein direkter Import von Bind-Konfigurationsdateien ist damit afaik noch nicht möglich. Das müsste erst jemand programmieren.

    Danke für den Hinweis, aber "BIND-File runterladen" sollte schlicht ein Button/Link im CCP sein, und nichts, wofür ich mit der API rumfrickeln und erst noch irgendwelchen Third-Party-Code von Github ausführen muss in der Hoffnung, dass der schon keinen Unsinn mit meinem API-Zugang anstellt.

    Bitte nimm das nicht persönlich, aber "Die Netcup-API für DynDNS benutzen" ist (genau wie auch bei mehr oder weniger allen anderen Anbietern, die so nen Zugang anbieten) IMHO gemeingefährlicher Unfug - um einen einzelnen simplen A-/AAAA-/TXT-Record zu updaten, klatschst du da auf ein im Zweifelsfall nicht vertrauenswürdiges Gerät Logindaten, mit denen man deinen ganzen Kundenaccount übernehmen und in deinem Namen kostenpflichtig Dinge bestellen kann. Die API ist für Domainreseller gedacht, nicht für DynDNS.

    [EDIT]
    Die sicherere Notlösung für das DynDNS-Problem wäre übrigens, sich bei nem externen Anbieter (gibt auch in Deutschland welche, die das kostenlos und mit DNSSEC anbieten) ne DynDNS-Subdomain für das betreffende Gerät zu holen, und bei der "richtigen" Domain, die man bei Netcup liegen hat, nen CNAME auf die DynDNS-Subdomain des externen Anbieters zu setzen.
    [/EDIT]

    Ansonsten noch ein weiterer "Nice to have"-Vorschlag: Das Webinterface sollte beim Umzug von Domains, beim Umstellen einer Domain von den Netcup-Nameservern auf externe Nameserver und beim Bearbeiten der Einträge für externe Nameserver Dinge automatisch erkennen/vorschlagen, die es es erkennen kann. Z.B. sollte es reichen, wenn ich eine IP-Adresse oder den Hostname eines Nameservers eintippe, damit das Webinterface sich von diesem Server gleich die NS-Records für diese Zone und ggf. die dazugehörigen IP-Adressen für etwaige Glue Records abfragen und vorschlagen kann. Genauso könnten auch DNSKEY- bzw. DS-Records automatisch erkannt und vorgeschlagen werden.

    Und um den Umzug von Mitbewerbern zu Netcup noch ein wenig einfacher zu gestalten, könnte man z.B. auch ne Möglichkeit anbieten, vor dem Domaintransfer einzelne DNS-Labels per ANY-Abfrage beim alten Nameserver abzufragen (würde viel Zeit sparen in Situationen, wo der Kunde kein Zonefile der Zone besitzt, und in der Zone vllt. nur wenige Label, aber viele Records pro Label hat).

  • […] und in deinem Namen kostenpflichtig Dinge bestellen kann. Die API ist für Domainreseller gedacht, nicht für DynDNS.

    Das ist leider so nicht richtig. Die DNS-API steht seit einigen Monaten jedem Kunden zur Verfügung, auch "kleinen" Privatkunden. Ohne Domain Reselling Vertrag können darüber keine kostenpflichtigen Aktionen wie z.B. Domainbestellungen ausgelöst werden.


    Der einzige Kritikpunkt, der natürlich trotzdem zutrifft: Mit dem API-Zugang kann man alle DNS-Records aller Domains ändern.


    Ich wollte das nur als schnelle Alternative bzw. Workaround vorschlagen. Klar, wenn es direkt von netcup unterstützt werden würde, wäre das natürlich zu bevorzugen… :)

  • Zur Umzugs-Timing-Sache:

    Wenn es nur darum geht den Registrar zu wechseln, und die Nameserver erhalten bleiben, dann ist die Sache relativ easy. Die Nameserver sind 2min nach der Registrierung bei NetCup schnell wieder eingefüllt. Und man müsste schon extremes Pech haben, wenn der Zone-Reload der TLD genau in diesen 2 Minuten erfolgt. Wer auf Nummer sicher gehen will schaut vorher eben noch nach, zu welchen Zeiten die Nameserver der TLD konkret reloaded werden und führt den Vorgang zwischen zwei Reloads geplant durch.


    Wenn auch der Nameserver-Anbieter zu NetCup gewechselt wird, dann kann das freilich etwas mehr "geklicke" bedeuten. Aber auch hier würde ich meinen, das man das zwischen zwei Reloads hinbekommt (vorausgesetzt wir sprechen hier von 10-20 Records, und nicht von 1000). Hier würde ich aber im Vorfeld tatsächlich die Reload-Zeiten recherchieren.


    Was DNSSEC angeht: Um sich hier nicht ins Knie zu schießen würde ich rechtzeitig vor dem Transfer die DS-Records noch beim alten Registrar entfernen (also z.B. 48h vorher) und erst nach erfolgtem Umzug die neuen DS-Records wieder eintragen.

  • "Rausfinden wann in der TLD die Zone neu geladen wird" geht, ist aber auch eher fummelig, und ein ziemlicher Aufwand, den dann jeder Kunde für jede Domain auf sich nehmen muss, anstatt dass das eigentliche Problem an der richtigen Stelle (im CCP) ein für alle Mal sauber und nachhaltig gelöst wird.

    DNSSEC abschalten geht, ist aber auch ne eher dreckige Lösung, und führt nebenbei auch dazu, dass diverse Record-Typen während der Migrationsphase de facto nicht funktionieren (z.B. SSHFP, TLSA, SMIMEA, OPENPGPKEY, oder auch die TXT-Records für MTA-STS).

    Letztlich sind das alles dreckige und umständliche Hacks, die nicht nötig wären, wenn das CCP schlicht das anbieten würde, was (aus guten Gründen) technisch möglich ist, anstatt die Möglichkeiten, die man als Kunde hat, aus Nonsens-"Gründen" zu beschränken.