Github Microsoft c.s. is dan ook zo gemaakt & ingericht dat die het domein benoemd (met haar github-CNAME-record functie) & zo doorlaat. Onderwater wordt door GitHub het DNS record afgevraagd met iets als “dig sitename.eigendomein.nl +nostats +nocomments +nocmd” en de resulterende datawaarde wordt aan de SSG github-locatie gekoppeld die vervolgens (weer) wordt uitgespuugd op naam van het github-cname site-record). Kortom, handig hergebruiken van DNS met/voor een andere functie dan qua RFC ooit was bedoeld.
NB: dit op deze wijze via DNS doorverwijzen is specifiek GitHub & staat geheel los van een redirect functie elders. Het enige dat nodig is, is toegang tot eigen DNS instellingen om aldaar een CNAME record aan te kunnen maken op/in je eigendomein.nl die wijst naar userid.github.io. (eindigend op idd punt ) .
Voordeel@github naast “gratis” biedt Jekyll (incl markdown) ondersteuning. Jammer is dat door daar “data” te publiceren iemand mogelijk wat rechten opgeeft en gehouden is aan publicatie beperkingen (je kan geen “controversiële” uitingen doen). (–> niets is niet eens gratis).
Ik heb mijn jekyll-site er zonder aanpassingen opgezet en het werkt, op één ding na: liquidfilters in assets/css worden niet verwerkt. Maar verder loopt alles (blog entries, menu, kalender met custom data, flickr gallery).
Wanneer iemand overweegt om gebruik te maken van de GitHub doorverwijs functie, is het noodzakelijk dat men CNAME records kan aanmaken op/in het eigendomein.
Of & hoe lang dat als faciliteit formeel voor/bij Freedom beschikbaar is/blijft, is onduidelijk. Vooral omdat dat deel van DNS-beheer niet perse noodzakelijk is om e-mail functie(s) via Freedom te kunnen leveren.
Dit buiten aspecten aangaande inhoudelijk eigenaarschap, doelstelling van GitHub; die niet perse hoeven te vallen onder de geëigende jurisdictie van de EU (privacy)wetgeving.
Lees vooral GitHub Privacy Statement - GitHub Docs
→ tldr: Github doet/mag alles met afgegeven data/verkeer.
Geen enkele reden om aan te nemen dat daar ook iets in gaat wijzigen, pure speculatie die nergens op gebaseerd is. Sterker nog, nu geen (basis) website functionaliteit meer wordt aangeboden is het tegenovergestelde juist waar en is het zelf kunnen beheren van de DNS zone juist extra van belang. Bovendien is het in de lucht houden van webservers een intensievere taak dan een DNS editor in stand houden in een webapplicatie die toch al online moet staan. Dat is in principe 1x bouwen en daarna verandert daar nooit meer wat aan.
Waarom zou zonder geboden “webserver” functie, het beheren van de eigen DNS hostzone(s) belangrijker worden ?
Los of iemand het zelf als “eigen toepassing” belangrijk vindt, zie ik geen direct belang voor een provider die (server)diensten doorgeeft. Natuurlijk wel nuttig voor iemand die zelf services ergens anders wil draaien en daarvoor geen DNS kan/wil (gaan onder)houden.
Reden(en) om ergens aan te twijfelen had ik vooralsnog ook niet t.a.v. de “website” en wat andere dingetjes die met set&forget functioneerden. Ik noemde het niet zomaar omdat - mij - is aangegeven dat de leverancier zich gaat richten op verbeteren van e-mail functies en het daarmee niet voor de hand ligt dat er andere uitbreidingen komen.
Je geeft zelf het antwoord al: omdat de website dan elders gehost moet kunnen worden, bijv. op een thuis servertje of op een server elders. Nogmaals, er is geen enkele aanleiding om überhaupt maar te denken dat de DNS editor zal verdwijnen. Van een heel andere orde dan een webserver-dienst.
Dat is wat anders. Ik heb het over de DNS editor in Mijn Freedom. Jij wilt een andere functie er bij om e.e.a. via een API te kunnen verwerken. Staat daar verder los van.
Over het algemeen heeft een heel systeem (in dit geval Mijn Freedom) een API en maak je niet verschillende API’s voor alle verschillende functies. DNS is daar dan maar een onderdeel van. Maar goed, het doet niks af aan dat de DNS editor zelf prima werkt en als dat eenmaal gemaakt is zullen daar niet veel aanpassing meer aan gedaan hoeven worden. Blijkbaar is ooit de keuze gemaakt om geen API beschikbaar te stellen, omdat de resources die beschikbaar zijn om dit te maken beperkt zijn en er waarschijnlijk hogere prioriteiten zijn. Er zal maar een hele kleine groep gebruik maken van een API, waardoor het te rechtvaardigen is dat daar (op dit moment) nog geen resources in gestoken zijn. Voor particulier gebruik gaat het ook best wel ver de diepte in. Maar goed, melden aan Freedom kan altijd en dan kunnen ze het als ze er wat inzien altijd op het wensenlijstje zetten.
Het is een argumentatie dat DNS handig en/of wenselijk is voor (ook mijn) …vul-in… behoeften en we elk een zienswijze als (eigen)belang hanteren. Freedom zelf, zal daartoe zeker geen plannen hebben en leveren wat haar mogelijk is.
Het leveren van DNS dienst, staat wmb los van e-mailtoegang bieden waarop de focus - bij de mailprovider, die o.a. de editor biedt - lijkt te gaan liggen. Ik hoop ook dat er niets veranderd(e) maar kan daarvoor in voorwaarden geen zekerheden vinden.
De DNS-editor zoals die nu is, blijft met zekerheid. Onze hosting dienst is hiervan afhankelijk. Daarbij leveren wij ook domeinen los van een dienst en daar gaan wij niet mee stoppen.
Ik vermoed dat hier met “editor”, mijnFreedom wordt genoemd waarmee momenteel de A/CNAME records in DNS worden bewerkt als noodzakelijk voor webhosting.
//–//
De webhoster - hier Procolix - zal via de Plesktool, de NGINX (multi)hostconfiguratie inrichten om websiteverzoeken namens een eigendomein bij Freedom af te handelen. CNAME-record zijn nodig om een sub/website bij Procolix uit te laten komen en A-records vooral om certificaten daarvan te kunnen vestigen.
Nope. CNAME records kunnen alleen gebruikt worden voor subdomeinen. De hoofd domeinnaam (domein.nl) mag geen CNAME zijn, dus dat is altijd een A en/of AAAA record. Als je HTTP(S) validatie gebruikt voor een SSL certificaat aanvraag, zal een webserver een bepaald antwoord moeten serveren aan de validatie server, hoe die validatie server bij de te valideren hostname komt (CNAME of A/AAAA) maakt verder geen enkele verschil. Bij DNS validatie ligt het aan de uitgevende instantie, Sectigo (vh. Comodo) gebruikt bijvoorbeeld CNAME’s, terwijl Let’s Encrypt TXT records gebruikt voor validatie.
Als alternatief zou je (voorlopig) een SSL certificaat van Sectigo kunnen overwegen. Ben je voor € 1,- per maand klaar en hoef je certificaat maar 1x per jaar te vervangen. SSL Certificaten vergelijken
En als je een beetje zoekt op internet kan het nog wel ietsje goedkoper ook.
We gaan technisch wat dieper maar goed (om)dat het kan. De inrichting is vooral met hoe het door ene partij wordt geïmplementeerd. Denk aan github die DNS ‘gebruikt’ om uit te vinden voor welke gebruiker zij een pagina moet faciliteren.
En ja, een CNAME zal normaliter uitkomen op een idd weer een IP Adres die dan de website-functie kan afhandelen.
Voor SSL via Let’sEncrypt tbv HTTPS is geen TXT record nodig en volstaat dat het uitkomt op een IP adres die het certificaat aanvraagt.
Mijn oriëntatie irt Website was vooral op uiteen te zetten hoe bedrijven DNS gebruiken om zo hun webfuik-diensten te leveren en duidelijk maakt waarom hosters “graag” zich het domein toeëigenen.
In geval van Freedom biedt Procolix dat de DNS bij Freedom blijft omdat zij haar web & ssl configuratie daarop afstemt.
To set up a www or custom subdomain, such as www.example.com or blog.example.com, you must add your domain in the repository settings. After that, configure a CNAME record with your DNS provider.
Terzijde, een (website) hoster kan (mogelijk) de GitHub methode blokkeren wanneer zij verbiedt dat iemand een zg FQDN kan opnemen in het CNAME record. Eén van mijn ‘hosters’ vereist dat een CNAME verwijzing altijd bij haar is ondergebracht.
Is er al informatie hoe de redirect functie per 1/1/24 gaat functioneren ?
Het mag onderwijl wel tijd worden dat die informatie bekend is/wordt gemaakt. Ook wacht ik nog steeds op een oplossing hoe ik niet te downloaden websites, kan veiligstellen.
Een apex domein is inderdaad iets als example.com.
Niet alle TLDs ondersteunen CNAMEs op het apex domein. Op .nl kan dat b.v. niet.
Ik heb bij GitHub een apex draaien door het gebruik van IP adressen, maar dat staat netjes in de docs: GitHub Pages with an apex domain.
Een beetje raar dat je hoster dat vereist, ik gebruik Cloudflare voor het beheer van mijn domeinen. Hier is gelukkig een free tier voor de ruim zat is om een aantal domeinen onder te brengen.
Mag ik hier ook even mijn verbazing over uiten?
U (Freedom) stopt met een basis service en verwijst naar een dienst a raison 25% van mijn abonnementsprijs ?
Gaat u mij omdat u stopt met deze dienstverlening dan ook compenseren met hetzelfde percentage?
Voor de absolute duidelijkheid ik ziet hier niet wegens financiële beweegredenen maar poog u wel te verwittigen dat dit bericht / alternatief wat hier gecommuniceerd is tegen het ridicule aan zit.
Ik voel me nu als klant niet echt serieus genomen gebied de eerlijkheid mij te zeggen.
Al het andere is al hierboven beschreven kortom ik sluit me daarbij aan.
Fix gewoon een simpele homedirectory voor statische HTML pagina’s met verder dezelfde beschikbare ruimte zoals bij de huidige oplossing dan is iedereen geholpen toch ?
Github Microsoft c.s. is dan ook zo gemaakt & ingericht dat die het domein benoemd (met haar github-CNAME-record functie) & zo doorlaat.
) .
Reden(en) om ergens aan te twijfelen had ik vooralsnog ook niet t.a.v. de “website” en wat andere dingetjes die met set&forget functioneerden.
maar goed (om)dat het kan. De inrichting is vooral met hoe het door ene partij wordt geïmplementeerd. Denk aan github die DNS ‘gebruikt’ om uit te vinden voor welke gebruiker zij een pagina moet faciliteren.