Subdomains, A NAME, Sicherheit und Routing

325
user863791

HINWEIS: Ich bin ein Berater für Marketingstrategie und kein Technologieberater.

Ich habe einen Kunden, für den wir die Cloud-Hosting-Lösung eines Drittanbieters verwenden, um kleine (einzelne Seiten) Websites für seine Kunden zu erstellen. Im Endkundenbereich wird es für alle Kunden sehr schwierig sein, einen eigenen MyWebSite.com-Namen zu erhalten. Dies ist ein Grund, warum mein Kunde für diese Sites Subdomains verwenden möchte: XYZ.MyClient.com. Endkunden sind mit dieser Lösung gut aufgestellt, was wir gesehen haben.

Das von uns verwendete Cloud-Hosting-Unternehmen eines Drittanbieters sagt, wir sollten nur einen Wildcard-A-NAME (z. B. * .MyClient.com) verwenden. Dies leitet den gesamten Unterdomänenverkehr über seine Plattform und an die richtige Site weiter, ohne die Hauptdomäne von zu beeinträchtigen alle (www.MyClient.com).

Die Outsourcing-Firma meines Kunden behauptet, nein, diese Wildcard-Lösung leitet den gesamten Datenverkehr von www.MyClient.com durch die Drittanbieter-Hosting-Firma, bevor sie zur richtigen Site gelangt. Sie behaupten, dass die beste Lösung darin besteht, einen A-NAME-Datensatz für jede Subdomäne zu erstellen und diese für Hunderte von Websites zu verwalten.

Ich brauche nur Antworten, um die Diskussion zwischen allen Beteiligten zu erleichtern - es ist mir egal, was die Antwort ist. Ich möchte nur, dass mein Kunde eine sichere, überschaubare und kostengünstige Lösung hat. Meine Fragen sind dann:

  1. Wird ein A NAME-Platzhalter-Ansatz tatsächlich den Kern von www.MyClient.com durch das Hosting-Unternehmen eines Drittanbieters leiten?
    1. Wenn ja, warum ist das ein Problem? Verzögern? Sicherheit? Andere?
    2. Ich habe an anderer Stelle gelesen (es war ein 5 Jahre alter Beitrag), dass es gut wäre, ein separates Sicherheitszertifikat für die Einrichtung der Unterdomäne zu haben. Ist das so? Wenn ja, kann mir jemand einen guten Hinweis geben?
    3. Das Verwalten von Hunderten von A NAME-Datensätzen für Subdomains scheint mir eine Menge Arbeit zu verursachen, die sich für Fehler und Nacharbeit eignet. Wahr oder nicht?
    4. Fehlt mir etwas?

Vielen Dank

0
https://tools.ietf.org/html/rfc4592#section-2.2.1 enthält Informationen zu dieser Problemkategorie. Ich möchte lieber nichts anderes schreiben, um Fehler zu vermeiden A.B vor 6 Jahren 1

1 Antwort auf die Frage

1
grawity

Wird ein A NAME-Platzhalter-Ansatz tatsächlich den Kern von www.MyClient.com durch das Hosting-Unternehmen eines Drittanbieters leiten?

Nein. Bestehende spezifische Namen haben immer Vorrang vor Platzhaltern. (Siehe "Existenzregeln" in dem zuvor verknüpften RFC 4592. )

Wenn ja, warum ist das ein Problem? Verzögern? Sicherheit? Andere?

Verzögern Sie und erzwingen Sie eine gewisse Bandbreite für den Drittanbieter, da der gesamte Datenverkehr an Ihren echten Webserver weitergeleitet werden muss. (Ich bin bereit zu wetten, dass sie einfach nicht das tun werden.)

Und natürlich hat der Drittanbieter die volle Kontrolle über den Inhalt Ihrer Hauptwebsite. Dies ist auch dann unerwünscht , wenn Sie den Webseiten Ihrer Kunden bereits vertrauen.

Ich habe an anderer Stelle gelesen (es war ein 5 Jahre alter Beitrag), dass es gut wäre, ein separates Sicherheitszertifikat für die Einrichtung der Unterdomäne zu haben.

Ich weiß nicht viel darüber, aber im Wesentlichen haben Sie drei Möglichkeiten:

  • Stellen Sie für jede Unterdomäne ein neues Zertifikat aus. Mit Let's Encrypt heutzutage durchaus möglich, und der Drittanbieter kann dies selbst tun.
  • Stellen Sie einige Zertifikate aus, von denen jedes für einige Dutzend Subdomains gleichzeitig gültig ist. Dies wurde in der Vergangenheit (vor LE) getan, ist aber wahrscheinlich am schwierigsten im Vergleich zu halten.
  • Stellen Sie ein Platzhalterzertifikat für aus *.myclient.com. Obwohl es am einfachsten zu verwalten ist, kostet es mehr und macht es theoretisch für den Host eines Drittanbieters einfacher, sich als wwwSubdomain auszugeben. (Es ist jedoch ein etwas gestrecktes Argument; die gleichen Probleme gibt es sowieso bei LE.)

Das Verwalten von Hunderten von A NAME-Datensätzen für Subdomains scheint mir eine Menge Arbeit zu verursachen, die sich für Fehler und Nacharbeit eignet. Wahr oder nicht?

Das größte Problem, das ich mit direct A/ AAAArecords sehen kann, ist, dass es ziemlich ärgerlich wäre, alle zu aktualisieren, wenn sich die IP-Adresse des Servers ändert. Wenn all diese Subdomains CNAMEs (Aliase) sind, wird dies einfacher, da nur eine einzige Domain (das CNAME-Ziel) aktualisiert werden muss.

Die Anzahl der Subdomains scheint jedoch im Allgemeinen kein Problem zu sein - solange ihre Erstellung und Löschung eindeutig als Teil des Verfahrens zur Einrichtung eines neuen Clients definiert wird. (Das heißt, wenn Ihr System es nicht vollständig automatisieren kann, wenn Sie die Webseite eines neuen Kunden aufrufen ...)

Dennoch wäre ein Platzhalter noch einfacher.