19 nov 2025·8 min
Checklist voor aangepaste domeinen: DNS- en SSL-problemen
Gebruik deze checklist voor aangepaste domeinen om DNS-recordproblemen, propagatievertragingen en SSL-timing te diagnosticeren, met eenvoudige verificatiestappen.
Gebruik deze checklist voor aangepaste domeinen om DNS-recordproblemen, propagatievertragingen en SSL-timing te diagnosticeren, met eenvoudige verificatiestappen.
“Aangepast domein werkt niet” is een verzamelnaam voor een paar verschillende storingen. Je browser toont het symptoom, niet de oorzaak. Voordat je iets verandert: beschrijf wat je daadwerkelijk ziet.
Typische symptomen zijn:
Meestal is er maar één ding mis:
Voordat je gaat troubleshooten, zorg dat je toegang hebt tot twee plekken: waar je DNS-records bewerkt (registrar of DNS-provider) en waar je het domein koppelt aan de hostingkant. Bijvoorbeeld: als je een gedeployde app op Koder.ai aan een aangepast domein koppelt, heb je DNS-toegang voor het domein nodig en toegang tot de domeininstellingen in de hosting- of deploymentconfiguratie van de app.
Sommige fixes zijn meteen zichtbaar (zoals een typfout corrigeren). Andere dingen kosten tijd. DNS-wijzigingen kunnen even duren voor ze zichtbaar worden en SSL zal meestal niet klaar zijn totdat DNS correct wijst en het domein bereikbaar is. Het doel is stoppen met raden en elke laag op volgorde bevestigen.
De meeste domeinproblemen komen neer op een mismatch tussen (1) de hostnaam die je test, (2) waar DNS wordt beheerd en (3) waar het record feitelijk naar wijst. Zodra die drie overeenkomen, is SSL doorgaans de laatste stap.
Domeinen hebben twee veelvoorkomende vormen: het rootdomein (example.com, ook wel apex genoemd) en subdomeinen (www.example.com, app.example.com). Ze zijn gerelateerd, maar kunnen verschillende DNS-records hebben. Het is dus normaal dat www werkt terwijl de apex faalt, of andersom.
Nameservers bepalen wie verantwoordelijk is voor je DNS-zone. Als je een domein bij het ene bedrijf hebt gekocht maar de nameservers naar een ander bedrijf wijzen, moet je DNS bewerken waar de nameservers naar wijzen. Veel “ik heb het bijgewerkt maar er veranderde niets”-situaties ontstaan omdat records in het verkeerde dashboard zijn aangepast.
Dit doen de belangrijkste recordtypes:
TTL is de “hoe lang cachen” timer. Een lagere TTL betekent dat caches sneller ververst worden. Een hogere TTL betekent dat je mogelijk langer moet wachten, zelfs nadat je het record hebt aangepast. Het is normaal dat je een tijdlang de oude waarde ziet.
Als een aangepast domein faalt, kun je het meestal in één van vier categorieën indelen: DNS lost niet op, DNS lost op maar naar de verkeerde plaats, SSL is nog niet klaar, of het faalt alleen voor sommige mensen door caching.
Gebruik deze beslisboom:
www werkt maar het rootdomein niet (of andersom), heb je waarschijnlijk alleen één hostnaam geconfigureerd, of heb je conflicterende redirectregels.Werk sneller door de exacte hostnaam op te schrijven die faalt (apex versus www) en de precieze foutmelding te noteren. Op hostingplatforms die domeinen en certificaten automatiseren, vertelt het verschil tussen “host niet gevonden” en “certificaat in afwachting” of je DNS-records moet corrigeren of simpelweg moet wachten tot SSL klaar is nadat DNS zichtbaar is.
Veel domeinfouten starten met een eenvoudige mismatch: je hebt DNS ingesteld voor de ene hostnaam, maar je test een andere.
Schrijf eerst de exacte hostnaam op die je live wilt hebben. Het rootdomein ziet eruit als example.com. Een subdomein ziet eruit als www.example.com of app.example.com. Dit zijn aparte DNS-items, dus “www werkt” betekent niet dat het rootdomein ook werkt.
Zoek vervolgens het verwachte doel van je hostingplatform. Sommige platforms geven een IP-adres (voor een A- of AAAA-record). Andere geven een doelhostnaam (voor een CNAME). Als je host een waarde in een domeininstellingsscherm geeft, behandel die waarde dan als bron van waarheid.
Voordat je iets verandert, leg vast wat er nu staat. Houd het simpel:
Bevestig ook dat je de juiste DNS-zone bewerkt. Het is makkelijk om het verkeerde domein, de verkeerde omgeving of het verkeerde provider-account te updaten.
Veel problemen zijn gewoon het verkeerde recordtype voor de hostnaam die je probeert te verbinden. Begin met twee gevallen te scheiden: het rootdomein (example.com) en een subdomein (www.example.com). Ze gedragen zich anders bij veel DNS-providers.
Een A-record wijst een naam naar een IPv4-adres. Veel configuraties gebruiken een A-record voor het rootdomein omdat sommige providers geen CNAME op de apex toestaan. Als je host een IP geeft, is een A-record meestal correct.
Een AAAA-record is de IPv6-versie. Een verkeerd AAAA-record dat naar een oude bestemming wijst kan verwarrend “werkt voor mij”-gedrag veroorzaken, omdat sommige bezoekers IPv6 raken terwijl anderen IPv4 gebruiken. Als je host geen IPv6-doel heeft gegeven, lost het verwijderen van een onjuiste AAAA-record vaak inconsistente fouten op.
Een CNAME-record wijst een subdomein naar een andere hostnaam (vaak gebruikt voor www). Het is nuttig wanneer de host wil dat je een benoemd eindpunt target dat achter de schermen kan veranderen.
Een TXT-record is voor verificatie en challenges (inclusief sommige SSL-checks). Vaak gemaakte fouten zijn het plaatsen van de TXT op de verkeerde naam (root versus _acme-challenge versus een subdomein), extra spaties toevoegen of de verkeerde waarde plakken.
Kijk voordat je verder gaat naar conflicten. Dit zijn de grootste problemen:
Veel “aangepast domein werkt niet”-gevallen gaan niet over de recordwaarde zelf. Ze ontstaan omdat het record op de verkeerde provider is toegevoegd. Als je domein Provider A’s nameservers gebruikt, zal het aanpassen van records in Provider B’s dashboard niets doen, zelfs als de records daar correct lijken.
Controleer welke nameservers je domein daadwerkelijk gebruikt. Je kunt dit meestal zien in de domeininstellingen bij je registrar onder “Nameservers”. Voor een tweede mening kun je DNS direct vanaf je computer vragen:
dig NS example.com
De door die opdracht geretourneerde nameservers zijn de gezaghebbenden.
Een snelle sanity-check:
ns1... en ns2..., moeten die exacte waarden bij de registrar staan.Als je records bij de verkeerde provider bijwerkt, zie je vaak twee dashboards die niet overeenkomen. Alleen de gezaghebbende nameservers doen ertoe.
Let ook op vertragingen na het wijzigen van nameservers bij de registrar. Tijdens het overgangsvenster kunnen de resultaten inconsistent lijken, afhankelijk van waar je test. Als nameservers nog wisselen, pauzeer dan met recordbewerkingen totdat de set nameservers stabiel is en ga dan verder.
“Propagatie” is geen schakelaar. Het is een keten van DNS-caches (ISP, telefoonprovider, openbare resolvers en je eigen apparaten) die met verschillende snelheden bijwerken. Daarom kan je domein voor een collega werken maar voor jou niet.
TTL (time to live) vertelt caches hoelang ze een antwoord mogen bewaren. Als de oude TTL 1 uur was, blijven sommige mensen de oude waarde bijna een uur zien. Het verlagen van TTL helpt alleen als je dat deed vóórdat je de wijziging doorvoerde.
Om cachingvertragingen van echte fouten te scheiden, voer je een paar snelle controles uit:
Als het record ergens waar je controleert verkeerd is (verkeerd IP, ontbrekende www, oude CNAME), los dat op. Als records op de meeste plekken correct lijken maar één netwerk het oude waarde blijft tonen, is het meestal cachevertraging.
SSL-certificaten falen meestal om één eenvoudige reden: de certificaatprovider kan het domein niet valideren totdat DNS consequent naar de juiste plek wijst.
De normale volgorde is eenvoudig:
Veel voorkomende blokkers zijn makkelijk te missen. Een verkeerde A- of CNAME-doel stuurt validatiechecks naar de verkeerde server. Een verouderd AAAA-record kan je werkende A-record overriden voor sommige bezoekers, waardoor HTTPS alleen voor hen faalt. Het ontbreken van een vereist TXT-record kan voorkomen dat een platform een certificaat uitgeeft.
Gebruik symptomen om “nog bezig met uitgeven” te scheiden van “verkeerd geconfigureerd”:
Terwijl je wacht, blijf niet continu records veranderen. Iedere wijziging zet de klok opnieuw en kan een verdeelde wereld creëren waarin verschillende netwerken verschillende antwoorden zien. Zet de juiste records één keer, controleer resolutie en verificatie en wacht vervolgens tot het certificaat is uitgegeven.
Als je een platform zoals Koder.ai gebruikt, is de veiligste route hetzelfde: bevestig dat DNS naar het verwachte doel wijst, verwijder onjuiste AAAA-records als die er zijn, en geef SSL tijd nadat DNS stabiel is.
Goed troubleshooten is vooral vergelijken: wat je ziet versus wat je verwacht. Vertrouw niet op “het laadt op mijn telefoon.” Gebruik reproduceerbare controles.
Gebruik een DNS-opzoektool (zoals nslookup of dig) en bevestig dat de teruggegeven waarde overeenkomt met wat je bedoeld had (een IP voor A of AAAA, een hostnaam voor CNAME, een token voor TXT).
# Apex (root) domain
dig example.com A
dig example.com AAAA
# www subdomain
dig www.example.com CNAME
# TXT (vaak gebruikt voor verificatie)
dig example.com TXT
Controleer beide namen die je mogelijk gebruikt: de apex (example.com) en www (www.example.com). Het is gebruikelijk dat de ene correct is terwijl de andere nog naar een oude bestemming wijst.
Open zowel http:// als https:// voor de apex en www. Je wilt één duidelijke “home” domein en één schone redirect.
www) en redirect de andere ernaartoe.Als resultaten verschillen per netwerk, zie je waarschijnlijk caching of propagatie. Houd een klein logboek bij: wat je hebt veranderd, waar je het hebt veranderd, de tijd en wat je observeerde.
De meeste DNS- en SSL-problemen zijn geen mysterie. Het zijn kleine fouten die je blijven doen kijken naar het verkeerde ding, of het té vaak wijzigen zodat je geen duidelijk beeld krijgt.
De meest voorkomende tijdverspiller is DNS op twee plekken bewerken. Dit gebeurt vaak na het wisselen van nameservers: je past records aan bij de registrar, maar DNS wordt eigenlijk elders gehost (of andersom). Alles lijkt correct in één dashboard, maar publiekelijk verandert er niets.
Een andere klassieke fout is proberen een CNAME op het rootdomein te zetten bij een provider die dat niet ondersteunt. Je hebt dan mogelijk een A-record nodig, of een ALIAS/ANAME-achtig record als je DNS-provider dat biedt.
IPv6 kan ook problemen veroorzaken. Het laten staan van een oud AAAA-record kan sommige bezoekers naar de verkeerde server sturen terwijl anderen correct IPv4 gebruiken.
Wees voorzichtig met “voor het geval dat”-records. Meerdere A-records kunnen zich gedragen als onbedoelde load balancing als één doel ongeldig is, vooral wanneer je een aangepast domein aan een hosted app koppelt.
Een laatste regel: stop met steeds de klok opnieuw te zetten.
Kleine, rustige wijzigingen zijn beter dan constant bijsturen.
Je lanceert een nieuwe app en stelt zowel example.com als www.example.com in. Een paar minuten later laadt www.example.com goed, maar het rootdomein geeft een DNS-fout, laadt een oude site of HTTPS blijft in afwachting. Dit patroon is gebruikelijk en heeft meestal een kleine oorzaak.
Begin met de saaie vraag: bewerk je DNS op de juiste plek? Als je domein geregistreerd is bij het ene bedrijf maar DNS gehost wordt bij een ander, kun je records blijven aanpassen zonder dat er iets gebeurt. Controleer nameservers eerst en open dan het DNS-paneel bij de provider waar die nameservers naar wijzen.
Vergelijk daarna de twee hostnamen. www is typisch een CNAME. Het rootdomein is lastiger: veel providers staan geen CNAME op de apex toe, dus het heeft vaak een A-record naar een IP nodig, of een ALIAS/ANAME-style record indien ondersteund.
Een besluitpad dat in de praktijk werkt:
example.com heeft geen record (of wijst ergens anders heen)? Repareer het apex-record.De juiste eindtoestand is saai: zowel example.com als www.example.com leiden naar dezelfde app, één is canoniek (de ander redirect) en HTTPS is geldig.
Wanneer een domeinconfiguratie faalt, komen de meeste oplossingen voort uit een paar snelle controles. Doe deze voordat je iets anders verandert.
Nadat DNS duidelijk correct is, controleer dan pas SSL. Veel platforms geven het certificaat pas uit nadat ze je domein consequent naar het juiste doel kunnen resolven. Als je te vroeg checkt, kun je een normale vertraging voor een echte fout aanzien.
Als je een aangepast domein toevoegt aan een gedeployde app op Koder.ai, behandel het domeininstellingsscherm als referentie voor het verwachte doel en controleer de status pas opnieuw nadat DNS tijd heeft gehad om te propagëren.
De snelste manier om DNS- en SSL-fouten niet te herhalen is een kort “domeinsetup-notitie” voor elk project bij te houden. Het is een herbruikbaar runbook dat je de volgende keer kunt kopiëren.
Bewaar het in je projectdocumentatie en vul het in voordat je DNS aanraakt:
Tijdens lancering: wijs één persoon aan als DNS-eigenaar. DNS breekt het vaakst als twee mensen tegelijk verschillende dingen “repareren” (bijvoorbeeld de één verandert nameservers terwijl de ander records aanpast).
Aan de hostingzijde: plan voor veilige terugdraaien. Als je platform snapshots of rollback ondersteunt, maak dan een snapshot voordat je routing verandert zodat je snel kunt terugkeren naar de laatst bekende goede staat. Als je op Koder.ai bouwt, kun je Planning Mode gebruiken om de domeinstappen op te schrijven, ze in volgorde toe te passen en terug te rollen als een wijziging de productie breekt.
Als je DNS hebt bevestigd en je ziet nog steeds fouten, stop met gokken en escaleer met bewijs:
Als je escaleert, voeg dan de hostnaam, verwachte records, huidige resolverresultaten en tijdstempels toe. Dat verandert trage heen-en-weer communicatie in een snelle oplossing.
Het betekent meestal dat één laag van de keten niet klopt: DNS lost niet op, DNS wijst naar de verkeerde bestemming, de server/host herkent je hostnaam niet, of HTTPS/SSL is nog niet uitgegeven. Begin met het precies opschrijven van de foutmelding die je ziet en de exacte hostnaam die je hebt ingevoerd (apex versus www).
Omdat example.com (de apex) en www.example.com aparte hostnamen zijn met losse DNS-records. Het is gebruikelijk dat www een correcte CNAME heeft, terwijl de apex geen A-record heeft, een verkeerde A-record heeft, of de DNS-provider geen CNAME op de apex ondersteunt.
Controleer de nameservers van het domein bij je registrar en vergelijk ze met de DNS-provider die je aanpast. Alleen de provider die voorkomt in de actieve nameservers is gezaghebbend; records bewerken ergens anders verandert niet wat het openbare internet ziet.
Gebruik een A-record wanneer je host een IPv4-adres geeft, een AAAA-record alleen als je host een IPv6-adres geeft, en een CNAME wanneer je host een andere hostnaam opgeeft (meestal voor www). TXT-records zijn voor verificatie en challenges en moeten op exact de naam worden aangemaakt die je host specificeert.
Een verouderd of verkeerd AAAA-record kan sommige bezoekers via IPv6 naar een oude server sturen terwijl anderen naar het juiste IPv4-adres gaan, wat resulteert in “het werkt bij mij” verwarring. Als je host geen IPv6-doel gaf, is het verwijderen van een foutief AAAA-record vaak de eenvoudigste oplossing.
Meestal heb je maar één hostname op de hostingzijde geconfigureerd (alleen apex of alleen www), of je hebt tegenstrijdige redirectregels die heen en weer sturen tussen HTTP en HTTPS of tussen apex en www. Kies één canonieke hostnaam, configureer beide hostnamen en zorg voor één duidelijke redirect-route.
Ja. Wachten is de juiste stap, maar alleen nadat DNS duidelijk vanaf meerdere plekken naar de juiste bestemming wijst. SSL-uitgifte voltooit meestal niet totdat het domein consequent naar de verwachte bestemming resolveert; het constant wijzigen van DNS houdt het uitgifteproces telkens opnieuw bezig.
TTL bepaalt hoe lang resolvers een antwoord cachen, dus zelfs nadat je een record hebt aangepast, kunnen sommige netwerken het oude waarde blijven teruggeven totdat de TTL verloopt. Test vanaf twee verschillende netwerken (bijvoorbeeld Wi‑Fi en mobiel) en voorkom dat je elke paar minuten DNS-wijzigingen doorvoert zodat je de propagatie rustig kunt observeren.
Gebruik een herhaalbare controle zoals dig of nslookup om te bevestigen dat de A/AAAA/CNAME/TXT-antwoorden overeenkomen met je verwachte doel, en test daarna zowel http:// als https:// voor zowel de apex als www. Als één netwerk andere DNS-antwoorden ziet dan een ander, is dat meestal caching; als alle netwerken de verkeerde antwoorden tonen, is het een configuratiefout.
Op Koder.ai: behandel het domeinscherm van de app als de bron van waarheid voor het verwachte DNS-doel en zorg dat DNS exact overeenkomt bij de gezaghebbende provider. Geef DNS daarna de tijd om te settelen voordat je SSL opnieuw controleert, en gebruik snapshots/rollback als je routing op een live project aanpast zodat je snel kunt terugkeren naar een bekende goede staat.