Eigen domein voor QR-codes instellen: CNAME, SSL en DNS uitgelegd

Wat een eigen domein voor een QR-redirect eigenlijk betekent

Elke dynamische QR-code verwijst eerst naar een korte redirect-link voordat je op de echte bestemming uitkomt, en die link staat op een domein. Scan je een code van de meeste QR-platforms, dan toont de adresbalk het eigen shortener-domein van de aanbieder: iets als qrco.de, bit.ly, of bij ScanKit scankit.app/r/. Een eigen domein vervangt dat domein van de aanbieder door een domein dat het bureau (of de klant) al in bezit heeft, zodat de redirect voortaan links.agency.com of qr.clientbrand.com laat zien.

Dit is iets anders dan het verschil tussen een dynamische QR-code en een statische. Dynamisch betekent alleen dat de bestemming achter de code kan veranderen nadat de code al gedrukt is. Een eigen domein is een aparte, extra laag: het verandert hoe de link zelf eruitziet, op elk apparaat waarmee iemand de link voor of na het scannen bekijkt. Bureaus willen meestal allebei tegelijk, want een klant die vraagt "waarom leidt mijn QR-code door naar de website van iemand anders?" stelt een reëel, terugkerend bezwaar in verkoopgesprekken, en daar bestaat een precies technisch antwoord op.

Het mechanisme erachter is hetzelfde als bij elk gebrandeerd link-shortening product (Bitly, Rebrandly) en bij elke white-label SaaS-functie in het algemeen: het bureau verhuist zijn QR-platform niet naar een nieuwe server, maar wijst via DNS een klein stukje van zijn eigen domein naar de bestaande infrastructuur van het platform.

De DNS-mechaniek: een CNAME-record, geen domeinoverdracht

Een eigen domein instellen voor een QR-redirect is een DNS-wijziging, geen hostingmigratie. Het bureau voegt één CNAME-record toe in de DNS-instellingen van zijn domein, dat een subdomein laat verwijzen naar een hostnaam die het QR-platform aanlevert. Een CNAME-record is een alias: het vertelt het internet dat "aanvragen voor links.agency.com eigenlijk moeten resolven naar waar edge.qrplatform.com naartoe wijst." Er verhuizen geen bestanden, er wisselt geen server van eigenaar, en de hoofdwebsite van het bureau op datzelfde domein blijft ongemoeid.

Er is één harde beperking die je moet begrijpen voordat je dit bij welke leverancier dan ook aanvraagt: een CNAME-record kan niet bestaan op de zone apex, oftewel het kale hoofddomein (agency.com zonder iets ervoor). Dat is geen beperking van de leverancier, maar een structurele regel in hoe DNS zelf is gespecificeerd: de apex van een domein moet een SOA-record en NS-records dragen, en een naam met een CNAME erop mag geen enkel ander recordtype er tegelijk naast hebben (RFC 1034, RFC 1912). Daarom vraagt vrijwel elke custom-domain-setup, bij elk SaaS-product dat dit aanbiedt, om een subdomein en niet om het kale domein.

Wil een bureau per se het hoofddomein zelf gebruiken in plaats van een subdomein, dan is de workaround een functie aan de kant van de DNS-provider die meestal ALIAS, ANAME of CNAME-flattening heet (Cloudflare, AWS Route 53 en diverse andere DNS-hosts ondersteunen dit onder verschillende namen). Die functie lost het doel op via de eigen servers van de provider en levert daarvoor een gesynthetiseerd A-record terug, zodat er nooit echt een CNAME op de apex staat en de DNS-regel dus niet wordt overtreden. Het is goed om te weten dat dit bestaat, want het is het antwoord op de vraag "kunnen we agency.com gebruiken en niet links.agency.com", maar het hangt volledig af van welk bedrijf de DNS van het bureau host, niet van het QR-platform.

De meest voorkomende opzetfout is niet exotisch: het is een verouderd A-record dat al op het subdomein staat dat het bureau wil gebruiken (vaak een restant van een oude redirect of een vergeten testpagina). Omdat een naam niet tegelijk een CNAME en een A-record kan hebben, mislukt het toevoegen van de nieuwe CNAME, of werkt hij stilzwijgend niet totdat dat oude record eerst is verwijderd.

SSL: het certificaat moet per domein worden aangemaakt

Een werkende CNAME is maar de helft van een werkend eigen domein. Elk van die domeinen heeft ook een geldig TLS-certificaat nodig, anders toont de browser een beveiligingswaarschuwing in plaats van een redirect. Vroeger betekende dit dat je per domein handmatig een certificaat moest kopen en installeren, wat eigen domeinen onpraktisch maakte voor een QR-platform dat veel bureaus bedient, elk met hun eigen klantsubdomeinen.

De moderne standaard is geautomatiseerd: Let's Encrypt geeft gratis certificaten uit via het ACME-protocol, dat domeineigendom bewijst via een "challenge" voordat er iets wordt uitgegeven. In de praktijk zijn er twee soorten challenges. HTTP-01 zet een tokenbestand op een specifiek pad van het domein; dat is eenvoudig, maar kan geen wildcardcertificaat uitgeven en vereist dat poort 80 bereikbaar is. DNS-01 vereist juist het publiceren van een specifiek TXT-record; dat is de enige methode die een wildcard kan valideren, en die werkt zelfs als het domein geen eigen webserver heeft, wat goed past bij een subdomein dat alleen voor redirects dient.

Voor een platform dat eigen domeinen van veel verschillende klanten tegelijk onboardt, is het gangbare patroon (zoals gebruikt door Cloudflare for SaaS en vergelijkbare multi-tenant setups) om die ACME-challenge namens de klant te automatiseren zodra de CNAME is geverifieerd, zodat het certificaat wordt uitgegeven en vernieuwd zonder dat het bureau iets hoeft te doen buiten het oorspronkelijke DNS-record om. Heeft de DNS-zone van een domein een CAA-record dat beperkt welke certificaatautoriteiten ervoor mogen uitgeven, dan moet dat record de uitgever expliciet toestaan (Let's Encrypt of welke CA het platform ook gebruikt), anders mislukt de uitgifte zelfs met een perfect correcte CNAME.

1. Een scan opent de gebrandeerde redirect-link op de telefoon van de bezoeker.
2. DNS lost de CNAME op en wijst het eigen domein naar het QR-platform.
3. Het TLS-certificaat van het platform voor dat domein wordt gecontroleerd voordat er iets laadt.
4. De bezoeker komt terecht op de echte, beoogde bestemmingspagina.

Hoeveel tijd het echt kost

"Tot 48 uur" is het getal dat overal wordt herhaald voor DNS-propagatie, en dat klopt technisch gezien als worstcasegrens, maar het overdrijft het typische geval zo erg dat het misleidend is. De vertraging die gebruikers daadwerkelijk ervaren, komt door caching: elk DNS-record heeft een TTL (time to live) die resolvers vertelt hoe lang ze het oude antwoord mogen blijven geven voordat ze opnieuw controleren. Zodra een wijziging de autoritatieve nameservers bereikt, is die vrijwel meteen beschikbaar; wat tijd kost, is dat elke resolver op internet die het oude record al gecachet heeft, de TTL van dat record moet uitzitten.

In de praktijk betekent een lage TTL (een gangbare standaard is 300 seconden, vijf minuten) dat het grootste deel van internet een DNS-wijziging binnen enkele minuten ziet, niet binnen dagen. Het realistische advies voor een domeinovergang: controleer de huidige TTL van het record voordat je de wijziging doorvoert, en staat die hoog (een dag of meer), verlaag hem dan een dag van tevoren zodat de uiteindelijke omschakeling snel doorwerkt, en zet hem daarna weer terug. Het cijfer van 24 tot 48 uur weerspiegelt vooral oude configuraties met een hoge TTL en worstcase-verwerkingstijden bij registries, niet wat er gebeurt bij een goed voorbereide, moderne DNS-opzet.

Helpt een gebrandeerd domein echt, en is het een beveiligingsfunctie?

In de meeste marketingteksten over eigen domeinen worden twee losse beweringen op één hoop gegooid, en die verdienen het om uit elkaar getrokken te worden.

De bewering over merkconsistentie is simpel en klopt: een link die qr.clientbrand.com toont, oogt alsof hij van de klant is, en een link die via een onbekend shortener-domein van een leverancier loopt, oogt alsof hij van een derde partij is, want dat is ook zo. Voor een klant die een bureau betaalt om zijn campagne te runnen, is die visuele consistentie iets reëels en redelijks om te willen, los van alles wat meetbaar is aan scangedrag.

De bewering over SEO is zwakker dan hij klinkt. Google zegt al jaren, ook rechtstreeks vanuit Googles eigen Search Central-team, dat subdomeinen en submappen gelijk worden behandeld voor ranking, en dat Googles systemen een subdomein koppelen aan het bovenliggende domein in plaats van het te straffen. Voor een QR-redirect specifiek maakt dit sowieso nauwelijks uit: de redirect-link zelf is geen content die iemand geïndexeerd en gerankt wil zien, het is een routeringslaag die de bezoeker meteen ergens anders naartoe stuurt. Elk SEO-voordeel dat aan een eigen QR-domein wordt toegeschreven, gaat in werkelijkheid over merkvertrouwen, niet over zoekresultaten.

De bewering over beveiliging is degene waarbij precisie ertoe doet, want die snijdt aan twee kanten. Een geverifieerd domein, bevestigd via DNS en TLS, dat een bureau daadwerkelijk beheert, is betrouwbaarder dan een generieke shortener, om een concrete reden: het is consistent en controleerbaar, niet omdat gebrandeerd ogende URL's an sich veilig zijn. De eigen consumentenvoorlichting van de Amerikaanse FTC over QR-code-oplichting is expliciet dat mensen de daadwerkelijke bestemmings-URL moeten controleren voordat ze een scan vertrouwen, juist omdat aanvallers visuele vertrouwenssignalen misbruiken. Beveiligingsonderzoekers hebben "quishing"-campagnes gedocumenteerd waarbij overtuigende lookalike-domeinen worden geregistreerd om precies die reden: een domein dat eruitziet alsof het van een vertrouwd merk is, is nou juist wat een vervalste QR-code overtuigend maakt, niet iets wat ertegen beschermt. Zie onze gids over QR-codebeveiliging voor bureaus voor hoe dat risico specifiek uitpakt bij printcampagnes. De eerlijke framing: een eigen domein wint vertrouwen omdat het het eigen, verifieerbare domein van het bureau is, onder de eigen DNS-controle van het bureau, en die discipline (DNS-records controleren, certificaten vernieuwen, een domein niet laten verlopen) is wat een klant daadwerkelijk beschermt, niet de branding op zich.

Het bureauperspectief: één platform, veel klantdomeinen

Voor een bureau dat QR-campagnes voor meerdere klanten draait, is een eigen domein geen eenmalige instelling, maar een configuratie per klant die netjes moet aansluiten op hoe het bureau klantwerkruimtes al organiseert. Een platform dat eigen domeinen goed ondersteunt voor bureaus, moet de codes van elke klant laten redirecten via het eigen domein van die klant (of dat van het bureau, afhankelijk van het contract), zonder dat de domeinen elkaar in de weg zitten, aangezien elk domein een onafhankelijke CNAME plus een onafhankelijk aangemaakt certificaat is.

Dit heeft een contractuele kant die makkelijk over het hoofd wordt gezien totdat hij voor problemen zorgt: van wie het domein ook is waar de redirect doorheen loopt, die partij heeft in feite controle over de link. Lopen de QR-codes van een klant via een subdomein dat de klant zelf bezit en eindigt de samenwerking, dan moet het bureau het DNS-record laten verwijderen of ombouwen, anders kan de klant simpelweg overnemen wat de code vervolgens doet door te wijzigen waar zijn eigen subdomein naartoe wijst, zelfs bij een code die al fysiek gedrukt is en de wereld in is. Bureaus die om deze reden klant-eigen domeinen gebruiken, doen er goed aan schriftelijk vast te leggen wat er bij het einde van het contract met het DNS-record gebeurt, net zoals ze afspreken wie toegang tot de analytics behoudt. Wordt in plaats daarvan het eigen domein van het bureau gebruikt (links.agencyname.com, gedeeld tussen klanten via aparte subpaden of werkruimte-gebonden UTM-parameters), dan doet die onduidelijkheid zich niet voor, ten koste van het feit dat de redirect niet het merk van de individuele klant draagt.

Checklist vooraf, voordat je een eigen domein aanvraagt bij een QR-platform

Voordat je welke leverancier dan ook vraagt om een eigen domein in te stellen, loont het om antwoorden te hebben op een kort lijstje vragen, want juist hier komen de verschillen tussen platforms het duidelijkst naar boven:

• Alleen subdomein, of ook hoofddomein? Ga na of het platform alleen een CNAME accepteert (dus een subdomein), of dat het ALIAS/CNAME-flattening ondersteunt voor een kaal hoofddomein via jouw specifieke DNS-host.
• Gaat het TLS-certificaat automatisch? Dat zou zo moeten zijn, zodra de CNAME is geverifieerd. Vraagt een leverancier je om handmatig een certificaatbestand te uploaden, dan is dat een teken van een oudere, minder geautomatiseerde opzet die kwetsbaarder is om te onderhouden.
• Wat is de verwachte insteltijd? Met een correct voorbereid DNS-record en een lage TTL zou het domein binnen het uur live moeten zijn, niet pas na dagen. Duurt het langer, dan wijst dat meestal op een handmatige controlestap bij de leverancier, niet op een DNS-beperking.
• Moet het domein toegewijd zijn, of kan het ook andere dingen hosten? Een subdomein dat puur voor QR-redirects wordt gebruikt (qr.clientbrand.com) voorkomt elk conflict met bestaande records; conflicten met verouderde records ontstaan juist wanneer je een subdomein hergebruikt dat al ander verkeer bedient.
• Wie is contractueel eigenaar van het DNS-record? Leg schriftelijk vast of het om het domein van het bureau of van de klant gaat, en wat er met het record gebeurt als de samenwerking eindigt.
• Toont het platform een waarschuwingspad als het certificaat ooit niet vernieuwt? Certificaten vernieuwen automatisch via ACME, maar latere wijzigingen aan DNS of CAA (door iemand die niets weet van de opzet met het eigen domein) kunnen de vernieuwing maanden na de succesvolle eerste installatie stilzwijgend laten mislukken.

Veelvoorkomende faalpatronen en hoe je ze herkent

De meeste problemen met eigen domeinen zijn terug te voeren op een klein aantal oorzaken, en herkennen welke dat is, gaat sneller dan gokken.

"CNAME could not be added" of het record lijkt geen effect te hebben. Bijna altijd een verouderd A-, AAAA- of ander record dat al op precies dat subdomein staat. Verwijder dat eerst; een naam kan geen CNAME hebben naast iets anders.

Het domein resolvet, maar de browser toont een certificaatwaarschuwing. Of het certificaat is nog niet klaar met aanmaken (controleer opnieuw nadat de CNAME de tijd heeft gehad om te verifiëren), of een CAA-record op het domein blokkeert de certificaatautoriteit die het platform gebruikt. Controleer het CAA-record als dat bestaat; het moet de uitgevende CA expliciet toestaan.

Het werkte, en brak weken later zonder wijzigingen aan de kant van het platform. De meest voorkomende oorzaak is dat iemand anders in het team om een ongerelateerde reden aan DNS zit te sleutelen (een mailrecord toevoegen, een registrar migreren) en daarbij per ongeluk dezelfde zone raakt, of een CAA-record dat later voor een ander doel is toegevoegd en nu de certificaatvernieuwing blokkeert. Daarom is het de moeite waard om het DNS-record voor een eigen QR-domein ergens te documenteren waar het hele team het kan zien, en niet alleen in het dashboard van de leverancier.

Aanvragen voor wildcardcertificaten mislukken. Wildcards kunnen alleen worden gevalideerd via het DNS-01-challengetype (een TXT-record), nooit via HTTP-01. Ondersteunt de flow voor eigen domeinen van een platform geen DNS-01-validatie, dan kan het structureel geen wildcard aanbieden, alleen losse subdomeinen, elk met een eigen CNAME en een eigen certificaat.

Veelgestelde vragen

Hoe lang duurt het voordat een eigen domein voor QR-codes live staat?

Met een correct voorbereid record met een lage TTL ziet het grootste deel van internet de wijziging binnen enkele minuten, zodra die de autoritatieve nameservers bereikt. De vaak genoemde "tot 48 uur" is een worstcasegrens van oude configuraties met een hoge TTL en verwerkingstijden bij registries, niet een typisch modern resultaat.

Heb ik een apart SSL-certificaat nodig voor een eigen QR-domein?

Nee, niet bij een goed gebouwd platform. Certificaten voor domeinen die klanten zelf bezitten, worden automatisch uitgegeven via het ACME-protocol (hetzelfde systeem achter Let's Encrypt) zodra de CNAME is geverifieerd, en ze vernieuwen ook automatisch. Moet je zelf een certificaatbestand uploaden, dan is dat een teken van een oudere, kwetsbaardere opzet.

Kan ik het domein van mijn klant gebruiken in plaats van het domein van mijn bureau?

Ja, technisch werkt het exact hetzelfde: de CNAME staat in de DNS van welk domein je het record ook toevoegt. De keuze is contractueel, niet technisch, en het loont om schriftelijk af te spreken wat er met dat DNS-record gebeurt als de samenwerking met die klant eindigt.

Is een subdomein slecht voor mijn SEO ten opzichte van het hoofddomein?

Niet voor een QR-redirectlink specifiek. Google behandelt subdomeinen en submappen gelijk voor ranking, en een redirect-link is geen content die op zichzelf hoeft te ranken; die moet vooral betrouwbaar ogen en werken.

Voorkomt een gebrandeerd eigen domein QR-phishing (quishing)?

Niet op zichzelf. Een domein dat het bureau daadwerkelijk beheert en geverifieerd houdt, is betrouwbaarder dan een generieke shortener, maar aanvallers registreren juist overtuigende, merk-nabootsende domeinen om precies dit soort visueel vertrouwen te misbruiken. De echte bescherming zit in DNS- en certificaathygiëne die het bureau daadwerkelijk onderhoudt, plus ontvangers die de bestemmings-URL controleren, niet in de aanwezigheid van een eigen domein op zich.

Kan ik het kale hoofddomein gebruiken, zoals agency.com, in plaats van een subdomein?

Alleen als jouw DNS-host een ALIAS-, ANAME- of CNAME-flattening-functie ondersteunt, want een gewoon CNAME-record kan volgens de DNS-specificatie niet op de root van een domein bestaan. De meeste bureaus gebruiken daarom liever een subdomein (links.agency.com), juist om die workaround niet nodig te hebben.

Wat is het verschil tussen een eigen domein en een white-label QR-platform?

Een eigen domein verandert alleen hoe de URL van de redirect-link eruitziet. White-labelling is breder: dat kan ook betekenen dat de eigen branding van het platform wordt verwijderd van de redirect-pagina zelf, van rapportages richting de klant, of van het dashboard dat de klant te zien krijgt. Een platform kan het één aanbieden zonder het ander, dus het is de moeite waard om beide te checken als merkconsistentie voor de hele klantervaring telt, niet alleen voor de link.

Kan één bureau verschillende domeinen voor verschillende klanten gebruiken op hetzelfde account?

Ja, dat is het normale patroon voor bureaus: de codes van elke klant redirecten via het eigen subdomein van die klant (of een gedeeld bureausubdomein, afhankelijk van het contract), elk ingesteld als een onafhankelijke CNAME en certificaat, zonder de opzet van andere klanten op hetzelfde account te verstoren.

De korte versie

Een eigen domein voor een QR-redirect is een DNS-wijziging, geen platformmigratie: één CNAME-record dat een subdomein naar het QR-platform wijst, met een TLS-certificaat dat een goed gebouwd platform automatisch aanmaakt en vernieuwt via het ACME-protocol. Meestal staat het binnen het uur live zodra het record correct is voorbereid, niet de 48 uur die de volksmond suggereert. Het helpt echt bij merkvertrouwen richting de klant en bij contractuele duidelijkheid over wie de link controleert; voor SEO doet het vrijwel niets, en op zichzelf is het geen verdediging tegen QR-phishing, aangezien aanvallers hetzelfde visuele vertrouwen misbruiken waarop een legitiem gebrandeerd domein steunt. Voordat ze dit bij welke leverancier dan ook aanvragen, doen bureaus er goed aan te bevestigen of gebruik van het hoofddomein wordt ondersteund, of het certificaat automatisch gaat, en wie contractueel eigenaar is van het DNS-record zodra een klantrelatie eindigt.