TXT-record

En TXT-record er en type post i DNS, som knytter en tekstværdi til et domænenavn eller subdomæne. Teksten kan bruges af andre systemer til at kontrollere en indstilling eller læse en politik. Den vises normalt ikke for en almindelig besøgende på hjemmesiden.

TXT-records bruges til mange forskellige formål. En tjeneste kan bede dig indsætte en tilfældig verificeringskode for at bevise, at du styrer domænet. E-mailsystemer bruger TXT-formatet til blandt andet SPF, offentlige DKIM-nøgler og DMARC-politikker.

Navnet kan få posten til at lyde som et frit notefelt, men værdien skal ofte følge en præcis syntaks. Et manglende semikolon, forkert hostnavn eller ekstra anførselstegn kan gøre, at den modtagende tjeneste ikke kan læse posten.

TXT-recorden ligger i den aktive DNS-zone. Det betyder, at den skal oprettes hos den udbyder, som domænets nameservere peger på. Det er ikke nødvendigvis samme virksomhed, som har solgt domænet, hoster hjemmesiden eller leverer e-mail.

Læs først leverandørens instruktion præcist. Den angiver typisk type, navn eller host, værdi og eventuelt TTL. På roddomænet bruges ofte @ eller et tomt felt, men DNS-paneler viser det forskelligt. Kopiér ikke et eksempel fra en anden udbyder uden at forstå panelets format.

Kontrollér derefter, hvor DNS styres. Slå nameserverne op og log ind hos den relevante udbyder. Opretter du posten i et gammelt webhotel, mens nameserverne peger på en ekstern DNS-tjeneste, sker der intet på det aktive domæne.

Indsæt værdien uden at omskrive den. Nogle paneler tilføjer selv anførselstegn omkring lange tekststrenge eller deler dem teknisk op. Det er normalt, så længe en DNS-forespørgsel returnerer den samlede værdi korrekt.

Efter gemning bør posten kontrolleres med et DNS-opslag eller leverandørens verificeringsknap. Opdateringen kan være synlig hurtigt, men caches og TTL kan give ventetid. Undgå at oprette den samme record igen og igen, mens du venter.

Google Workspace beder en virksomhed bevise ejerskab af example.dk. Virksomheden får en værdi som google-site-verification=... og opretter en TXT-record på roddomænet. Når Google kan læse værdien i DNS, godkendes domænet. Koden påvirker ikke hjemmesidens indhold.

På samme domæne findes en TXT-record, der begynder med v=spf1. Den beskriver, hvilke systemer der må sende e-mail for domænet. Det er stadig en TXT-record, men indholdet følger SPF’s regler og bør administreres som én samlet politik.

En DKIM-record placeres ofte på et navn som selector._domainkey.example.dk. Værdien indeholder den offentlige nøgle. En DMARC-record ligger typisk under _dmarc.example.dk. De tre poster bruger samme DNS-type, men har forskellige navne og funktioner.

En virksomhed indsætter verificeringskoden i webhotellets DNS-panel, men domænet bruger Cloudflare-nameservere. Leverandøren kan ikke finde posten. Da værdien oprettes i den aktive Cloudflare-zone, lykkes verificeringen uden ændringer på hjemmesiden.

Den mest almindelige fejl er forkert placering. Mange domæner har været flyttet mellem registrator, hosting og CDN, og gamle paneler kan stadig se aktive ud. Nameserverne er facit for, hvilken zone der offentliggøres.

En anden fejl er at skrive hele domænet i et felt, hvor panelet automatisk tilføjer domænet. Resultatet kan blive _dmarc.example.dk.example.dk. Se altid, hvordan panelet viser den fulde record efter gemning.

Pas også på flere SPF-poster. Et domæne må ikke have to separate SPF-politikker på samme navn. Hvis en ny mailtjeneste skal godkendes, skal den normalt flettes ind i den eksisterende SPF-værdi i stedet for at blive oprettet som endnu en record.

Til sidst bør gamle verificeringsrecords gennemgås, når tjenester opsiges. En tilfældig verificeringskode er sjældent farlig alene, men en ryddelig DNS-zone gør det lettere at se aktive systemer og opdage poster, der ikke længere har et formål.

DNS-paneler kan vise lange TXT-værdier som flere tekststykker. Ved opslag samles de normalt til én logisk værdi. Det er især almindeligt ved lange DKIM-nøgler og behøver ikke være en fejl.

TXT er en generel recordtype. Det er indholdets præfiks og placering, der fortæller, om værdien er SPF, DKIM, DMARC eller en verificeringskode. Derfor bør hver post dokumenteres med leverandør og formål, selv om DNS-panelet ikke har et separat kommentarfelt.

En ændring i TXT-records påvirker normalt ikke den IP-adresse, som hjemmesiden bruger, eller den MX-record, der modtager e-mail. Men fejl i e-mailpolitikker kan påvirke levering, så produktionsrecords bør ændres med samme omhu som andre DNS-poster.

En TXT-record kan have flere værdier på samme host, når de tjener forskellige formål. Det er normalt for verificeringskoder. Undtagelsen er SPF, hvor flere separate politikker på samme navn giver fejl. Man skal derfor vurdere indholdet og ikke blot tælle TXT-rækker.

Når en leverandør beder om en host med understregning, eksempelvis _dmarc eller _acme-challenge, er tegnet en del af navnet. Det skal ikke fjernes som en formateringsfejl. DNS-paneler kan dog vise værtsnavnet forskelligt, så den fulde record bør kontrolleres udefra.

Certifikatudstedere kan bruge midlertidige TXT-records til DNS-validering af domænekontrol. De har et andet formål end SSL-certifikatet selv. Recorden beviser kontrollen under udstedelsen, mens certifikatet senere bruges af HTTPS-forbindelsen.

Nogle verifikationer kræver, at recorden bliver stående, mens andre kun kontrolleres én gang. Følg leverandørens dokumentation før oprydning. Fjernes en nødvendig record, kan automatisk fornyelse eller løbende ejerskabskontrol stoppe senere uden en tydelig fejl på hjemmesiden.

En lav TTL kan vælges før en planlagt ændring, men den gør ikke alle resolver-caches øjeblikkelige. Når ændringen er stabil, kan TTL hæves igen efter jeres driftsbehov. For verificeringsrecords er en standardværdi ofte tilstrækkelig.

DNS-opslag viser den offentliggjorte værdi, men ikke nødvendigvis om den eksterne tjeneste har accepteret den. Kontrollér begge dele: først at recorden kan ses korrekt, derefter at leverandørens validering eller mailtest faktisk består.

Gem ikke interne hemmeligheder i TXT-records. DNS er offentligt læsbart. Verificeringskoder er designet til offentliggørelse, men adgangskoder, API-nøgler og private nøgler hører aldrig hjemme i en offentlig DNS-zone.

Ved fejlsøgning bør du spørge efter recordtypen og det fulde navn, ikke blot et screenshot af værdien. To identiske tekstværdier på forskellige hosts er to forskellige records, og det er ofte værtsnavnet, der er forkert.

Nogle DNS-udbydere har en proxyfunktion for webrecords, men TXT-records publiceres normalt direkte. Bland derfor ikke indstillinger for CDN-proxy på A- og CNAME-records sammen med den tekstbaserede verifikation. De ligger i samme panel, men løser forskellige opgaver.

Gem en eksport eller oversigt før større DNS-ændringer. TXT-records bliver let overset, fordi hjemmesiden stadig kan åbne uden dem. Problemet viser sig måske først ved næste nyhedsbrev, certifikatfornyelse eller domæneverificering.

Når flere tjenester kræver verifikation, kan domænet have mange TXT-records samtidig. Det er normalt, så længe hver record har korrekt navn og værdi. Du bør ikke slette en ukendt TXT-record blot for at “rydde op”, før du har fundet ud af, om den bruges af mail, analyse, certifikater eller en ekstern platform.

Ved overdragelse af et domæne bør DNS-dokumentationen følge med. En ny leverandør kan ellers flytte de synlige webrecords og glemme verifikationer, som ikke umiddelbart påvirker hjemmesiden. En enkel liste over formål, ejer og dato gør fremtidige ændringer væsentligt sikrere.

DNS-værktøjer kan vise forskellige resultater under udrulningen, fordi de spørger forskellige resolver-systemer med hver deres cache. Kontrollér derfor recorden fra flere steder og sammenhold resultatet med TTL. En manglende værdi få minutter efter ændringen er ikke nødvendigvis en fejl, men efter længere tid bør navn, zone og syntax undersøges.

Når vi lancerer hjemmesider eller webshops, kontrollerer vi de tekniske afhængigheder omkring domænet. Vores artikel om HTTP og HTTPS, forklarer et andet lag af den teknik, som ofte bliver blandet sammen med DNS.