Als ik kijk naar mijn DNS instellingen op het freedom service paneel kom ik de volgende regel tegen:
mail CNAME webmail.freedom.nl.
Dit is een default, dus niet door mij zelf toegevoegd. Als ik het goed begrijp is de bedoeling daarvan dat als ik als URL opgeef
mail.mijndomein.nl
dat ik uitkom op webmail.freedom.nl.
Dit werkt niet. Safari geeft aan mail.mijndomein.nl te kennen, maar het certificaat is verlopen. Het (letsencrypt) certificaat is voor *.caldav.soverin.nl en inderdaad al maanden verlopen.
Als ik vervolgens aangeef toch naar de site te willen komt er een 404 pagina.
Het lijkt er op dat er iets bij soverin niet goed is ingeregeld en dit daarom niet werkt. Als het niet de bedoeling is dat het werkt, dan lijkt mij dat dit (default) CNAME record nutteloos is.
Die CNAME op eigen domein leek mij ook (ooit) bedoeld als site verwijzing… dat echter i.c.m. “website” op onze eigen domeinen nu wat anders werkt.
Om jouw mail.domain.nl door te verwijzen kun je een redirect website inrichten.
Ik ga geen lang(er) verhaal houden dat hier op Stackoverflow staat uitgelegd.
NB: ik gebruik de redirect via _layouts die werkt. De permalink(jekyll) methode kreeg ik niet aan de gang. (linkvoorbeeld weggehaald omdat ik geen traffic wil hebben)
Ik denk dat men bij Freedom en ws eerder bij Soverin mogelijk (nog) ergens druk doende is omdat ik bij mijn website/dns testen op detail soms wat andere resultaten krijg.
Los van fout certificaat wordt een onbekend subdomein - default - dan soms wel, soms niet geredirect erc.etc…
Op de website is een standaard template actief die sites met(CNAMES binnen de domein/freedom/soverin scope) zonder expliciete “website” definitie, redirect naar https://soverin.net/ (wat jezelf kunt aanpassen naar iets anders).
Ik krijg de indruk dat wanneer ik een (qua dns) onbekend subdomein gebruik waarvoor ook geen website is, dit door Soverin wordt afgevangen en omgeleid naar de universele redirect template (van websites) DAT echter eerst moet worden “verwerkt” op/door de Soverin server voordat het actief resulteert in de standaard redirect.
Een niet-bestaand subdomein komt in een soort queue dat moet worden verwerkt.
Ik denk ook dat we (ik) ook op een bewegend doel aan het schieten zijn en mogelijk wat pionierend geduld moet oefenen.
Onduidelijk voor mij is of de ‘helpdesk’ hier actief meeleest.