Indstil Hetzner DNS korrekt - eksempel på konfiguration med hetzner dns-konfiguration

Hetzner DNS-konfiguration så hjemmeside, subdomæner og mail fungerer uden omveje, og ændringer træder hurtigt i kraft. I denne vejledning viser jeg dig de nødvendige indstillinger i Hetzner DNS, en gennemprøvet eksempelkonfiguration og praktiske testmetoder, så du kan undgå fejl på et tidligt tidspunkt og holde din zone ren.

Centrale punkter

Følgende nøglepunkter giver dig et hurtigt overblik over, hvad der er vigtigt for en pålidelig DNS-zone.

• Navneserver indtast korrekt hos registratoren
• A/AAAA til internettet, MX/TXT til mail
• TTL Vælg passende, og vent på udbredelse
• SPF/DKIM mod spam og spoofing
• Overvågning og test efter ændringer

DNS i en nøddeskal: hvad du virkelig har brug for

Jeg tildeler et domæne via Optegnelser specifikke destinationer, så browsere og mailservere kan finde mine tjenester. A A-Record peger på en IPv4-adresse, en AAAA på IPv6, og en MX definerer leveringen af e-mails. Et CNAME danner et alias, der peger på et andet navn, mens TXT indeholder oplysninger til SPF eller verifikationer. En ren baseline består af A/AAAA for hoveddomænet, CNAME for www, MX for mail og en SPF-TXT. På den måde holder jeg zonen overskuelig, hurtig at vedligeholde og åben for senere udvidelser.

Tilføj domæne til Hetzners DNS-konsol

I DNS-konsollen opretter jeg først en ny Zone og tjekker, at domænet er stavet helt rigtigt. Derefter aktiverer jeg den manuelle vedligeholdelse af Optegnelserså jeg kan oprette og ændre specifikke poster. Tip: Jeg noterer IP-adresser og mail-destinationer på forhånd, så jeg kan indtaste alt uden afbrydelser. På den måde undgår jeg tastefejl og sætter posterne i en rolig rækkefølge. Så snart zonen er klar, planlægger jeg ændringen af navneservere og de efterfølgende kontroller.

Indtast navneserveren korrekt hos registratoren

Når jeg har oprettet zonen, indtaster jeg Navneserver fra Hetzner, så administrationen er centraliseret i DNS-konsollen. De sædvanlige indtastninger er ns1.first-ns.de, robotns2.second-ns.de og robotns3.second-ns.com. For .de- eller .at-domæner sætter jeg mine egne navneservere op med Lim-pladerså referencerne og IP'erne bliver gemt. Hvis du aldrig har gjort det før, kan du finde de enkelte trin i guiden til Opsæt limplader. Derefter tager det lidt tid at skifte, da opdateringen kan komme med forskellig hastighed rundt omkring i verden.

Eksempel på konfiguration: Gør hjemmesiden og e-mailen eksekverbar

Til en typisk webtilstedeværelse bruger jeg en A-Record for roddomænet, en CNAME for www og passende mail records. En SPF-TXT forhindrer eksterne servere i at sende e-mails i domænets navn. Eventuelt tilføjer jeg en AAAA-record, hvis webserveren IPv6 giver. For eksterne mailtjenester som ForwardMX tilpasser jeg MX og gemmer deres specifikationer. Følgende tabel viser et solidt udgangspunkt for mange opsætninger.

Navn	Type	Værdi	Hint
@	A	195.201.210.43	Webserver IPv4
@	AAAA	Valgfrit: 2a01:4f8:xxxx:xxxx::1	Webserver IPv6
www	CNAME	@	Alias på rod
@	MX	mx1.forwardmx.net	Prio 10
@	TXT	"v=spf1 include:_spf.forwardmx.net -all"	SPF mod spoofing

Aktivér DNSSEC og indstil DS-record

Hvis manipulationssikkerhed er vigtig for mig, aktiverer jeg DNSSEC for zonen. I Hetzner-konsollen genererer jeg signaturnøgler til dette og modtager derefter de nødvendige DS-datasom jeg deponerer hos registratoren. Jeg kontrollerer, at algoritmen og digest er blevet overført korrekt. Derefter venter jeg, indtil kæden fra registratoren til zonen valideres korrekt. Før større nøglerotationer sænker jeg TTL og planlægger et tidsvindue, så resolvere ser nye signaturer i god tid. Vigtigt: Hvis der opstår en fejl under ændringen, mislykkes valideringerne for modtagerne - jeg har derfor en rollback klar (slet ikke gamle nøgler for tidligt) og tester med valideringsresolvere.

Indstil TTL korrekt og forstå forplantning

Die TTL bestemmer, hvor længe resolverne cacher en post. Til konverteringer vælger jeg en kort TTL (f.eks. 300 sekunder), så ændringer bliver synlige hurtigt. Efter den endelige opsætning øger jeg værdierne igen for at spare anmodninger og opnå en ensartet opløsning. De, der implementerer ofte, holder sig gerne til 600-1200 sekunder, mens de, der sjældent foretager ændringer, bruger 3600-14400. Et praktisk overblik over beslutningen får man ved at se på Optimalt valg af TTL.

Apex-domæne, CAA og certifikater under kontrol

For SaaS-mål på Zone Apex Det kan jeg huske CNAME er ikke tilladt på @. Jeg bruger derfor udbyderens A/AAAA eller indstiller en omdirigering til www på webserverniveau. For certifikattildelingen kontrollerer jeg med CAA-rekorderhvilke CA'er der er autoriseret til at udstede certifikater. For eksempel vedligeholder jeg kun den CA, jeg rent faktisk bruger, og tilføjer eventuelt en mailadresse til rapporter. Hvis jeg skifter CA, øger jeg kort TTL og opdaterer CAA, før jeg udsteder. For wildcards via ACME DNS-01 sørger jeg for, at TXT-records under _acme-udfordring kan indstilles hurtigt og ryddes op automatisk, så der ikke efterlades gamle udfordringer.

Opret underdomæner og tjenester på en ren måde

For hvert underdomæne opretter jeg en passende A- eller CNAME-record, afhængigt af om subdomænet peger direkte på en IP eller et navn. Eksempel: blog.example.de som A-record til blog-VM'en, cdn.example.de som CNAME til et CDN-navn. For API'er skelner jeg strengt mellem interne og offentlige navne for at undgå risici. Standardiserede navne som api, app, img hjælper med vedligeholdelse og overvågning. På den måde holder jeg zonen struktureret og kan tydeligt tildele ændringer.

Wildcards, SRV og særlige recordtyper

Jeg bruger Wildcard Records (*.example.de), f.eks. til opsætninger med flere klienter. Jeg sørger for, at nøjagtige indtastninger altid har forrang frem for jokertegn. For tjenester som SIP, Matrix eller Autodiscover opretter jeg SRV-registreringer og tjek formatet og prioriteterne. TXT-optegnelser med langt indhold (f.eks. 2048-bit DKIM) opdeles i flere citatsegmenter, så parsere kan flette dem korrekt. Jeg undgår flere SPF-poster og kombinerer poster i en gyldig SPF for ikke at bryde opslagsgrænsen.

Pålidelig e-mail-levering: SPF, DKIM og DMARC

Til troværdig e-mail bruger jeg MX en ren SPF-TXT, der dækker mine afsendersystemer. Jeg aktiverer også DKIM hos den anvendte mailservice og publicerer DKIM-selektoren som TXT under selector._domainkey. Jeg bruger DMARC til at definere, hvordan modtagere skal håndtere mails, der ikke består SPF/DKIM. Jeg starter ofte med "p=none", evaluerer rapporter og skifter senere til "quarantine" eller "reject". Denne sekvens reducerer risici og øger gradvist leveringskvaliteten.

Uddybning af SPF/DKIM/DMARC i praksis

Jeg holder SPF så lavt som muligt: kun nødvendigt inkludere-mekanismer og aldrig mere end én SPF pr. værtsnavn. For at overholde grænsen på 10 DNS-opslag reducerer jeg kæder eller bruger IP4/IP6-mekanismer, hvis de er stabile. For DKIM-rotation Jeg bruger to aktive selektorer (gammel/ny), udgiver den nye nøgle, skifter mailservice og sletter først den gamle efter et par dage. Med DMARC I første omgang indstiller jeg rapporteringsadresser (rua/ruf) og kontrollerer justering (aspf/adkim). Til underdomæner kan jeg bruge sp= definere en separat politik, hvis de sender separat. På den måde reagerer jeg på reelle trafikdata i stedet for antagelser.

Omvendt DNS (PTR) til ren postlevering

Ud over MX, SPF og DKIM har jeg opsat Omvendt DNS (PTR) for udgående mailservere. IP'ens PTR peger på et værtsnavn, som igen opløses korrekt til den samme IP via A/AAAA (Frem/tilbage-match). Jeg indstiller PTR pr. IP direkte hos IP-ejeren (f.eks. i serverinterfacet) - ikke i domænets zonestyring. Jeg bruger nibble-formatet til IPv6. En passende PTR reducerer spamklassifikationer og hjælper med omdømme. Hvis mailen kører via en ekstern tjeneste, lader jeg dens PTR være, som den er, og undgår blandede afsenderkilder uden SPF-tilpasning.

Typiske fejl og hurtige løsninger

Hvis et domæne ikke løses, tjekker jeg først TTLnavneserverposter og den korrekte stavning af posterne. Det andet kig går til ForplantningNogle opløsere cacher længere, især efter at TTL er steget. Jeg sammenligner opløsningen ved hjælp af forskellige DNS-kontrollører for at genkende regionale forskelle. I tilfælde af lokale problemer skifter jeg midlertidigt til offentlige resolvere som 1.1.1.1 eller 8.8.8.8. Hvis fejlen kun opstår i interne netværk, tjekker jeg interne resolvere og regler i containere, Kubernetes eller CoreDNS-konfigurationer.

Testmetoder: dig, nslookup og end-to-end

Jeg tester ikke kun poster, men hele stien:

• grave A/AAAA/CNAME/MX/TXT: Tjek svar, TTL og autoritet
• grave +sporeSe delegationskæde og navneserveradfærd
• SMTP-testTjek HELO/EHLO, TLS og banner
• HTTPS ægteCertifikatkæde, værtsnavn, omdirigeringer

På den måde genkender jeg også fejl, som ikke er synlige i rene DNS-svar, f.eks. forkerte VirtualHost-mappinger eller udløbne certifikater. Når jeg har foretaget ændringer, venter jeg mindst en TTL, før jeg drager endelige konklusioner.

Arbejd effektivt med Hetzner-konsollen

Jeg grupperer relaterede Indgange tid, indstiller en kort TTL, før jeg foretager større ændringer, og udgiver så alt på én gang. Før jeg gemmer, tjekker jeg igen MX-prioriteter, SPF-syntaks og mål-IP'en for A-recorden. For serveradministration og -processer kan de kompakte instruktioner på Tips til Hetzner-robotten. Efter implementeringer tester jeg http, https og mail med rigtige forespørgsler, ikke kun via ping. Det giver mig mulighed for at genkende fejl, som rene DNS-forespørgsler ikke viser.

Automatisering: API, skabeloner og ACME

Jeg sparer tid ved at automatisere. Til regelmæssige udrulninger bruger jeg API i DNS-konsollen for at oprette, ændre eller slette poster. Jeg arbejder med skabeloner for tilbagevendende mønstre (f.eks. Web + Mail + DMARC) og indsætter kun projektspecifikke værdier. For Let's Encrypt DNS-01 inkluderer jeg en automatiseret TXT-recordwriter og integrerer den i fornyelsesworkflowet. Vigtigt: Jeg behandler API-tokens som passwords, tildeler dem til specifikke projekter og tilbagekalder adgangen, når de ikke længere er nødvendige.

Avancerede opsætninger: Split-Horizon, CDN og ACME

Jeg adskiller interne og eksterne brugere, hvis det er nødvendigt DNS-visninger, så den interne app peger på private IP'er og besøgende på offentlige destinationer. Skal jeg bruge en CDNJeg henviser underdomæner til CDN-navnet via CNAME og aktiverer TLS der. For automatiske certifikater via ACME/Let's Encrypt indstiller jeg eventuelt DNS-01-udfordringer via TXT, hvis HTTP-01 ikke matcher. Automatisering er vigtig her, så fornyelser udføres i god tid. Logs og meddelelser hjælper med at genkende fejl i god tid.

Ydeevne og tilgængelighedsmønstre

Jeg øger tilgængeligheden med enkle midler: Flere A/AAAA-optegnelser (round robin) deler belastningen uden yderligere tjenester, forudsat at backends er statsløse eller deler sessioner. Under vedligeholdelse fjerner jeg midlertidigt enkelte IP'er og hæver derefter posten igen. En for kort TTL-kørsel kan belaste resolverne; jeg finder en balance mellem svarhastighed og cache-hitrate. Jeg indstiller klare processer for failovers uden sundhedstjek: I tilfælde af en fejl bytter jeg poster, overvåger dem aktivt og nulstiller dem igen efter gendannelse.

Sikkerhed og zonehygiejne

Jeg deaktiverer unødvendige Zoneoverførsler (AXFR) og kun offentliggøre NSder virkelig er autoritative. Jeg sletter regelmæssigt gamle eller forældreløse subdomæner, så der ikke opstår skyggeflader. For IDN'er tjekker jeg Punycode-stavning for at undgå stavefejl og fejl i specialtegn. Rollebaseret adgang i konsollen sikrer, at det kun er de rigtige personer, der ændrer zoner. Og helt pragmatisk: Jeg dokumenterer kort ændringer i teamværktøjet - det reducerer antallet af forespørgsler under driften betydeligt.

Migrations- og rollback-strategi

Før en flytning sænker jeg TTL (24-48 timer i forvejen), spejler alle Optegnelser i den nye zone og tester opløsningen direkte via de nye navneservere. Først når alt er korrekt, sætter jeg Navneserver hos registratoren. Efter delegeringen overvåger jeg trafik og fejl. Hvis noget går galt, ruller jeg tilbage på en kontrolleret måde eller retter individuelle poster. Jeg planlægger DNSSEC-migrationer særligt konservativt og lader den gamle signaturkæde være på plads, indtil den nye er sikkert på plads. Til sidst nulstiller jeg TTL til produktionskompatible værdier.

Kort sammenligning af udbydere med hensyn til ydeevne og fleksibilitet

Ydeevne, funktioner og DNS-frihed bestemme, hvor fleksibelt jeg udruller projekter. I praksis leverer de store hostere solide Svartidermen er forskellige med hensyn til betjening, funktioner og support. Jeg vurderer udvalget i forhold til ydeevne, udvalg af funktioner, hjælpekvalitet og DNS-muligheder. Følgende oversigt viser et kondenseret billede, som jeg kan bruge til at træffe beslutninger. I sidste ende er det, hvad mit projekt virkelig har brug for, der tæller, ikke den største funktionsliste.

Udbyder	Ydelse	Omfanget af funktioner	Støtte	DNS-fleksibilitet	Rangering
webhoster.de	Høj	Meget omfattende	Til toppen	Maksimum	1
Hetzner	Høj	Omfattende	God	Høj	2
Contabo	Medium	Standard	O. K.	Medium	3

Kort opsummeret

Jeg satte en Hetzner DNS-zone på en struktureret måde: Opret zone, indtast navneserver hos registrator, sæt core records for web og mail, og test derefter. Med passende TTL Jeg forkorter overgangstiderne og øger dem igen efter afslutningen for at mindske belastningen. SPF, DKIM og DMARC styrker leveringen og beskytter domænet mod misbrug. Jeg holder underdomæner konsistente og adskiller interne fra offentlige destinationer. Med denne eksempelkonfiguration og de daglige kontroller forbliver din hetzner dns-konfiguration pålidelig, hurtig og nem at vedligeholde.