Domeinen & websites
Elk domein waar het thuishoort
Domeinen, websites en hostingaccounts hangen aan de klant: één keten van naam tot server. Op de domeinpagina staan naast elkaar wat publieke DNS antwoordt, wat Cloudflare verwacht en wat het register van je registrar zegt. En dat register beslist mee over de factuur, zodat je alleen de domeinen in rekening brengt die je ook echt verlengt.
De keten, per klant
De online infrastructuur van een klant is een vaste keten: het domein, eventueel een website, en de hosting waarop die draait. Alle drie hangen aan de klant en verschijnen als panelen op de klantpagina, zodat je op één plek ziet wat waar staat. Een domein heeft hooguit één website, op de root (@) of op www, met een technisch beheerder die je bij naam vastlegt: jouw bureau, de klant, een medewerker of een contactpersoon. Hosting is een eigen entiteit (Instellingen → Hosting) en mag zonder klant staan, want gedeelde infrastructuur is een echte toestand en geen ontbrekend veld. Alle drie nemen je eigen extra velden over, houden een activiteitenspoor bij van wie wat wanneer wijzigde, en reizen als spreadsheet heen en terug, met bulk bewerken over een hele selectie.
- Domein: klant, status, startdatum, registrar-, DNS- en e-mailprovider, registratie- en e-mailcontact
- Website: op @ of www, gekoppeld aan een hostingaccount, met per site een uptime-vlag
- Hosting: provider, IP-adres en een verantwoordelijke; geen klant betekent gedeeld
DNS die zichzelf bijhoudt
Voor elk domein leest een gewone resolver de publieke DNS uit: nameservers, DNSSEC en MX-records. Dat werkt voor élk domein, niet alleen voor de partijen waarmee we koppelen. Een nieuw domein wordt meteen na aanmaken opgehaald en daarna elke nacht ververst, zodat de pagina klopt zonder dat iemand erop drukt; de knop Verversen staat er wel, voor het moment vlak na een wijziging. Een onbereikbaar domein leest als 'geen gegevens' en breekt nooit de rest van de batch. Plak je een hele URL in het naamveld, dan wordt die teruggebracht tot de kale domeinnaam: 'https://WWW.Example.NL/pagina' wordt example.nl, ook bij een import, zodat je geen tweede rij krijgt voor een domein dat je al had.
- Nameservers, precies zoals ze publiek staan
- DNSSEC: ja, nee, of (nog) onbekend, want 'nooit gecontroleerd' is niet 'uit'
- MX-records op prioriteit, zodat je ziet waar de mail heen gaat
Cloudflare hoort bij het domein, niet bij een tweede tabblad
Cloudflare-accounts zijn rijen onder Instellingen → Cloudflare en geen installatie-instelling: je bureau heeft er zelf een en sommige klanten brengen de hunne mee. Je plakt een scoped API-token (versleuteld opgeslagen, nooit teruggegeven) en drukt op Token controleren; dat scherm schrijft op wat het token daadwerkelijk mag, dus een ontbrekend recht leest daar als 'niet toegekend' in plaats van drie schermen verderop als een knop die het niet doet. Zones ophalen haalt in één handeling de zones, de Pages-projecten en de Cloudflare Registrar-lijst binnen, en meldt hoeveel er aan een domein gekoppeld konden worden; wat niet matcht wordt getoond en niet verstopt. Op het domein zelf koppelt 'Koppelen aan Cloudflare' eerst een bestaande zone en maakt er alleen een aan als die er niet is, met een optie 'Alleen een bestaande zone koppelen' voor het overnemen van de inrichting van een klant. Het paneel zet 'Cloudflare verwacht' naast 'Publieke DNS antwoordt' en zegt in één zin of de nameservers al goed wijzen.
- DNS-records live uit Cloudflare: A, AAAA, CNAME, TXT, MX, NS, SRV en CAA, met TTL, proxy en notitie
- Een zone exporteren als zonebestand of als CSV, rechtstreeks vanaf het paneel
- Cloudflare Pages: een hostnaam aan een project koppelen, ook als de DNS ergens anders staat
- Drie losse rechten, zodat naar DNS kijken iets anders is dan DNS wijzigen
Een omleiding met een mechanisme erachter
'Doorverwijzing' was jarenlang alleen een statuslabel: het domein stond op doorverwijzen en het echte werk gebeurde ergens anders. Nu is het een Redirect Rule die schakl. zelf op de Cloudflare-zone zet, met doel-URL en het soort omleiding erbij; bij een permanente staat een waarschuwing, want browsers onthouden die. Standaard zet schakl. de records erbij die de omleiding nodig heeft, want een regel op een zone zonder proxied record vuurt nooit af: dat is precies de storing die eruitziet als een Cloudflare-probleem en het niet is. 'Controleren bij Cloudflare' gaat vervolgens kijken en benoemt wat het vindt, in gewone zinnen: de regel is in het Cloudflare-dashboard gewijzigd (met welke velden afwijken), hij is weg, hij is nooit verstuurd, de zone staat gepauzeerd, of een andere regel gaat er misschien eerst overheen. Conflicten worden gemeld en nooit stilletjes opgelost; de regel van iemand anders raakt schakl. niet aan.
- 301, 302, 307 of 308, met pad en querystring naar keuze mee
- Ook www en andere subdomeinen, met de records die de omleiding nodig heeft erbij
- Een omleiding die in zijn eigen bereik terugwijst wordt geweigerd, niet opgeslagen
Het register weet wat DNS niet weet
Publieke DNS vertelt je waar een domein heen wijst; het vertelt je niet wanneer het afloopt, of het verhuisslot aanstaat, wie de houder is, of wat de registry werkelijk gedelegeerd heeft. Die vier feiten komen uit het register van je registrar. Voor OXXA bewaar je resellerlogins onder Instellingen → OXXA, haal je het hele register in één aanroep op, en staat op de domeinpagina het paneel Registrar (OXXA) met Verloopt, Houder, Verhuisslot, Automatisch verlengen, DNSSEC en de nameservers, plus aandachtspunten in gewone taal: dit domein verloopt binnenkort, het verhuisslot staat uit, het register heeft andere nameservers dan wij verstuurd hebben. De waardevolste uitkomst van de eerste synchronisatie staat achter het filter 'Alleen niet-gekoppelde': domeinen die je elk jaar betaalt en waarvan schakl. (en dus je factuur) geen weet had. En 'Nameservers wijzigen bij OXXA' haalt de laatste handmatige stap uit de Cloudflare-overdracht: het vak opent voorgevuld met de nameservers die Cloudflare verwacht, en een tweede keer versturen verandert niets en zegt dat ook.
- Wat het register gedelegeerd heeft, wat wij verstuurd hebben en wat publieke DNS antwoordt zijn drie aparte gegevens; verschil wordt gemeld, nooit overschreven
- Nameservergroepen zijn bij OXXA gedeelde objecten, dus schakl. maakt er een aan en bewerkt er nooit een van iemand anders
- Eerlijk erbij: de OXXA-koppeling is geschreven op OXXA's eigen API-documentatie en heeft nog niet tegen een echte resellerlogin gedraaid; hetzelfde geldt voor de Registrar-helft van Cloudflare
Alleen factureren wat je echt verlengt
De domeinlijst van een bureau is een mengsel: namen die jij elk jaar verlengt en namen die de klant zelf registreerde en jou alleen vroeg ze ergens heen te wijzen. Alleen een register kan die twee uit elkaar houden; een zone kan het niet, want Cloudflare beantwoordt de DNS van genoeg domeinen die het niet houdt. Daarom is Facturatie op een domein driewaardig, met een zin eronder die zegt welk register besloot ('Staat in het register van OXXA, dus dit domein wordt gefactureerd'), en verandert er niets zolang er geen register is opgehaald: een installatie die vandaag domeinen factureert, factureert morgen precies dezelfde. Wat er in rekening komt volgt de TLD-tarieven met prijshistorie, waar een prijsverhoging eerst als voorbeeld per extensie te zien is en pas daarna wordt geschreven; een nachtelijke run schuift elk domein een jaar op en zet de verlengingsregel op een conceptfactuur. Domeinen, websites, hosting, Cloudflare en OXXA zijn uitbreidingsmodules: de kern van schakl. is open source (AGPL) en modules als deze draaien op een licentiesleutel die je invoert onder Instellingen → Licentie; verloopt die, dan worden ze alleen-lezen, zodat het register, de verloopdatums en de waarschuwingen leesbaar blijven terwijl er niets meer naar buiten geschreven wordt.
- Wel factureren: de jaarlijkse verlenging gaat naar de klant
- Niet factureren: de klant registreerde het domein zelf, wij brengen er niets voor in rekening
- Volg het register: het register beslist, en de kolom Gefactureerd zet er 'volgens register' bij
Wat er op de site draait, en of hij overeind staat
Cloudflare is iets wat een domein heeft; WordPress en de monitor zijn iets wat een website heeft, en ze staan dus een niveau lager in de boom. Eén WordPress-applicatiewachtwoord per site opent vier oppervlakken op dezelfde host, en levert meteen de AI-zichtbaarheid van Rank Math als marketingbron: hoe vaak het merk van een klant genoemd en gelinkt wordt in AI-antwoorden. Uptime Kuma zet het vinkje monitoren om in een echt record, met een klant, een profiel, een geschiedenis en een plek op de klantpagina naast het domein en het hostingaccount waar hij van afhangt. En omdat iemand vroeg of laat een monitor in Kuma zelf aanpast, wordt apart bewaard wat schakl. besloot en wat het als laatste zag, zodat afwijking iets is wat je kunt zien in plaats van iets wat stilzwijgend overschreven wordt.
- Het WordPress-wachtwoord hoort bij een beheerder, dus alleen beheerders mogen het beheren en een klantlogin komt er nooit bij
- Een monitorserver van een klant achter een firewall werkt ook: dan komt het verkeer de andere kant op
- Bestaande monitors neem je over in plaats van ze opnieuw aan te maken
Meer weten?
De documentatie beschrijft elke module tot in de details, van installatie tot rechten.