Domainumzug mit Hindernissen
Wenn wir einen Domainumzug von uns weg haben, gibt es i.d.R. erstaunte Gesichter ob der Warnung "Die Domain ist mit DNSSEC geschützt, bitte setzen Sie sich mit uns vorab in Verbindung, um einen Ausfall der Domain beim Umzug zu vermeiden." Und nun gab es mal einen Fall, bei dem der neue Provider ebenfalls DNSSEC einsetzte. Mit fatalen Folgen.
Eigentlich ist ein Domainumzug zu einem anderen ISP einfach. Man führt einen KSK und ZSK-Rollover aus und wechselt zwischendrin die Nameserver. Das Vorgehen ist üblicherweise:
- Man bekommt die neuen DNSKEYs vom neuen Provider und hängt sie in die Zone auf den alten Servern.
- Man fügt den neuen KSK bei der Registry als weiteren DS (Trust Anchor) ein.
- Der neue Provider hängt die alten DNSKEYs in seine Zone.
- Ist alles lange genug draußen, wechselt man die Nameserver per Domainumzug. Alte Records können weiterhin validiert werden, neue Records aber auch mit den alten DNSKEY/DS Einträgen.
- Ist alles lange genug draußen, löscht der neue Provider die alten Keys in der Zone und den alten DS in der Registry.
In diesem Fall war es aber ganz anders. Zum einen war die Zone schon beim neuen Provider, nur die Nameserver zeigen noch zu uns.
Spontaner Tod
Zum anderen löste die Zone direkt nach dem Einfügen des neuen DS (Verweis auf den neuen DNSKEY) bei der Registry nicht mehr auf. Die Resolver meldeten SERVFAIL.
- Die Webseiten konnten hinter validierenden Resolvern nicht mehr abgefragt werden.
- Es konnten keine E-Mails mehr zugestellt werden, da viele Mailserver DANE/TLSA einsetzen und dafür DNSSEC validieren.
- …
Ein Blick auf DnsViz offenbarte, daß die Signaturechain in Ordnung ist, die Zone aber als bogus angesehen wird.
Die Begründung lautet, die DNSKEYs würden nicht zu den DS Einträgen passen.
Ja, was zur Hölle? Die sollen auch nicht passen! Das ist ein Umzug.
Der Blick in den Standard hilft aber der Wahrheitsfindung:
There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any).
Das bedeutet schlicht, daß für jedes Cryptroverfahren, das vom Parent signalisiert wird, auch in der Zone ein aktives Schlüsselpaar vorliegen muß.
Sinn der Maßnahme ist es, Downgrade Angriffe zu verhindern. Würde man diese Forderung nicht stellen, könnte ein Angreifer ein noch vorhandenes unsicheres Verfahren ausnutzen und die sicheren Verfahren einfach ausfiltern.
In diesem Fall erfolgte ein Wechsel von RSASHA1 zu RSASHA256. Die Zone auf den alten Servern hatte nur das RSASHA1 Verfahren, die neue Zone nur RSASHA256.
Lessons learned
- Einen Umzug kann man nur machen, wenn beide die gleichen Algorithmen benutzen.
- Algorithmenwechsel ohne vollständige Kontrolle der private Keys gehen nicht.
- Man ist nie zu alt, um Neues zu erfahren.
- Man ist nie zu jung, um Bekanntes zu vergessen.
Das Problem ist natürlich bekannt. Switch.ch hat es ausführlich beschrieben, ohne dabei auf die Problematik eines Umzugs einzugehen.
Und natürlich passiert das auch anderen. Hier das gleiche Phänomen bei der NASA am 2.10.2015.
Aber es ist keine Entschuldigung.