Hoe domeinen en DNS werken: een gids voor niet-ontwikkelaars

Een domein is de naam die mensen intypen om je site te bereiken, zoals example.com, en DNS (het Domain Name System) is het telefoonboek van het internet dat die naam vertaalt naar de plek waar je site echt staat. Je huurt het domein bij een registrar en voegt vervolgens DNS-records toe die zeggen “de website staat daar” en “e-mail gaat hiernaartoe”. Een eigen domein aan een app koppelen komt neer op het toevoegen van het juiste record op de juiste plek en wachten tot het actief wordt.

Waarom het ertoe doet bij bouwen met AI

Een AI-appbouwer kan je app schrijven en hosten, maar je domein staat buiten de app — vaak bij een apart bedrijf, in een beheerpaneel vol onbekende recordtypen. Hier lopen veel lanceringen vast: de app is klaar, maar het domein toont een foutmelding, of e-mail houdt ineens op te werken na een DNS-wijziging.

Een klein beetje begrip helpt enorm. Je weet welk record je host vraagt, waarom het nog niet werkt, en hoe je voorkomt dat dingen (zoals e-mail) die al op je domein rekenen kapotgaan.

Een alledaagse vergelijking

Denk aan de contactenlijst van je telefoon.

Je onthoudt het nummer van je vriend niet; je tikt op zijn naam en de telefoon zoekt het op. DNS doet hetzelfde voor het internet: je typt example.com en DNS zoekt het nummer (het IP-adres) op van de server waarmee je moet verbinden.

• Het domein is de naam van het contact.
• De registrar is het bedrijf dat officieel vastlegt dat de naam van jou is.
• DNS-records zijn de gegevens die onder die naam zijn opgeslagen: telefoonnummer, e-mailadres, huisadres.
• Nameservers bepalen welk adresboek het officiële is voor die naam.
• Caching is je telefoon die een nummer een tijdje onthoudt. Als je vriend van nummer verandert, blijven sommige telefoons het oude nummer bellen totdat hun opgeslagen kopie wordt ververst — dat is DNS-“propagatie”.

De onderdelen van een domeinnaam

Neem app.example.com:

Je koopt een domein niet echt; je registreert het voor een periode (meestal een jaar of langer) en verlengt het. Laat je het verlopen, dan kan iemand anders het registreren.

Hoe een DNS-opzoeking werkt

Wanneer iemand app.example.com intypt:

1. De browser vraagt een DNS-resolver — meestal beheerd door hun internetprovider of een openbare dienst — om het adres.
2. Als de resolver een recent gecachte uitkomst heeft, antwoordt hij meteen.
3. Zo niet, dan werkt hij zich omlaag door de hiërarchie: de rootservers wijzen naar de .com-servers, die naar de nameservers van jouw domein wijzen.
4. Je nameservers geven het record terug dat je hebt ingesteld, zoals een CNAME naar je host of een A-record met een IP-adres.
5. De resolver slaat het antwoord op voor de TTL (time to live) van het record en geeft het aan de browser, die verbinding maakt met de server.

Dit gebeurt meestal in milliseconden.

DNS-recordtypes die je echt gaat gebruiken

Enkele regels die het waard zijn om te kennen:

• Een CNAME kan geen naam delen met andere records. Daarom kan een standaard CNAME niet op het hoofddomein, dat altijd NS- en andere records heeft. Veel DNS-providers bieden oplossingen die ALIAS, ANAME of CNAME-flattening heten.
• TXT-records doen veel werk voor e-mail. SPF bepaalt wie namens jouw domein mail mag versturen; DKIM publiceert een sleutel om handtekeningen te controleren; DMARC vertelt ontvangers wat ze moeten doen met mail die die controles niet haalt.
• Lagere MX-nummers betekenen een hogere prioriteit. Mail probeert eerst de laagste.

Propagatie en TTL

“Propagatie” doet vermoeden dat wijzigingen langzaam over het internet worden verspreid. In werkelijkheid gaat het om caching: resolvers bewaren een kopie van elk antwoord voor de TTL, en vragen pas opnieuw als die verloopt. Dus:

• Een nieuw record dat nog nooit is opgezocht, werkt vaak binnen enkele minuten.
• Het wijzigen van een bestaand record duurt maximaal de oude TTL voordat het overal zichtbaar is.
• Het wijzigen van nameservers kan één tot twee dagen duren, omdat die records op TLD-niveau langer worden bewaard.

Een handige truc: verlaag vóór een geplande wijziging de TTL van het record (bijvoorbeeld naar enkele minuten), wacht tot de oude TTL is verstreken, en doe dan de wijziging.

Een voorbeeld: een boekingsapp koppelen aan je domein

Je bezit jouwsalon.nl. Je huidige website en Google Workspace-e-mail gebruiken het al. Je hebt een boekingsapp gebouwd en wilt die op boek.jouwsalon.nl.

1. Zoek waar je DNS wordt beheerd. Dat kan je registrar zijn of een aparte DNS-provider. Je NS-records vertellen het je.
2. Voeg een CNAME toe voor boek dat wijst naar het doel dat je apphost je geeft.
3. Voeg een TXT-record toe dat je host vraagt om eigendom te bewijzen, als die dat gebruikt.
4. Laat MX- en e-mail-TXT-records ongemoeid. E-mail blijft werken omdat je ze niet hebt aangeraakt.
5. Verifieer in je host zodra DNS is bijgewerkt. De host geeft dan een HTTPS-certificaat uit voor boek.jouwsalon.nl.
6. Test op een telefoon via mobiele data, die een andere resolver en cache gebruikt dan je thuis-wifi.

Als je de app op het hoofddomein jouwsalon.nl wilt, heb je A-records nodig of de ALIAS- of flattening-functie van je DNS-provider — en dan vervang je daarmee je huidige website. Meer stappen vind je bij hoe je een eigen domein koppelt.

Veelgemaakte fouten en misvattingen

• “Domein en hosting zijn hetzelfde.” Het domein is de naam; hosting is waar de app draait. DNS koppelt ze.
• Een A-record gebruiken terwijl de host een CNAME vraagt (of andersom). Volg de instructies van de host precies.
• Typefouten in het doel. Eén fout teken in een CNAME-doel en de verificatie mislukt.
• Nameservers wisselen zonder records over te nemen. DNS naar een nieuwe provider verhuizen zonder de MX- en TXT-records opnieuw aan te maken is een klassieke manier om e-mail te laten breken.
• Proxyen terwijl je dat niet moet. Sommige DNS-providers, zoals Cloudflare, kunnen verkeer proxyen. Sommige hosts vereisen dat het record op “alleen DNS” staat, zodat ze certificaten kunnen uitgeven.
• “Onbekende” TXT-records verwijderen. Het zijn vaak verificatie- of e-mailbeveiligingsrecords waar iets van afhangt.
• Het domein laten verlopen. Zet automatische verlenging aan en houd je betaalkaart actueel.

Wat je aan je AI-appbouwer kunt vragen

DNS staat buiten je code, dus het gaat hier meer om wat je moet vragen:

• “Welk exact DNS-record heb ik nodig voor app.mijndomein.nl — type, naam en waarde?”
• “Heeft deze wijziging invloed op mijn e-mail?”
• “Mijn domein toont een fout nadat ik het record heb toegevoegd. Wat moet ik controleren?”
• “Voeg de juiste canonieke URL en redirects toe, zodat www en niet-www niet allebei de site tonen.”
• “Stel het verzenden van e-mail vanaf mijn domein in — welke SPF-, DKIM- en DMARC-records heb ik nodig?” Zie hoe je e-mails vanuit je app verstuurt.

Eigen domeinen op Mythex

Elke gepubliceerde Mythex-app krijgt een adres jouwnaam.mythex.app. Op Pro kun je in plaats daarvan je eigen domein gebruiken: koop er een binnen Mythex (de registratie wordt apart gefactureerd, en de DNS voor gekochte domeinen wordt voor je beheerd), of koppel er een die je al bezit door een CNAME toe te voegen van een subdomein zoals app.example.com naar het adres jouwnaam.mythex.app van je app, en daarna op Verifiëren te klikken. HTTPS wordt automatisch uitgegeven. Staat je DNS bij Cloudflare, zet dat record dan op “alleen DNS”. Subdomeinen worden aanbevolen; voor hoofddomeinen hangt het af van de ALIAS- of flatteningondersteuning van je DNS-provider. In de documentatie over eigen domeinen lees je elke stap, en prijzen laat zien wat Pro bevat.

Veelgestelde vragen