Dan maakt de computer er - zoals bij mij - een https versie van . Kij maar boven in de adresbalk. Een kopie wat erbij mij te zien toenn ik grokipedia aanklikte : >>> https://grokipedia.com/ Controleer je ook het slotje?? wat verschijnt !!

Volgens mij zit hier een denk fout. Er is wel degelijk een https versie van grokipedia.com. Een eenvoudig search laat dit al zien.

Wat ik me overigens wel afvraag is waarom je naar 126.0.1.1 verwijst, dit gaat dan naar een ip adres van een Japanse bank.

Waarom heeft u het ip adres van Softbank uit Japan in uw host file staan?
Dit snap ik niet
Sowieso is het handiger om domeinen in te voeren zonder www. Dan blokkeert u het hele domein (moet men wel 127.0.0.1 o.i.d. gebruiken...).

Bij mij laadt grokipedia.com gewoon met https, dus waarom het bij u niet beschikbaar is weet ik niet.

Je host lijst doet helemaal niets met html extensions of tls, je hebt de tweede keer gewoon een nieuw domein opgegeven.
eerst grokipedia.com en later www.grokipedia.com. Alles wat in je hostfile staat wordt gestuurd naar het adres dat je daar opgeeft, of dat nu http of https of iets anders is.

126.0.1.1 is een raar IP, dit is volgens mij geen gereserveerd lokaal ip, dus er kan daadwerkelijk ooit iets antwoord op geven.

Voor wat betreft de vraag: Komt dit misschien door een feature zoals DNS over HTTP (DoH)?
Ik ben wel benieuwd wat er gebeurt als je het IP wijzigt in 127.0.1.1, misschien dat firefox voor die resolving een uitzondering heeft en zaken als DoH skipt.

Heb je na de wijziging de browser volledig herstart? (Of misschien zelf linux). Misschien dat je tegen gecachte data aan zit te kijken (of pagina, of DNS), dat bijv. firefox al wist waar ie de HTTPS variant kon vinden, maar de HTTP variant niet.

Verder: Geen idee.

Je haalt hier twee zaken door elkaar.
DNS (en daarmee ook een host bestand) vind helemaal niks van poorten (of protocollen).
Het is een telefoonboek voor het vertalen van URL's naar IPadressen, niet meer, niet minder.

Wat wel kan, en dat voorbeeld geef je zelf al aan in bovenstaand bericht, er zit een verschil tussen www.grokipedia.nl en grokipedia.nl, die kunnen gerust naar een ander IP adres verwijzen. Meestal is een www. een CNAME record voor het toplevel domein, maar dat is geen verplichting.

In jou geval: het kan prima zijn dat een HTTP verbinding een harde forward doet naar de HTTPS versie van de website. Als de de laatste dan wél in je host file dicht zet heb je kans op dergelijk gedrag.

Ten eerste valt me op dat je de ene keer meldt dat je www.grokipedia.com aan dat IP-adres koppelt en de andere keer zonder www ervoor. Weet je zeker dat je wat je in de browser intikte wel in je hosts-file had afgevangen?

Ten tweede is de IP-reeks die op je eigen pc wordt afgebeeld niet 126.*.*.* maar 127.*.*.*, dus met 126.0.1.1 verwijs je naar een IP-adres dat gewoon op het internet bestaat, maar dat bij mij geen response geeft op http of https:

En waarom grokipedia.com wel wordt geladen? Als je in je hosts-file wel www erbij hebt staan is het nogal wiedes dat grokipedia.com zonder www ervoor naar de echte grokipedia verwijst, die heb je dan namelijk niet in je hosts-file afgevangen. En als ik "grokipedia.com" zonder meer invul in mijn adresbalk krijg ik direct Grokipedia te zien. Dubbelklik ik op de adresbalk dan laat die zien dat de browser er https:// voor had gezet. De browser kiest tegenwoordig default voor https als je het niet expliciet vermeldt.

Neem dit eens in je hosts-file op:
Als je andere verwijzingen naar 126.*.*.* hebt zou ik die ook aanpassen.

Er is door iemand die hier node wordt gemist voor zijn zeer verhelderende bijdragen al vaker op gewezen dat het slotje niets met veilig te maken heeft. Maar dat terzijde.

Waar het mij om gaat is dat de normale invoer van een niet gewenste websites in de hostfile wordt genegeerd als het een niet gecodeerde, dus http site betreft.

Voorzover ik zie werkt het invoeren van alleen de domeinnaam niet, dus zonder www. ervoor. De bedoeling van de hostfile is toch dat er zelfs niet een request kan worden gezonden van je computer naar een pagina host? Of zie ik dat verkeerd?

Ik ben totaal geen IT deskundige, En er valt mij iets op dat volgens mij niet de bedoeling is. Dat is alles.

Hier TS,
Aan allen die reageren op het IP adres.
Mijn excuses voor de misverstanden. Ik tikte per abuis een 6 i.p.v. een 7.

In elk geval dank voor alle reacties. Ik ga ze doorlezen.

P.s. Ik was een reactie aan het opstellen nadat er 1 was, niet meer. Nadat ik mijn reactie had gepost stonden er na F5 ineens 7 reacties. Adequaat reageren is zo vrijwel onmogelijk.

Het feit dat iemand 126.0.1.1 gebruikt, daarvan kan je er vanuit gaan dat dat een type fout was. Het ligt zo dichtbij 127.0.1.1 dat men echt een fout gemaakt heeft, dus alle reaktie's ten spijt, ik denk dat diegene die dit bericht gestart is dat ook gewoon weet. Ik zou trouwens geen www.grokpedia.com gedaan hebben, maar ook 127.0.0.1 grokpedia.com

Die aanname is onjuist. Webbrowsers halen de volledige domeinnaam uit de URL en zoeken daar een IP-adres bij op.

Probleem: DNS-caches in browsers en besturingssystemen (maar ook de browser-cache van webpagina's kan roet in het eten gooien). Je hebt geen zekerheid dat elke configuratiewijziging, zoals in de hosts file, direct wordt opgemerkt - temeer daar de hosts file vooral een museumstuk van vóór de tijd van DNS is.

De term "domeinnaam" kan verwarrend zijn: het kan gaan om de naam van bijv. een "server" (*), het kan gaan om een hoofddomein met één of meer subdomeinen, of beide. Niets belet de huurder van de domeinnaam security.nl om de domeinnaam www.www.security.nl te registreren (noch om er niet een webservice maar bijv. een mailservice op te draaien; het is maar een naam die wereldwijd uniek is).

(*) Lastig is dat op één server (met een specifiek IP-adres) meerdere, soms duizenden, websites kunnen "draaien" (in bijv. https://en.wikipedia.org/wiki/Server_Name_Indication staat hoe dit werkt). Daarom gebruik ik bij websites (zowel http als https) vaak de term "websitenaam" i.p.v. domeinnaam.

In het door TS beschreven geval zijn zowel grokipedia.com als www.grokipedia.com volstrekt verschillende domeinnamen (en totaal verschillende websitenamen als je ze via http of https benadert). In dit geval (zonder opname in de hosts file!) stuurt de echte https://www.grokipedia.com de browser van de bezoeker door naar https://grokipedia.com (de website met "content").

Overigens zitten beide momenteel "achter Cloudflare" (104.18.18.2 en, gespiegeld, 104.18.19.2) en beide zijn via https bereikbaar; zie bijv. het RELATIONS tabblad van https://virustotal.com/gui/domain/grokipedia.com (het voert te ver om hier uit te leggen hoe de reverse proxies van Cloudflare werken). Onderaan die pagina zie je ook de meeste (niet alle) historische certificaten.

Nee, met een regel in de hosts file geef je aan welke domeinnaan (of meerdere domeinnamen) op het gegeven IP-adres te vinden zijn.

Met de volgende regel in jouw hosts file:
geef je aan dat jouw browser verbinding moet maken met 127.0.0.1 - "localhost" oftewel jouw computer indien je een van beide websites opent in jouw browser. Als er op jouw computer geen https webservice draait, en je Firefox hebt ingesteld op "alleen https", zal jouw browser melden dat "de website" geen https ondersteunt. D.w.z. tenzij er nog oude DNS-informatie in een DNS-cache zit en de hosts file (nog) niet wordt uitgelezen.

Blokkeren met de hosts file vind ik een nogal botte-bijl methode: elke domeinnaam moet exact worden gespecificeerd (als je grokipedia.com opneemt wordt geen enkele subdomeinnaam daarvan geblokkeerd).

De meeste uitlegs hier zijn technisch juist nog steeds basaal (als we over DNS in geheel hebben) maar we kunnen het nog steeds veel korter omschrijven.

hostfile is een overschrijving van je reguliere DNS connectie.
Zegt je DNS provider x en jij zegt y in hostfile dan route hij naar y

www. is een subdomein zoals ook bijvoorbeeld mail.domein.tld is.
hostfile kan geen wildcards dat is een beperking in hoe het later is doorontwikkeld.

Omdat www een subdomein is hoeft deze niks van doen te hebben met het hoofdomein en kan via ander IP lopen.
Je moet ze dus beide routen als regel als je die twee beide wilt blokkeren want hostfile kan geen wildcards.
Omdat de www en hoofdomein ook hun eigen htaccess kunnen hebben en dus redirect opstelling en wel of niet https forceren kan je verschillen merken.


Of nog korter
Hostfile overschrijft DNS kan geen wildcard bevatten
www is een subdomein en kan afzonderlijk van hoofddomein zijn
Dus je moet per subdomein los een regelmaken naast je hoofddomein wil je zelfde routing afdwingen.


We kunnen gigantisch diep hierop in gaan tot het benoemen van de respectievelijke rfcs aan toe omzeiling beperking wildcards met proxy maar end of day is het ook belangrijk om in te schatten waar de OP het voor vraagt.

Gaat het om probleem oplossing of uitgebreid leren hoe DNS werkt.
Als laatste is dan kan men hier nog wel een boekwerk gaan schrijven.

DNS is een teringzooi aan ducttape oplossingen met uitzonderingen op uitzonderingen en had eigenlijk al jaren compleet herschreven moeten worden in een internet 2.0 Maar men is al des doods voor de economische gevolgen so we dont.

Hier TS,

Dank voor alle reacties! want daardoor kwam ik tot de conclusie dat ik twee regels moest aanmaken in de Hostfile om Grokipedia te blokkeren.


Nu krijg ik de alleen HTTPS melding, en als ik dan klik op 'doorgaan naar http website', krijg ik de melding: 'Kan geen verbinding maken'.

Uitstekend zo. :-)

P.s.
Andere discussie: Van de specifieke gang van zaken m.b.t. Grokipedia en het alleen aanbieden van de ongecodeerde (plain tekst) http-site krijg ik, net als van Musk, een nare smaak in de mond. In Grokipedia kun je - naar ik aanneem - ook bijdragen posten en die gaan dus in gewone leesbare tekst over het internet. :-[