Umzug zu deSEC

Wer seine Domain bei einem Registrar wie netcup registriert hat, muss dort nicht zwangsläufig auch die DNS-Server verwenden. Registrar und DNS-Hosting lassen sich voneinander trennen. Genau das habe ich mit meinen Domains gemacht: Die Domains bleiben bei netcup registriert, das DNS-Hosting übernimmt künftig deSEC.

deSEC ist ein vom gemeinnützigen deSEC e.V. betriebener DNS-Dienst. Der Dienst ist kostenlos, die Software ist Open Source und DNSSEC ist fester Bestandteil des Konzepts. Zonen werden automatisch signiert, die benötigten DS- und DNSKEY-Informationen stellt deSEC direkt bereit. Hinzu kommen unter anderem eine REST-API zur automatisierten Verwaltung, DynDNS-Unterstützung und eine verteilte Anycast-Infrastruktur. Beim Datenschutz verfolgt deSEC nach eigenen Angaben den Ansatz, möglichst wenige personenbezogene Daten zu erheben. Der Dienst finanziert sich unter anderem über Spenden.

In diesem Beitrag zeige ich anhand von kuketz-forum.de, wie der Umzug von netcup zu deSEC funktioniert. Das Vorgehen lässt sich grundsätzlich auch auf andere Registrare übertragen. Voraussetzung ist, dass sich dort externe Nameserver und DNSSEC konfigurieren lassen.

Für die folgenden Schritte werden ein Account bei deSEC sowie Zugriff auf die DNS- und Domainverwaltung des bisherigen Anbieters benötigt. Außerdem verwende ich für die Kontrollen das Werkzeug dig. Unter Debian lässt es sich beispielsweise über das Paket dnsutils installieren:

apt install dnsutils

Wichtig ist außerdem, DNS und Registrar auseinanderzuhalten. In meinem Fall bleibt netcup weiterhin Registrar für kuketz-forum.de. Lediglich die autoritativen Nameserver und damit das eigentliche DNS-Hosting werden zu deSEC verschoben.

Bevor irgendetwas umgestellt wird, müssen die vorhandenen DNS-Einträge möglichst vollständig erfasst werden. Dieser Schritt sollte nicht unterschätzt werden. Eine vergessene Subdomain fällt vielleicht zunächst gar nicht auf, ein fehlender MX-, SPF-, DKIM– oder DMARC-Eintrag kann dagegen unmittelbar Auswirkungen auf den Mailverkehr haben.

Welche Nameserver aktuell für die Domain zuständig sind, lässt sich automatisch ermitteln. Das folgende Skript benötigt deshalb keine Kenntnis darüber, ob die Domain bei netcup oder einem anderen Anbieter liegt. Lediglich DOMAIN muss angepasst werden:

#!/bin/bash

DOMAIN="kuketz-forum.de"

echo "===== Autoritative Nameserver ====="

mapfile -t NAMESERVERS < <(dig "$DOMAIN" NS +short | sed 's/\.$//')

if [ "${#NAMESERVERS[@]}" -eq 0 ]; then
    echo "Keine autoritativen Nameserver gefunden."
    exit 1
fi

printf '%s\n' "${NAMESERVERS[@]}"

NS="${NAMESERVERS[0]}"

echo
echo "Für die folgenden Abfragen wird verwendet:"
echo "$NS"
echo

echo "===== Autoritative Antwort prüfen ====="
dig @"$NS" "$DOMAIN" SOA +noall +comments +answer

echo
echo "===== Apex ====="

for type in A AAAA MX TXT CAA; do
    echo "--- $type ---"
    dig @"$NS" "$DOMAIN" "$type" +noall +answer
done

echo
echo "===== www ====="

for type in A AAAA CNAME; do
    echo "--- $type ---"
    dig @"$NS" "www.$DOMAIN" "$type" +noall +answer
done

TESTNAME="dns-migration-wildcard-test-$(date +%s)"

echo
echo "===== Wildcard-Test: $TESTNAME.$DOMAIN ====="

for type in A AAAA CNAME; do
    echo "--- $type ---"
    dig @"$NS" "$TESTNAME.$DOMAIN" "$type" +noall +answer
done

echo
echo "===== DMARC ====="
dig @"$NS" "_dmarc.$DOMAIN" TXT +noall +answer

Die erste NS-Abfrage läuft über den aktuell eingestellten rekursiven Resolver und ermittelt die Nameserver der Domain. Für die eigentlichen Kontrollen wird anschließend einer dieser Nameserver mit dig @"$NS" direkt angesprochen. Damit umgehen wir für diese Abfragen den Cache des lokalen beziehungsweise vorgeschalteten rekursiven Resolvers und fragen einen Server, der die Zone selbst ausliefert.

Bei kuketz-forum.de landete die Abfrage zum Zeitpunkt meiner Migration beispielsweise bei einem Nameserver von netcup. Bei einem anderen DNS-Anbieter wird entsprechend dessen autoritativer Nameserver verwendet. Bei der SOA-Abfrage sollte im Header das Flag aa auftauchen:

flags: qr aa

aa steht für »Authoritative Answer« und bestätigt, dass der angesprochene Nameserver für die Zone autoritativ antwortet.

Anschließend prüft das Skript einige typische DNS-Records. Ein A-Record ordnet der Domain eine IPv4-Adresse zu, ein AAAA-Record entsprechend eine IPv6-Adresse. MX-Records bestimmen, welche Mailserver E-Mails für die Domain entgegennehmen. In TXT-Records stecken häufig zusätzliche Informationen wie die SPF-Regeln für den Mailversand, während CAA festlegt, welche Zertifizierungsstellen Zertifikate für die Domain ausstellen dürfen.

Diese Records werden zunächst für die Domain selbst, also in meinem Fall kuketz-forum.de, abgefragt. Zusätzlich prüft das Skript die häufig verwendete Subdomain www und den DMARC-Eintrag _dmarc. Ein CNAME-Record wird bei www ebenfalls abgefragt, weil eine Subdomain statt direkt auf eine IP-Adresse auch auf einen anderen Hostnamen verweisen kann.

Zum Schluss folgt ein Wildcard-Test. Ein Wildcard-Eintrag wie *.kuketz-forum.de sorgt dafür, dass auch nicht ausdrücklich angelegte Subdomains eine DNS-Antwort erhalten. Das Skript erzeugt deshalb einen sehr wahrscheinlich nicht existierenden Hostnamen wie dns-migration-wildcard-test-1758441234.kuketz-forum.de und fragt diesen ab. Erhält auch dieser eine A- oder AAAA-Adresse, spricht das für einen vorhandenen Wildcard-Eintrag. Das ist beim Umzug wichtig, weil ein vergessener Wildcard-Eintrag dazu führen kann, dass bisher funktionierende Subdomains nach dem Wechsel nicht mehr aufgelöst werden.

Eine Einschränkung hat das Skript allerdings: DNS bietet keine allgemeine Abfrage nach dem Muster »Zeige mir sämtliche Einträge dieser Zone«. Es kann deshalb nur Namen und Record-Typen prüfen, die bereits bekannt sind oder gezielt abgefragt werden. Wenn beispielsweise folgende Einträge existieren:

cloud.example.org
git.example.org
vpn.example.org
selector42._domainkey.example.org

kann das Skript deren Existenz nicht erraten. Im Idealfall bietet der bisherige DNS-Anbieter deshalb einen Export der kompletten Zone an. Alternativ kann getestet werden, ob ein Zonentransfer per AXFR erlaubt ist:

DOMAIN="kuketz-forum.de"
NS=$(dig "$DOMAIN" NS +short | head -n1)

dig @"$NS" "$DOMAIN" AXFR

Wird AXFR erlaubt, erhält man die Zone vollständig. Bei normalen DNS-Hosting-Angeboten ist ein öffentlicher Zonentransfer allerdings üblicherweise gesperrt. Eine Fehlermeldung an dieser Stelle ist daher nichts Ungewöhnliches. Die zuverlässigste Grundlage für einen Umzug bleibt deshalb die DNS-Verwaltung des bisherigen Anbieters beziehungsweise ein dort angebotener Zonefile-Export. Bei netcup habe ich die dort aufgeführten Records mit den Ergebnissen der dig-Abfragen verglichen.

In meiner Konfiguration gab es beispielsweise zusätzlich vier DKIM-CNAMEs für mailbox.org:

DOMAIN="kuketz-forum.de"
NS=$(dig "$DOMAIN" NS +short | head -n1)

for i in 1 2 3 4; do
    dig @"$NS" "mb0000${i}._domainkey.$DOMAIN" CNAME +noall +answer
done

Diese Abfragen gehören nicht allgemein zu einer DNS-Migration. Wer einen anderen Mailanbieter oder andere DKIM-Selektoren verwendet, muss seine entsprechenden Einträge prüfen. Für die Migration sollte man daher möglichst drei Quellen miteinander abgleichen:

1. DNS-Verwaltung beziehungsweise Zonefile-Export des bisherigen Anbieters
2. AXFR, falls der Anbieter einen Zonentransfer erlaubt
3. direkte dig-Abfragen gegen einen autoritativen Nameserver als zusätzliche Kontrolle

Bei kuketz-forum.de sah die so ermittelte Konfiguration beispielsweise so aus:

@       A       46.38.242.112
@       AAAA    2a03:4000:7:33:94cf:91ff:fe6a:b3e0

@       MX 10   mxext1.mailbox.org.
@       MX 10   mxext2.mailbox.org.
@       MX 10   mxext3.mailbox.org.
@       MX 10   mxext4.mailbox.org.

@       TXT     "v=spf1 include:mailbox.org mx ip4:45.9.61.217 ip6:2a03:4000:45:4a:c89c:ddff:fe76:ac70 ~all"

@       CAA     0 issue "letsencrypt.org"

*       A       45.9.61.217
*       AAAA    2a03:4000:45:4a:c89c:ddff:fe76:ac70

www     A       45.9.61.217
www     AAAA    2a03:4000:45:4a:c89c:ddff:fe76:ac70

_dmarc  TXT     "v=DMARC1; p=reject; pct=100; fo=1; ruf=mailto:abuse@kuketz-forum.de;"

mb00001._domainkey CNAME MB00001._domainkey.mailbox.org.
mb00002._domainkey CNAME MB00002._domainkey.mailbox.org.
mb00003._domainkey CNAME MB00003._domainkey.mailbox.org.
mb00004._domainkey CNAME MB00004._domainkey.mailbox.org.

Erst wenn diese Bestandsaufnahme abgeschlossen ist, sollte die neue Zone bei deSEC aufgebaut werden.

Nach der Registrierung bei deSEC wird die Domain zunächst dort angelegt, ohne beim bisherigen Registrar etwas zu verändern. Die bisherigen Nameserver bleiben also vorerst aktiv. Damit lässt sich die komplette neue Zone vorbereiten und testen, während der produktive DNS-Betrieb unverändert weiterläuft. Die DNS-Zone kann anschließend bei deSEC nachgebaut werden. Für kuketz-forum.de habe ich folgendes Zonefile verwendet:

$ORIGIN kuketz-forum.de.
$TTL 86400

@       IN A       46.38.242.112
@       IN AAAA    2a03:4000:7:33:94cf:91ff:fe6a:b3e0

@       IN MX 10   mxext1.mailbox.org.
@       IN MX 10   mxext2.mailbox.org.
@       IN MX 10   mxext3.mailbox.org.
@       IN MX 10   mxext4.mailbox.org.

@       IN TXT     "v=spf1 include:mailbox.org mx ip4:45.9.61.217 ip6:2a03:4000:45:4a:c89c:ddff:fe76:ac70 ~all"

@       IN CAA     0 issue "letsencrypt.org"

*       IN A       45.9.61.217
*       IN AAAA    2a03:4000:45:4a:c89c:ddff:fe76:ac70

www     IN A       45.9.61.217
www     IN AAAA    2a03:4000:45:4a:c89c:ddff:fe76:ac70

_dmarc  IN TXT     "v=DMARC1; p=reject; pct=100; fo=1; ruf=mailto:abuse@kuketz-forum.de;"

mb00001._domainkey IN CNAME MB00001._domainkey.mailbox.org.
mb00002._domainkey IN CNAME MB00002._domainkey.mailbox.org.
mb00003._domainkey IN CNAME MB00003._domainkey.mailbox.org.
mb00004._domainkey IN CNAME MB00004._domainkey.mailbox.org.

Das ist meine konkrete Konfiguration und kein allgemeingültiges Zonefile. IP-Adressen, Mailserver, SPF-Regeln, DKIM-Selektoren und andere Records müssen natürlich durch die eigenen Werte ersetzt werden.

Noch bevor beim Registrar ein Nameserver geändert wird, sollte geprüft werden, ob deSEC die neue Zone vollständig und korrekt ausliefert. Die autoritativen Nameserver von deSEC sind:

ns1.desec.io
ns2.desec.org

Für kuketz-forum.de habe ich beide Nameserver direkt abgefragt:

DOMAIN="kuketz-forum.de"

for ns in ns1.desec.io ns2.desec.org; do
    echo "===== $ns ====="

    echo "--- Apex ---"
    dig @"$ns" "$DOMAIN" A +noall +answer
    dig @"$ns" "$DOMAIN" AAAA +noall +answer
    dig @"$ns" "$DOMAIN" MX +noall +answer
    dig @"$ns" "$DOMAIN" TXT +noall +answer
    dig @"$ns" "$DOMAIN" CAA +noall +answer

    echo "--- www ---"
    dig @"$ns" "www.$DOMAIN" A +noall +answer
    dig @"$ns" "www.$DOMAIN" AAAA +noall +answer
    dig @"$ns" "www.$DOMAIN" CNAME +noall +answer

    TESTNAME="dns-migration-wildcard-test-$(date +%s)"

    echo "--- Wildcard-Test: $TESTNAME.$DOMAIN ---"
    dig @"$ns" "$TESTNAME.$DOMAIN" A +noall +answer
    dig @"$ns" "$TESTNAME.$DOMAIN" AAAA +noall +answer

    echo "--- DMARC ---"
    dig @"$ns" "_dmarc.$DOMAIN" TXT +noall +answer

    echo "--- mailbox.org DKIM ---"
    for i in 1 2 3 4; do
        dig @"$ns" "mb0000${i}._domainkey.$DOMAIN" CNAME +noall +answer
    done

    echo
done

Auch hier sind die letzten DKIM-Abfragen spezifisch für meine Konfiguration und müssen gegebenenfalls angepasst oder entfernt werden.

Jetzt sollten die Ergebnisse mit der bisherigen Zone verglichen werden. A, AAAA, MX, TXT, CAA, CNAME, Wildcards und alle tatsächlich verwendeten Subdomains müssen auf beiden Seiten übereinstimmen. Erst wenn beide deSEC-Nameserver die erwarteten Daten ausliefern, geht es weiter.

Dieser Schritt ist besonders wichtig, wenn die Domain beim bisherigen DNS-Anbieter bereits mit DNSSEC abgesichert ist. Bei DNSSEC befindet sich in der übergeordneten Zone ein DS-Record, der die Vertrauenskette zur darunterliegenden Domain herstellt. Bei kuketz-forum.de liegt dieser DS also in der .de-Zone. Wird nun einfach der DNS-Anbieter gewechselt, verwendet deSEC andere DNSSEC-Schlüssel. Ein noch vorhandener DS des bisherigen Anbieters würde dann nicht zu den neuen Schlüsseln und Signaturen passen. Validierende Resolver können die Domain in diesem Zustand mit SERVFAIL ablehnen.

Für einen einfachen Umzug ohne Multi-Signer-Verfahren habe ich deshalb zunächst DNSSEC beim bisherigen Anbieter deaktiviert. Anschließend habe ich nicht einfach gewartet oder darauf vertraut, dass die Änderung schon angekommen sein wird, sondern direkt bei den autoritativen Nameservern der .de-Zone geprüft:

DOMAIN="kuketz-forum.de"

for ns in a.nic.de f.nic.de l.de.net; do
    echo "===== $ns ====="
    dig @"$ns" "$DOMAIN" DS +noall +comments +answer +authority
done

Entscheidend war bei allen drei Abfragen:

ANSWER: 0

Es durfte also kein DS-Record für kuketz-forum.de mehr vorhanden sein. Damit ist die Domain vorübergehend nicht durch DNSSEC abgesichert. Bei diesem einfachen Migrationsverfahren ist das beabsichtigt. Wer eine durchgehend bestehende DNSSEC-Vertrauenskette benötigt, muss stattdessen einen aufwendigeren Schlüsselwechsel beziehungsweise ein geeignetes Multi-Signer-Verfahren verwenden.

Die Nameserver sollten erst umgestellt werden, wenn der alte DS tatsächlich aus der Parent-Zone verschwunden ist.

Nachdem der alte DS verschwunden war, habe ich bei netcup für die Domain externe Nameserver eingetragen:

ns1.desec.io
ns2.desec.org

Die Domain selbst bleibt weiterhin bei netcup registriert. Geändert wird lediglich die Delegation der DNS-Auflösung. IPv4- oder IPv6-Adressen müssen für diese Nameserver nicht als Glue Records eingetragen werden. Glue wird insbesondere benötigt, wenn die Nameserver innerhalb der Domain liegen, die gerade delegiert wird. Das ist bei kuketz-forum.de und ns1.desec.io beziehungsweise ns2.desec.org nicht der Fall.

Bei einer .de-Domain lässt sich anschließend direkt bei DENIC kontrollieren, ob die neue Delegation angekommen ist:

DOMAIN="kuketz-forum.de"

for ns in a.nic.de f.nic.de l.de.net; do
    echo "===== $ns ====="
    dig @"$ns" "$DOMAIN" NS +noall +authority
done

Das Ergebnis sollte die deSEC-Nameserver zeigen:

kuketz-forum.de.  86400  IN  NS  ns1.desec.io.
kuketz-forum.de.  86400  IN  NS  ns2.desec.org.

Wenn die abgefragten .de-Nameserver diese Delegation ausliefern, ist die Änderung in der .de-Zone angekommen. Die hier verwendeten DENIC-Server gelten natürlich für .de-Domains. Bei anderen Top-Level-Domains muss entsprechend bei den autoritativen Nameservern der jeweiligen Parent-Zone geprüft werden.

deSEC signiert die Zone automatisch. Damit ein validierender Resolver den Signaturen auch vertrauen kann, muss nun wieder die Vertrauenskette von der übergeordneten Zone zur eigenen Domain hergestellt werden. Die dafür benötigten Informationen zeigt deSEC bei der jeweiligen Domain an. Für kuketz-forum.de waren das:

DS:
48649 13 2 ab6391a5309b80ac765a54b0046e50d058d66b823e9b01fe3a34bcd176d06e39

DNSKEY:
257 3 13 xYam/6iZwRzXjGMeCLX8vrpQkv9R43YZLVF40TmDpWhN3CUOLlHARm/zTZ08/byIbdA2EAqACRLo31qmHM3Y5A==

Der hier abgebildete DNSKEY ist ein öffentlicher Schlüssel. Er enthält kein geheimes Schlüsselmaterial. Resolver müssen diesen Schlüssel sogar abrufen können, um die DNSSEC-Signaturen zu überprüfen. Der zugehörige private Schlüssel verbleibt bei deSEC und wird für die Signierung der Zone verwendet.

Welche Informationen beim Registrar eingetragen werden müssen, unterscheidet sich je nach Anbieter. netcup erwartet in seiner Oberfläche den DNSKEY beziehungsweise dessen Bestandteile. Bei kuketz-forum.de waren das:

Public Key:
xYam/6iZwRzXjGMeCLX8vrpQkv9R43YZLVF40TmDpWhN3CUOLlHARm/zTZ08/byIbdA2EAqACRLo31qmHM3Y5A==

Flags:
KSK (257)

Algorithm:
ECDSAP256SHA256 (13)

Diese Werte dürfen nicht aus diesem Artikel übernommen werden. Jede Domain besitzt eigene DNSSEC-Schlüssel. Verwendet werden ausschließlich die Werte, die deSEC für die eigene Domain anzeigt. Nach dem Speichern beim Registrar habe ich erneut direkt bei DENIC kontrolliert, ob der neue DS in der .de-Zone angekommen ist:

DOMAIN="kuketz-forum.de"

for ns in a.nic.de f.nic.de l.de.net; do
    echo "===== $ns ====="
    dig @"$ns" "$DOMAIN" DS +noall +answer
done

Bei kuketz-forum.de erschien anschließend:

kuketz-forum.de. 86400 IN DS 48649 13 2 AB6391A5309B80AC765A54B0046E50D058D66B823E9B01FE3A34BCD176D06E39

Der ausgegebene DS muss mit dem von deSEC angegebenen DS übereinstimmen. Groß- und Kleinschreibung des hexadezimalen Hashwerts spielt dabei keine Rolle. Damit war die neue DNSSEC-Vertrauenskette hergestellt.

Zum Schluss reicht es nicht, lediglich zu prüfen, ob die Domain irgendeine Antwort liefert. Entscheidend ist, ob validierende Resolver die komplette DNSSEC-Kette erfolgreich überprüfen können. Dafür habe ich Quad9, Cloudflare und Google verwendet:

DOMAIN="kuketz-forum.de"

for dns in 9.9.9.9 1.1.1.1 8.8.8.8; do
    echo "===== $dns ====="
    dig @"$dns" "$DOMAIN" A +dnssec +noall +comments +answer
done

Bei erfolgreicher DNSSEC-Validierung findet sich im Header unter anderem:

status: NOERROR
flags: qr rd ra ad

Interessant ist dabei das Flag ad. Es steht für »Authenticated Data« und zeigt in diesem Fall, dass der Resolver die DNSSEC-Validierung erfolgreich durchgeführt hat. Bei meiner Migration sah das unmittelbar nach der Umstellung allerdings noch nicht bei allen drei Resolvern gleich aus. Quad9 und Google lieferten bereits:

status: NOERROR
flags: qr rd ra ad

Cloudflare antwortete dagegen zunächst:

status: SERVFAIL

Die erweiterte Fehlermeldung war in diesem Fall besonders hilfreich:

EDE: 22 (No Reachable Authority): (at delegation kuketz-forum.de.)
EDE: 23 (Network Error): (46.38.225.225:53 returned REFUSED for kuketz-forum.de A)

Die angegebene IP-Adresse gehörte zu einem bisherigen autoritativen netcup-Nameserver der Domain. Cloudflare versuchte zu diesem Zeitpunkt also noch, kuketz-forum.de über die alte Delegation aufzulösen, während Quad9 und Google bereits die neue deSEC-Zone erreichten und deren DNSSEC-Signaturen erfolgreich validierten.

Das ist ein gutes Beispiel dafür, warum man nach einer DNS-Umstellung nicht sofort an der Konfiguration herumschrauben sollte, nur weil ein einzelner Resolver ein anderes Ergebnis liefert. DNS arbeitet mit Caches und TTLs. Bei kuketz-forum.de hatte die Delegation eine TTL von 86400 Sekunden, also 24 Stunden. Entsprechend lange können alte Informationen bei einzelnen Resolvern noch vorhanden sein.

Wenn die Parent-Zone bereits korrekt auf deSEC delegiert, der dort veröffentlichte DS exakt mit deSEC übereinstimmt und andere validierende Resolver bereits NOERROR samt ad liefern, sollte zunächst geprüft werden, ob der abweichende Resolver noch mit alten Delegationsdaten arbeitet. Genau das ließ sich in meinem Fall anhand der EDE-Fehlermeldung erkennen. Nach Ablauf der entsprechenden TTL sollte die Abfrage erneut durchgeführt werden.

Der eigentliche Wechsel des DNS-Hosters ist schnell erledigt. Kritisch wird es vor allem dann, wenn DNSSEC bereits aktiv ist. Hier sollte man nicht einfach Nameserver und Schlüssel gleichzeitig austauschen und anschließend hoffen, dass alles funktioniert.

Für meinen Umzug hat sich folgende Reihenfolge bewährt:

1. Bestehende DNS-Zone beim bisherigen Anbieter möglichst vollständig erfassen.
2. Öffentlich ausgelieferte Records zusätzlich direkt beim bisherigen autoritativen Nameserver kontrollieren.
3. Domain bei deSEC anlegen und sämtliche Records übernehmen.
4. Neue Zone direkt über ns1.desec.io und ns2.desec.org prüfen.
5. Bestehendes DNSSEC beim bisherigen Anbieter deaktivieren.
6. Prüfen, dass der alte DS tatsächlich aus der Parent-Zone verschwunden ist.
7. Nameserver beim Registrar auf deSEC umstellen.
8. Neue Delegation direkt in der Parent-Zone kontrollieren.
9. DNSSEC mit den von deSEC bereitgestellten Daten beim Registrar wieder aktivieren.
10. Prüfen, dass der neue DS korrekt in der Parent-Zone veröffentlicht wurde.
11. DNSSEC abschließend über mehrere validierende Resolver testen.

Statt nach einer Änderung einfach eine bestimmte Zeit abzuwarten, habe ich jeweils geprüft, ob sie tatsächlich angekommen ist. Bei .de-Domains geht das recht einfach, da sich sowohl die Delegation als auch der DS direkt bei den autoritativen Nameservern von DENIC abfragen lassen.

Nach der Migration bleibt netcup in meinem Fall Registrar der Domain. Lediglich das DNS-Hosting wandert zu deSEC. Das ist eine saubere Trennung und hat zusätzlich den Vorteil, dass ein späterer Registrarwechsel nicht automatisch wieder einen Wechsel der DNS-Infrastruktur bedeutet.

Wer deSEC verwendet und den Betrieb unterstützen möchte, kann das Projekt mit einer Spende unterstützen.

Über den Autor | Kuketz

Als freiberuflicher Pentester und Sicherheitsforscher bei Kuketz IT-Security untersuche ich IT-Systeme, Webanwendungen sowie Android- und iOS-Apps auf Schwachstellen. Darüber hinaus lehre ich IT-Sicherheit an der DHBW Karlsruhe, gebe Workshops und Schulungen und halte Vorträge auf Fachveranstaltungen. Als Autor schreibe ich unter anderem für c’t. Meine Arbeit und der Kuketz-Blog werden regelmäßig in Medien wie heise online, Spiegel Online und der Süddeutschen Zeitung aufgegriffen.

Mehr Erfahren ➡

Unterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leser ermöglicht. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Neue Beiträge bekommst du per Mastodon, RSS oder E-Mail.