Je browser landt via een dns op een plekje aangewezen door een webserver. Daar staat een bestand met een verwijzing. (even simpel gezegd) of een script. De browser voert deze uit omdat deze wordt aangeboden door de webserver. Plesk is dan aangeroepen in dit script of bestand. Het bestand kan html zijn of bijvoorbeeld een php script.

Even simplistisch gesteld.

De redirect wordt ingesteld door een dns beheerder, op aangeven van de websitehoster. Een host kan meerdere websites hosten er wordt dan gekeken naar een header waarin de naam van de site verwerkt is. De webserver software reageert met de pagina die bedoeld is voor deze domeinnaam.

[dns domainnaam bijv. .NL ] -> DNS domainnaam + registrar (geeft aan welke dns server) -> DNS registrar (geeft aan welke server IP de website staat en andere verwijzingen zoals SPF etc.

Een goede mogelijkheid is dat de website beheerder een goedkope "shared hosting" website heeft afgenomen bij een
hoster doe Plesk gebruikt, waarbij dus meerdere domeinnamen (van verschillende klanten) verwijzen naar het IP adres
van 1 server. Die ene server krijgt de requests binnen, zoekt de domeinnaam op in een tabel, als die gevonden is dan
stuurt ie de content voor die domeinnaam, en als die domeinnaam niet in de tabel staat toont ie die default site.

De manier waarop dit mis gaat is dat de klant (degene die de site bedrijft) het account heeft opgezegd of niet meer betaald
heeft, waardoor zijn domeinnaam uit de tabel verwijderd is door de hoster, maar de DNS verwijzing van zijn domeinnaam
naar die host niet heeft verwijderd (bijvoorbeeld omdat ie DNS ergens anders heeft ondergebracht of dit niet door de
hoster "automatisch beheerd" wordt).

M.a.w. het is een beetje een lelijke manier om te zeggen "sorry maar deze site bestaat niet meer".

En het korte antwoord is : de webhoster doet dit .


Niet je access-ISP .

Jazeker.

Maar als je een melding ziet met iets als "This page is generated by Plesk", dan is waarschijnlijk jouw browser niet zo veilig mogelijk geconfigureerd. In elk geval in Firefox kun je de "HTTPS-Only mode" aanzetten (ik gebruik de Engelstalige versie, in de Nederlandse zal dat mogelijk iets anders heten). Dan krijg je in bijna alle gevallen een certificaatfoutmelding te zien in plaats van zo'n pagina met "Plesk" o.i.d.

Niet dat het daarmee veel duidelijker wordt wat er aan de hand is. Feit is dat er op de server geen website met de gegeven domeinnaam bestaat met een geldig https servercertificaat en waarmee een versleutelde verbinding kan worden opgebouwd. Met andere woorden, vooral als niet-beveiligingsexpert doe je er verstandig aan om die site niet toch te proberen te bezoeken.

"Plesk pagina's" krijg je vooral te zien bij "shared hosting", dus waarbij meerdere websites één IP-adres gebruiken. Het doel ervan is om een beheerder in de gelegenheid te stellen om een nog niet bestaande website in te richten. Zo'n pagina krijg je dus te zien als de website nog niet bestaat, maar ook als de website niet meer bestaat op die server - maar de DNS-registratie al (of nog) wel.

Terug naar een veiliger webbrowser, er zijn 2 problemen:

1) Weglaten protocol
Als je in de adresbalk "het protocol" weglaat door bijvoorbeeld slechts ing.nl in te tikken, is het nog steeds standaard voor browsers om daar dan http:// voor te zetten vóórdat de verbinding wordt gemaakt (het uitgangspunt is dus nog steeds een onveilige verbinding naar TCP poort 80 van de webserver). Ook op TV, kranten en andere tijdschriften zie je zelden dat links voorafgegaan worden door "https://".

2) Protocol is (onbedoeld) expliciet "http://"
Links (URLs) in webpagina's, e-mails en chatberichten beginnen nog vaak met "http://" in plaats van met "https://". Bovendien bevatten veel "URL" QR-codes een link die met "http://" begint.

Als jouw browser in beide gevallen niet "http://" in "https://" wijzigt vóórdat de verbinding wordt gemaakt, kan een aanvaller die (door jouw browser ontvangen) DNS-antwoorden kan manipuleren, of toegang heeft tot jouw netwerkverbinding (zoals vaak mogelijk is bij public WiFi), jouw browser naar een andere website sturen. Dat die andere website jouw browser vervolgens vraagt om opnieuw met hem te verbinden, maar nu via "https://", helpt natuurlijk geen zier.

Of jouw browser veilig is ingesteld, kun je snel zien door http://http.badssl.com/ te openen. Een veilig geconfigureerde browser zal die URL wijzigen in https://http.badssl.com/ vóórdat de verbinding wordt gemaakt. Als jouw browser dat doet, krijg je een foutmelding te zien die je vertelt dat deze site (https://http.badssl.com/) met opzet niet bestaat.

Als jouw browser niet veilig is geconfigureerd, krijg je een rode pagina met, in witte tekst, "http.badssl.com" te zien.

Bij een veilig geconfigureerde browser hoor je dus een foutmelding te krijgen als je op http://http.badssl.com/ klikt!

Zegt het voort...

Plesk, WHM, cPanel werkt met een cgi-sys/defaultwebpage.cgi pagina deze staat zelf onder /usr/local/cpanel/cgi-sys/

Deze pagina ingesteld op de root en is een standaard pagina wanneer er geen custom index bestaat op het domein en de DNSzone is aangemaakt.

De pagina is meestal niet waard om aan te passen er staat uitgelegd wat mogelijke redenen kunnen zijn maar als beheerder kijk je toch eerder in je logs dan een generieke foutmelding. Je wilt natuurlijk ook niet een debug pagina aan elke willekeurige bezoeker tonen. Een bezoeker heeft daar eigenlijk ook niks mee te maken een account houder moet dit uitzoeken bij de server provider of de provider zelf van de server. Doe je meestal via acctinfo: https://support.cpanel.net/hc/en-us/articles/4404836032407-How-to-use-acctinfo-to-troubleshoot-issues

Dit is verder ingebakken functie je kunt dit niet uitschakelen als eigenaar. Je kan de locatie weghalen maar dan krijg je een harde error en bij een volgende versie van je paneel komt het net zo goed terug. En als je heel snel je logs en je opslag wilt vullen dan moet je vooral een default locatie verwijderen uit je server want elke bot, crawler ooit zal dan een trigger veroorzaken.

Dit gebeurt trouwens ook als je met cPanel of Plesk wanneer elke gebruiker een eigen IP gebruikt je zult het vaker zien bij een VPS maar dedicated is het niet anders bij. Het gebeurt ook bij mail only accounts.

Er is in verleden discussie geweest over de functie maar de nieuwe eigenaar van de producten GoDaddy vind dit geen prioriteit hebben en er staat ook geen revisie gepland in de huidige roadmap huidige focus is multi role management en clustering support.

Geweldig!
Dankjewel allemaal voor deze uitvoerige uitleg!

Kijk ook eens even met het tooltje DNSDataView van Nir Sofer.

#webproxy

Aanvulling op mijn post hierboven: ik snap en weet niet waarom "https only" nog niet de standaard is in webbrowsers.

Mogelijk is dat omdat sommige public WiFi-aanbieders willen dat je aanmeldt op hun portal. In plaats van dat zij daar een URL voor opgeven, kapen zij de eerste verbinding die je probeert te maken - en dat kan niet bij https.

Sowieso werkt dit niet als je begint met een website die HSTS gebruikt, en die je recentelijk hebt bezocht: dan wijzigt de browser sowieso http in https voordat de verbinding gemaakt wordt (en met HSTS is er geen mogelijkheid om te kiezen voor "doe dan maar http"). Lastig daarbij is dat je er als internetter meestal geen idee van hebt of een https website een geldige HSTS-configuratie heeft.

Onverwachte foutmeldingen bij public WiFi gerelateerd aan HSTS kun je bijvoorbeeld vinden in https://support.google.com/chrome/answer/6098869?hl=nl:
Probleem: als je jouw browser hebt ingesteld om alle verbindingen via https op te zetten, gaat 1) al fout.

Dat komt omdat jouw browser dan verbinding probeert te maken met https://example.com - en dat lukt natuurlijk niet als de WiFi-aanbieder die verbinding naar een andere website stuurt (hoewel dat WiFi aanmeld-portaal een kopie van het https servercertificaat van https://example.com naar jouw browser zou kunnen doorsturen, beschikt dat portaal natuurlijk niet over de bij dat certificaat passende private key, en dus krijg je een foutmelding).

Een belangrijk verschil met websites die HSTS ondersteunen, is dat de meeste (zo niet alle) browsers je in dit geval wél de kans geven om alsnog via http te verbinden "met die website" (niet met de opgegeven website, maar met het WiFi-portaal).

Kortom, als je jouw browser instelt op "https only" en het lukt niet om via public WiFi verbindingen te maken, tik dan een domeinnaam in waarvan je weet (of vermoedt) dat deze geen HSTS gebruikt, zoals http://example.com of http://http.badssl.com (je mag die URL's ook met https beginnen, maar dat is 1 letter extra tikken die jouw browser anders toevoegt. Sterker, je mag "http://" ook weglaten). Zodra de foutmelding verschijnt, kies je voor "toch verbinden via http" (of tekst van vergelijkbare strekking); dan zou je op het WiFi-portal uit moeten komen.

Lukt dat ook niet, raadpleeg dan de eigenaar van de public WiFi-toegang.

Nee zo werkt dat niet. Browsers of operating systems (afh van welk platform) maken ZELF de eerste verbinding in http,
kijken wat er gebeurt, en indien zij detecteren dat er een "portal" is dan laten ze je de betreffende pagina zien nog VOOR
dat ze naar de door jou ingestelde home pagina gaan (of de door jou ingetikte URL bezoeken).

Bij welke browsers en/of besturingssystemen is dat het geval, voor zover je weet?

Praktisch alle, denk ik . Omdat captive portals zo gebruikelijk zijn.

firefox :
https://support.mozilla.org/en-US/kb/captive-portal

(oude pagina, zegt dat firefox het niet kan)
https://www.intraway.com/blog/how-browser-identify-captive-portals

Mogelijk dat ze bij een blank homepage (nog) geen captive portal check doen , overigens.

Precies. Google Chrome doet dit, Microsoft Edge doet dit, Apple IOS en Android doen het zelf (zodat de browsers er niet mee opgezadeld worden), etc.
Er zijn verschillende methoden in gebruik waarvoor dus ook verschillende servers op internet draaien van de betreffende fabrikanten zelf.
Dit geeft hen uiteraard meteen "call home" faciliteiten, ze weten wanneer hun klanten hun spullen verbinden met een netwerk.