Das eine ist die DNS Verwaltung beim Provider.
Hier ist der CNAME nur eine Vereinfachung, man kann genauso überall feste A-Records eintragen.
Die Überlegung ist da nur, dass man eben für example.com einen A-Record anlegt und für alle weiteren sub.example.com die ebenfalls auf diese IP auflösen sollen nur noch CNAME TXT Einträge auf example.com
Sollte sich die IP mal ändern muss man dann nur einen A record anpassen.
Damit werden in beiden Fällen erst mal alle anfragenden Clients für die definierten Domains in Richtung deines Anschlusses geschickt.
Und je nach Firewall und Portfreigaben landen die Anfragen dann auf der DS.
Dann ist die Frage, was die DS mit diesen Anfragen macht.
Im Werkszustand sind keinerlei Hostnamen definiert und auch die Web Station nicht installiert.
Kommst du also, egal über welchen Namen du anfragst, via 80/443 auf die DS greift die Automatik und leitet dich auf den DSM Login um (Ports unter Systemsteuerung > Netzwerk > DSM Einstellungen).... weil, wo sollte man auch sonst hin wollen...
Hat man die Web Station installiert landet die Anfrage landet die Anfrage dort auf der Dummy Seite (weil man dort vermutlich hin will, DSM dann nur via expliziter Portangabe).
Sobald man vHost in der Web Station, oder eine benutzerdefinierte Domain (Systemsteuerung > Netzwerk > DSM Einstellungen), oder einen Reverse Proxy (Systemsteuerung > Anwedungsportal > Anwendungen oder Reverse Proxy) definiert wird für diese Host/Domainnamen praktisch ein "Filter" in das Anfrage-Prozedere zwischen geschaltet.
Es wird also bei den Anfragen geprüft (SNI, Server Name Indication vom anfragenden Browser) ob diese für einen der definierten Hostnamen ist.
Wenn ja, dann wird die Anfrage dorthin weitergegeben/verarbeitet.
Wenn nicht geht sie den Weg wie oben beschrieben ohne Hostnamen.
Ist sozusagen die Kehrmaschine, die rote Laterne, ... kurz alles was nicht anderweitig spezifiert ist landet auf dem allgemeinen Web Server (also was im doc root unter /web liegt).
Sprich ohne vHost landet
www.example.com und example.com dort, also z.B. bei /web/index.html
Als Zertifikat würde jenes ausgeliefert welches für "Systemvoreinstellung" konfiguriert ist.
Der ganze andere Kram (vHost, Reverse Proxy, benutzerdefinerte Domains, etc) kommt jetzt erst ins Spiel, wenn man
- mehrere Seite Hosten will die nicht direkt in /web sondern /web/Site1 etc liegen
- man verschiedene PHP-Versionen, web-server, etc für verschiedene Projekte definieren will
- man die Domains einzeln mit Zertifikaten versehen will und nicht alle in einem unterbringen will
- man diverse Dienste über Subdomains erreichen will (bsp ds.example.com als benutzerdefinierte Domain (Systemsteuerung > Netzwerk > DSM Einstellungen) auf 80/443 lauschen lassen will. Reverse proxy auf localhost
ort ist ein weiterer Weg für dieses Beispiel)
- man....
Und trotz der ganzen Komplexität gibt es noch Sachen für die man lieber selber auf die Konsole absteigt und webserver/host-configs direkt anpasst/ergänzt.
P.S. Will man wissen warum eine Anfrage wie/wo landet muss man eben die ganze Anfrage-Kette vom Client aus nacheinander durchgehen und prüfen wer sie wie wo beeinflusst/verändert. Da sind eben einige Parteien beteiligt. Am Ende dann auch noch der Nutzer, der mal hier für ein Test eine .htaccess hingelegt hat und vergessen hat, die dann einen Apache Host aus dem tritt bringt, aber keinen der unter nginx läuft. etc.
Da kann man viel Spaß haben...
