Alternative Methode zur Domainverifizierung anbieten

[tehplague]

Welches Problem möchtest du lösen? Wann tritt es auf?
Aktuell muss ich eine Domain, die ich auf ein Projekt bei Mittwald aufschalten will, per DNS-Record verifizieren, um meine Eigentümerschaft nachzuweisen. Das passiert über einen TXT-RR im DNS, der auf eine von Mittwald gewürfelte Challenge gesetzt wird.
Sobald ich allerdings ein CDN wie AWS CloudFront vor das Mittwald-System schalten möchte, muss ich für die Projektdomain regelmäßig einen CNAME-RR auf das CDN setzen, also z.B. so:

www.marketing-factory.de. 7200  IN      CNAME   d1taqcj5s8jjee.cloudfront.net.

Sofern für eine Domain allerdings ein CNAME-RR existiert, ist nach RFC1034, Abschnitt 3.6.2, vorgesehen, dass keine weiteren Records existieren.

If a CNAME RR is present at a node, no other data should be present

Die Einrichtung eines parallelen TXT-Records schließt sich somit aus. Aktuell lösen wir das, indem wir statt www.marketing-factory.de entsprechend marketing-factory.de bei Mittwald anlegen. Denn Mittwald erlaubt die Anlage beliebiger Subdomain ohne hierfür eine erneute Verifizierung vorauszusetzen. Das führt allerdings zu unschönen Effekten, weil das System dann für die übergeordnete Domain versucht, auch z.B. TLS-Zertifikate zu holen, was zu einer Vielzahl von Störmeldungen im mStudio führt, die in der Praxis ohne Relevanz sind.

Um kompatibel mit CDNs (und anderen Diensten) zu sein, für die ich die Domain zunächst per CNAME woanders hin als zu Mittwald zeigen lassen müsste, braucht es also einen anderen Weg.

Welche Lösungsideen hast du?
Eine mögliche Idee wäre es, die Verifizierung über die Einrichtung einer von Mittwald vorgegebenen Subdomain durchzuführen. Mittwald hält dann intern einen nur Mittwald bekannten Salt (im Beispiel den String salt) und berechnet dann z.B.

'_' + SHA256('salt|' + 'www.marketing-factory.de') -> '_cc959f2fef235d7d768d056f5c09070c8e136694b2638eb3cef9c0e32b4f4be2'`

Der Kunde trägt dann den TXT-RR für diese Subdomain ein, also z.B.

_cc959f2fef235d7d768d056f5c09070c8e136694b2638eb3cef9c0e32b4f4be2.www.marketing-factory.de. 7200  IN      TXT   "domainVerification=foo".

Mittwald könnte bei der Prüfung sowohl auf der Domain selbst, als auch auf der vorgegebenen Subdomain abfragen, sodass man mit nur einer zusätzlichen DNS-Query mit diesem Verhalten auch abwärtskompatibel zum Bestand wäre.

Hast du zusätzliche Informationen (wie z.B. Screenshots)?
Link zur RFC1034