Hvordan domener og DNS fungerer: en guide for ikke-utviklere

Et domene er navnet folk skriver for å komme til nettstedet ditt, for eksempel example.com, og DNS (Domain Name System) er internettets telefonkatalog som oversetter det navnet til hvor nettstedet ditt faktisk ligger. Du leier domenet fra en registrar, og legger deretter til DNS-poster som sier «nettstedet ligger der» og «e-posten går hit». Å koble et eget domene til en app handler mest om å legge til riktig post på riktig sted og vente til den trer i kraft.

Hvorfor det betyr noe når du bygger med KI

En KI-appbygger kan skrive og hoste appen din, men domenet ditt ligger utenfor den, ofte hos et annet selskap, i et kontrollpanel fullt av ukjente posttyper. Her stopper mange lanseringer: appen er klar, men domenet viser en feil, eller e-posten slutter å virke etter en DNS-endring.

Litt forståelse kommer langt. Du vet hvilken post hosten din ber om, hvorfor den ikke har fungert ennå, og hvordan du unngår å ødelegge det som allerede er avhengig av domenet ditt, som e-post.

En hverdagslig analogi

Tenk på kontaktlisten på telefonen din.

Du husker ikke vennens nummer; du trykker på navnet deres, og telefonen slår opp nummeret. DNS gjør det samme for internett: du skriver example.com, og DNS slår opp nummeret (IP-adressen) til serveren du skal koble til.

• Domenet er kontaktens navn.
• Registraren er selskapet som offisielt registrerer at navnet er ditt.
• DNS-postene er detaljene lagret under navnet: telefonnummer, e-postadresse, hjemmeadresse.
• Navnetjenerne er hvilken kontaktliste som er den offisielle for navnet.
• Bufring er telefonen som husker et nummer en stund. Hvis vennen din bytter nummer, vil noen telefoner fortsette å ringe det gamle til den lagrede kopien oppdateres — det er DNS-«propagering».

Delene av et domenenavn

Ta app.example.com:

Du kjøper ikke et domene for alltid; du registrerer det for en periode (vanligvis et år eller mer) og fornyer det. Lar du det utløpe, kan noen andre registrere det.

Slik fungerer et DNS-oppslag

Når noen skriver app.example.com:

1. Nettleseren spør en DNS-resolver — vanligvis drevet av internettleverandøren deres eller en offentlig tjeneste — om adressen.
2. Hvis resolveren har et friskt bufret svar, svarer den umiddelbart.
3. Hvis ikke, går den nedover hierarkiet: rotserverne peker den til .com-serverne, som peker den til domenets navnetjenere.
4. Navnetjenerne dine returnerer posten du satte, for eksempel en CNAME til hosten din eller en A-post med en IP-adresse.
5. Resolveren bufrer svaret for postens TTL (time to live) og gir det til nettleseren, som kobler seg til serveren.

Dette skjer vanligvis på millisekunder.

DNS-posttyper du faktisk kommer til å bruke

Noen regler verdt å kjenne til:

• En CNAME kan ikke dele navn med andre poster. Derfor kan en vanlig CNAME ikke brukes på rotdomenet, som alltid har NS- og andre poster. Mange DNS-leverandører tilbyr løsninger kalt ALIAS, ANAME eller CNAME-flattening.
• TXT-poster gjør mye av e-postarbeidet. SPF lister hvem som kan sende post for domenet ditt; DKIM publiserer en nøkkel for å verifisere signaturer; DMARC forteller mottakere hva de skal gjøre med post som feiler disse kontrollene.
• Lavere MX-tall betyr høyere prioritet. E-post prøver den laveste først.

Propagering og TTL

«Propagering» får det til å høres ut som om endringer sprer seg sakte over internett. Det som faktisk skjer er bufring: resolvere beholder en kopi av hvert svar for TTL-en, og spør først på nytt når den utløper. Så:

• En ny post som aldri har blitt slått opp, fungerer ofte innen minutter.
• Endring av en eksisterende post tar opptil den gamle TTL-en før den er synlig overalt.
• Endring av navnetjenere kan ta opptil ett–to døgn, fordi disse postene bufres lenger på toppdomenenivå.

Et nyttig triks: før en planlagt endring, senk postens TTL (for eksempel til noen få minutter), vent til den gamle TTL-en har gått, og gjør deretter endringen.

Et eksempel: koble en bookingapp til domenet ditt

Du eier dinfrisor.com. Den nåværende nettsiden din og Google Workspace-e-posten bruker allerede domenet. Du har bygget en bookingapp og vil ha den på book.dinfrisor.com.

1. Finn hvor DNS-en din styres. Det kan være hos registraren din eller en egen DNS-leverandør. NS-postene dine forteller deg det.
2. Legg til en CNAME for book som peker til målet appverten din oppgir.
3. Legg til eventuelle TXT-poster verten ber om for å bevise eierskap, hvis den bruker en.
4. La MX- og e-post-TXT-postene være. E-posten fortsetter å fungere fordi du ikke har rørt den.
5. Verifiser i verten når DNS-en har oppdatert seg. Verten utsteder deretter et HTTPS-sertifikat for book.dinfrisor.com.
6. Test på en telefon med mobildata, som bruker en annen resolver og bufring enn hjemme-Wi-Fi-et ditt.

Hvis du ville hatt appen på rotdomenet dinfrisor.com i stedet, trenger du A-poster eller DNS-leverandørens ALIAS-/flattening-funksjon — og du ville erstattet den nåværende nettsiden din der. For flere steg, se slik kobler du til et eget domene.

Vanlige feil og misforståelser

• «Domenet og hostingen er det samme.» Domenet er navnet; hosting er der appen kjører. DNS kobler dem sammen.
• Bruke en A-post når verten ba om en CNAME (eller omvendt). Følg hostens instruksjoner nøyaktig.
• Skrivefeil i målet. Ett feil tegn i en CNAME-mål gjør at verifiseringen feiler.
• Bytte navnetjenere uten å kopiere postene. Å flytte DNS til en ny leverandør uten å gjenopprette MX- og TXT-poster er en klassisk måte å ødelegge e-post på.
• Proxy når du ikke bør. Noen DNS-leverandører, som Cloudflare, kan proxye trafikk. Noen hoster må ha posten satt til «DNS only» for å kunne utstede sertifikater.
• Slette «ukjente» TXT-poster. De er ofte verifiserings- eller e-postsikkerhetsposter som noe er avhengig av.
• La domenet utløpe. Slå på automatisk fornyelse og hold betalingskortet oppdatert.

Hva du bør spørre KI-appbyggeren din om

DNS ligger utenfor koden din, så dette handler mer om hva du bør spørre om:

• «Hvilken eksakt DNS-post trenger jeg for app.mittdomene.no — type, navn og verdi?»
• «Vil denne endringen påvirke e-posten min?»
• «Domenet mitt viser en feil etter at jeg la til posten. Hva bør jeg sjekke?»
• «Legg til riktig kanonisk URL og omdirigeringer slik at www og uten www ikke begge viser nettstedet.»
• «Sett opp sending av e-post fra domenet mitt — hvilke SPF-, DKIM- og DMARC-poster trenger jeg?» Se slik sender du e-post fra appen din.

Egne domener på Mythex

Hver publisert Mythex-app får en adresse på navnDitt.mythex.app. På Pro kan du bruke ditt eget domene i stedet: kjøp et inne i Mythex (registrering faktureres separat, og DNS for kjøpte domener håndteres for deg), eller koble til et du allerede eier ved å legge til en CNAME fra et underdomene, for eksempel app.example.com, til appens navnDitt.mythex.app-adresse, og deretter klikke Verify. HTTPS utstedes automatisk. Hvis DNS-en din ligger på Cloudflare, sett den posten til «DNS only». Underdomener anbefales; rotdomener avhenger av DNS-leverandørens støtte for ALIAS eller flattening. Dokumentasjonen for egne domener går gjennom hvert steg, og prissiden viser hva Pro inkluderer.

Spørsmål