Sådan virker domæner og DNS: en guide for ikke-udviklere

Et domæne er navnet folk skriver for at komme til dit website, som example.com, og DNS (Domain Name System) er internettets telefonbog, der oversætter det navn til, hvor dit website faktisk ligger. Du lejer domænet hos en registrator og tilføjer derefter DNS-poster, der siger "hjemmesiden ligger dér" og "e-mail går herhen". At forbinde et eget domæne til en app handler mest om at tilføje den rigtige post det rigtige sted og vente på, at den træder i kraft.

Hvorfor det betyder noget, når du bygger med AI

En AI-app-builder kan skrive og hoste din app, men dit domæne ligger uden for den, ofte hos et andet firma, i et kontrolpanel fuldt af ukendte posttyper. Det er her mange lanceringer går i stå: appen er klar, men domænet viser en fejl, eller e-mailen holder pludselig op med at virke efter en DNS-ændring.

Lidt forståelse rækker langt. Du vil vide, hvilken post din hostingudbyder beder om, hvorfor den ikke har virket endnu, og hvordan du undgår at ødelægge det, der allerede er afhængigt af dit domæne, som e-mail.

En hverdagsanalogi

Tænk på din telefons kontaktliste.

Du husker ikke din vens nummer; du trykker på navnet, og telefonen slår det op. DNS gør det samme for internettet: du skriver example.com, og DNS slår nummeret (IP-adressen) op på den server, der skal forbindes til.

• Domænet er kontaktens navn.
• Registratoren er firmaet, der officielt registrerer, at navnet er dit.
• DNS-poster er oplysningerne gemt under navnet: telefonnummer, e-mailadresse, hjemmeadresse.
• Navneserverne er hvilken kontaktbog, der er den officielle for det navn.
• Caching er, at din telefon husker et nummer et stykke tid. Skifter din ven nummer, ringer nogle telefoner stadig til det gamle, indtil den gemte kopi er opdateret; det er DNS-"udbredelse".

Dele af et domænenavn

Tag app.example.com:

Du køber ikke et domæne helt; du registrerer det for en periode (typisk et år eller mere) og fornyer det. Lader du det udløbe, kan en anden registrere det.

Sådan virker et DNS-opslag

Når nogen skriver app.example.com:

1. Browseren spørger en DNS-resolver, typisk drevet af deres internetudbyder eller en offentlig tjeneste, om adressen.
2. Har resolveren et friskt cachet svar, svarer den straks.
3. Hvis ikke, arbejder den sig ned gennem hierarkiet: rodserverne peger den til .com-serverne, som peger den til dit domænes navneservere.
4. Dine navneservere returnerer den post, du har sat, for eksempel en CNAME til din host eller en A-post med en IP-adresse.
5. Resolveren cacher svaret i postens TTL (time to live) og giver det til browseren, som forbinder til serveren.

Det hele sker typisk på millisekunder.

DNS-posttyper, du faktisk bruger

Nogle regler, der er værd at kende:

• En CNAME kan ikke dele navn med andre poster. Derfor kan en standard-CNAME ikke ligge på rodomænet, som altid har NS- og andre poster. Mange DNS-udbydere tilbyder omgåelser kaldet ALIAS, ANAME eller CNAME-flattening.
• TXT-poster klarer meget af e-mailarbejdet. SPF angiver, hvem der må sende mail for dit domæne; DKIM offentliggør en nøgle til at verificere signaturer; DMARC fortæller modtagere, hvad de skal gøre med mail, der fejler disse tjek.
• Lavere MX-tal betyder højere prioritet. Mail prøver det laveste først.

Udbredelse og TTL

"Udbredelse" lyder, som om ændringer spredes langsomt over internettet. Det, der faktisk sker, er caching: resolvere gemmer en kopi af hvert svar i sin TTL og spørger først igen, når den udløber. Så:

• En ny post, der aldrig er slået op før, virker ofte inden for minutter.
• Ændring af en eksisterende post tager op til dens gamle TTL, før den ses overalt.
• Ændring af navneservere kan tage op til et døgn eller to, fordi disse poster caches længere på TLD-niveau.

Et nyttigt trick: før en planlagt ændring sænker du postens TTL (for eksempel til et par minutter), venter til den gamle TTL er gået, og foretager derefter ændringen.

Et eksempel: forbind en bookingapp til dit domæne

Du ejer dinfrisør.dk. Din nuværende hjemmeside og Google Workspace-e-mail bruger det allerede. Du har bygget en bookingapp og vil have den på book.dinfrisør.dk.

1. Find hvor din DNS administreres. Det kan være din registrator eller en separat DNS-udbyder. Dine NS-poster fortæller dig det.
2. Tilføj en CNAME for book, der peger på det mål, din app-host giver dig.
3. Tilføj en eventuel TXT-post, som din host beder om for at bevise ejerskab, hvis den bruger en.
4. Lad MX- og e-mail-TXT-poster være. E-mailen fortsætter med at virke, fordi du ikke har rørt den.
5. Verificér i din host, når DNS er opdateret. Hosten udsteder derefter et HTTPS-certifikat til book.dinfrisør.dk.
6. Test på en telefon med mobildata, som bruger en anden resolver og cache end dit hjemme-Wi-Fi.

Hvis du i stedet ville have appen på rodomænet dinfrisør.dk, skal du bruge A-poster eller din DNS-udbyders ALIAS/flattening-funktion, og du ville erstatte din nuværende hjemmeside dér. Flere trin finder du i sådan forbinder du et eget domæne.

Almindelige fejl og misforståelser

• "Domænet og hostingen er det samme." Domænet er navnet; hosting er, hvor appen kører. DNS forbinder dem.
• At bruge en A-post, når hosten bad om en CNAME (eller omvendt). Følg hostens instruktioner præcist.
• Tastefejl i målet. Ét forkert tegn i en CNAME-værdi, og verificeringen fejler.
• At skifte navneservere uden at kopiere posterne. At flytte DNS til en ny udbyder uden at genskabe MX- og TXT-poster er en klassisk måde at ødelægge e-mail på.
• Proxying når du ikke skal. Nogle DNS-udbydere, som Cloudflare, kan proxy'e trafik. Nogle hosts kræver, at posten står på "DNS only", så de kan udstede certifikater.
• At slette "ukendte" TXT-poster. De er ofte verificerings- eller e-mailsikkerhedsposter, noget afhænger af.
• At lade domænet udløbe. Slå automatisk fornyelse til, og hold betalingskortet opdateret.

Hvad du skal spørge din AI-builder om

DNS ligger uden for din kode, så det handler mere om, hvad du skal spørge om:

• "Hvilken præcis DNS-post skal jeg bruge for app.mindomæne.dk: type, navn og værdi?"
• "Vil denne ændring påvirke min e-mail?"
• "Mit domæne viser en fejl, efter jeg har tilføjet posten. Hvad skal jeg tjekke?"
• "Tilføj den korrekte kanoniske URL og omdirigeringer, så www og ikke-www ikke begge viser siden."
• "Opsæt afsendelse af e-mail fra mit domæne: hvilke SPF-, DKIM- og DMARC-poster får jeg brug for?" Se sådan sender du e-mails fra din app.

Egne domæner på Mythex

Hver udgivet Mythex-app får en adresse som dinnavn.mythex.app. På Pro kan du bruge dit eget domæne i stedet: køb et inde i Mythex (registrering faktureres separat, og DNS for købte domæner administreres for dig), eller forbind et du allerede ejer ved at tilføje en CNAME fra et underdomæne, som app.example.com, til din apps adresse dinnavn.mythex.app, og derefter klikke på Verificér. HTTPS udstedes automatisk. Hvis din DNS ligger hos Cloudflare, skal posten stå på "DNS only". Underdomæner anbefales; rodomæner afhænger af din DNS-udbyders understøttelse af ALIAS eller flattening. Dokumentationen om egne domæner gennemgår hvert trin, og priser viser, hvad Pro inkluderer.

Spørgsmål