Ställ in Hetzner DNS-inställningar korrekt - exempel på konfiguration med hetzner dns-konfiguration

Hetzner DNS-konfiguration så att webbplats, underdomäner och e-post fungerar utan omvägar och ändringar snabbt får effekt. I den här guiden visar jag dig de nödvändiga inställningarna i Hetzner DNS, en beprövad exempelkonfiguration och praktiska testmetoder så att du kan undvika fel i ett tidigt skede och hålla din zon ren.

Centrala punkter

Följande punkter ger dig en snabb överblick över vad som är viktigt för en tillförlitlig DNS-zon.

• Namngivare ange korrekt med registraren
• A/AAAA för webben, MX/TXT för post
• TTL Välj på lämpligt sätt och vänta på spridning
• SPF/DKIM mot skräppost och spoofing
• Övervakning och tester efter ändringar

DNS i ett nötskal: vad du verkligen behöver

Jag tilldelar en domän via Rekord specifika destinationer så att webbläsare och e-postservrar kan hitta mina tjänster. A A-Record pekar på en IPv4-adress, en AAAA på IPv6 och en MX definierar leverans av e-postmeddelanden. Ett CNAME bildar ett alias som pekar på ett annat namn, medan TXT innehåller information för SPF eller verifieringar. En ren baslinje består av A/AAAA för huvuddomänen, CNAME för www, MX för e-post och en SPF-TXT. På så sätt håller jag zonen tydlig, snabbt underhållbar och öppen för senare tillägg.

Lägg till domän i Hetzners DNS-konsol

I DNS-konsolen skapar jag först en ny Zon och kontrollerar att stavningen av domänen är exakt rätt. Sedan aktiverar jag det manuella underhållet av Rekordså att jag kan skapa och ändra specifika poster. Tips: Jag antecknar IP-adresser och e-postdestinationer i förväg så att jag kan skriva in allt utan avbrott. På så sätt undviker jag skrivfel och får en lugn ordning på posterna. Så snart zonen är klar planerar jag bytet av namnservrar och de efterföljande kontrollerna.

Ange namnservern korrekt hos registraren

När jag har skapat zonen går jag in i Namngivare från Hetzner så att administrationen centraliseras till DNS-konsolen. De vanliga posterna är ns1.first-ns.de, robotns2.second-ns.de och robotns3.second-ns.com. För .de- eller .at-domäner sätter jag upp mina egna namnservrar med Limskivorså att referenser och IP-adresser lagras. Om du aldrig har gjort detta tidigare kan du hitta de enskilda stegen i guiden till Upprätta limregister. Sedan tar jag lite tid på mig för omställningen, eftersom uppdateringen kan komma med olika hastighet runt om i världen.

Exempelkonfiguration: Gör webbplatsen och e-postmeddelandet körbara

För en typisk webbnärvaro använder jag en A-Record för rotdomänen, ett CNAME för www och lämpliga e-postposter. En SPF-TXT hindrar externa servrar från att skicka e-post i domänens namn. Eventuellt lägger jag till en AAAA-post om webbservern IPv6 tillhandahåller. För externa e-posttjänster som ForwardMX anpassar jag MX och lagrar deras specifikationer. Följande tabell visar en solid utgångspunkt för många konfigurationer.

Namn	Typ	Värde	Ledtråd
@	A	195.201.210.43	Webbserver IPv4
@	AAAA	Valfritt: 2a01:4f8:xxxx:xxxx::1	Webbserver IPv6
www	CNAME	@	Alias på root
@	MX	mx1.forwardmx.net	Prio 10
@	TXT	"v=spf1 include:_spf.forwardmx.net -all"	SPF mot spoofing

Aktivera DNSSEC och ange DS-rekord

Om manipulationssäkerhet är viktigt för mig, aktiverar jag DNSSEC för zonen. I Hetzner-konsolen genererar jag signaturnycklar för detta och får sedan de nödvändiga DS-datasom jag deponerar hos registraren. Jag kontrollerar att algoritmen och digesten har överförts korrekt. Sedan väntar jag tills kedjan från registraren till zonen valideras korrekt. Inför större nyckelbyten sänker jag TTL och planerar ett tidsfönster så att resolvers ser nya signaturer i god tid. Viktigt: Om ett fel uppstår under förändringen misslyckas valideringarna för mottagarna - jag har därför en rollback redo (radera inte gamla nycklar för tidigt) och testar med valideringsresolvers.

Ställ in TTL korrekt och förstå propagering

Die TTL avgör hur länge resolvers cachar en post. För konverteringar väljer jag en kort TTL (t.ex. 300 sekunder) så att förändringar syns snabbt. Efter den slutliga installationen ökar jag värdena igen för att spara förfrågningar och uppnå en konsekvent upplösning. De som distribuerar ofta gillar att hålla sig till 600-1200 sekunder, medan de som sällan gör ändringar använder 3600-14400. En praktisk översikt över beslutet ges av min titt på Optimalt TTL-val.

Apex-domän, CAA och certifikat under kontroll

För SaaS-mål på Zon Apex Jag minns att CNAME är inte tillåtet på @. Jag använder därför leverantörens A/AAAA eller ställer in en omdirigering till www på webbservernivå. För certifikattilldelningen kontrollerar jag med CAA Rekordvilka certifikatutfärdare som har rätt att utfärda certifikat. Jag underhåller till exempel bara den CA som jag faktiskt använder och lägger eventuellt till en e-postadress för rapporter. Om jag byter CA ökar jag TTL en kort stund och uppdaterar CAA innan utfärdande. För wildcards via ACME DNS-01 ser jag till att TXT-poster under _acme-utmaning kan ställas in snabbt och rensas upp automatiskt så att inga gamla utmaningar lämnas kvar.

Skapa underdomäner och tjänster på ett smidigt sätt

För varje underdomän skapar jag en lämplig A- eller CNAME-record, beroende på om subdomänen pekar direkt på en IP eller på ett namn. Exempel: blog.example.de som A-record till bloggens VM, cdn.example.de som CNAME till ett CDN-namn. För API:er gör jag en strikt åtskillnad mellan interna och offentliga namn för att undvika risker. Standardiserade namn som api, app, img hjälper till med underhåll och övervakning. På så sätt håller jag zonen strukturerad och kan tydligt tilldela ändringar.

Jokertecken, SRV och särskilda posttyper

Jag använder Wildcard Records (*.example.de), till exempel för konfigurationer som kan hantera flera klienter. Jag ser till att exakta poster alltid har företräde framför jokertecken. För tjänster som SIP, Matrix eller Autodiscover skapar jag SRV-register och kontrollera format och prioriteringar. TXT-poster med långt innehåll (t.ex. 2048-bitars DKIM) delas upp i flera citatsegment så att parsers kan sammanfoga dem korrekt. Jag undviker flera SPF-poster och kombinerar poster till en giltig SPF för att inte bryta uppslagsgränsen.

Tillförlitlig leverans av e-post: SPF, DKIM och DMARC

För pålitlig e-post använder jag MX en ren SPF-TXT som täcker mina sändande system. Jag aktiverar också DKIM hos den e-posttjänst som används och publicera DKIM-selektorn som TXT under selector._domainkey. Jag använder DMARC för att definiera hur mottagare ska hantera mail som inte passerar SPF/DKIM. Jag börjar ofta med "p=none", utvärderar rapporter och byter senare till "quarantine" eller "reject". Denna sekvens minskar riskerna och ökar gradvis leveranskvaliteten.

Fördjupande SPF/DKIM/DMARC i praktiken

Jag håller SPF så låg som möjligt: endast nödvändigt inkludera-mekanismer och aldrig mer än en SPF per värdnamn. För att uppfylla gränsen på 10 DNS-uppslagningar minskar jag kedjorna eller använder IP4/IP6-mekanismer om de är stabila. För DKIM-rotation Jag använder två aktiva väljare (gamla/nya), publicerar den nya nyckeln, byter e-posttjänst och raderar den gamla först efter några dagar. Med DMARC Jag ställer först in rapporteringsadresser (rua/ruf) och kontrollerar justering (aspf/adkim). För underdomäner kan jag använda sp= definiera en separat policy om de skickar separat. På så sätt reagerar jag på verkliga trafikdata i stället för antaganden.

Omvänd DNS (PTR) för ren e-postleverans

Förutom MX, SPF och DKIM konfigurerade jag Omvänd DNS (PTR) för utgående e-postservrar. IP:ns PTR pekar på ett värdnamn, som i sin tur löser korrekt till samma IP via A/AAAA (Matchning framåt/bakåt). Jag ställer in PTR per IP direkt med IP-ägaren (t.ex. i servergränssnittet) - inte i zonhanteringen för domänen. Jag använder nibble-formatet för IPv6. En lämplig PTR minskar skräppostklassificeringen och hjälper till med ryktet. Om e-post körs via en extern tjänst låter jag dess PTR vara som den är och undviker blandade avsändarkällor utan SPF-anpassning.

Typiska fel och snabba lösningar

Om en domän inte kan lösas kontrollerar jag först TTLnamnserverposter och korrekt stavning av posterna. Det andra utseendet går till FörökningVissa resolvers cachar längre, särskilt efter att TTL har ökat. Jag jämför upplösningen med hjälp av olika DNS-kontroller för att upptäcka regionala skillnader. Vid lokala problem byter jag tillfälligt till publika resolvers som 1.1.1.1 eller 8.8.8.8. Om felet bara uppstår i interna nätverk kontrollerar jag interna resolvers och regler i containrar, Kubernetes- eller CoreDNS-konfigurationer.

Testmetoder: dig, nslookup och end-to-end

Jag testar inte bara skivor, utan hela banan:

• gräva A/AAAA/CNAME/MX/TXT: Kontrollera svar, TTL och auktoritet
• gräva +spåraSe delegeringskedja och namnserverbeteende
• SMTP-testKontrollera HELO/EHLO, TLS och banner
• HTTPS verkligCertifikatkedja, värdnamn, omdirigeringar

På så sätt upptäcker jag även fel som inte syns i rena DNS-svar, till exempel felaktiga VirtualHost-mappningar eller utgångna certifikat. Efter att ha gjort ändringar väntar jag minst en TTL innan jag drar slutliga slutsatser.

Arbeta effektivt med Hetzner-konsolen

Jag grupperar ihop relaterade Ingångar tid, sätter en kort TTL innan jag gör större förändringar och sedan publicerar allt på en gång. Innan jag sparar kontrollerar jag igen MX-prioriteringar, SPF-syntax och mål-IP för A-posten. För serveradministration och processer finns de kompakta instruktionerna på Hetzner Robot tips. Efter driftsättningar testar jag http, https och mail med riktiga förfrågningar, inte bara via ping. På så sätt kan jag upptäcka fel som rena DNS-frågor inte visar.

Automation: API, mallar och ACME

Jag sparar tid genom automatisering. För regelbundna driftsättningar använder jag API av DNS-konsolen för att skapa, ändra eller ta bort poster. Jag arbetar med mallar för återkommande mönster (t.ex. Web + Mail + DMARC) och infogar endast projektspecifika värden. För Let's Encrypt DNS-01 inkluderar jag en automatiserad TXT-postskrivare och integrerar den i arbetsflödet för förnyelse. Viktigt: Jag behandlar API-tokens som lösenord, tilldelar dem till specifika projekt och återkallar åtkomsten när de inte längre behövs.

Avancerade inställningar: Split-Horizon, CDN och ACME

Jag separerar interna och externa användare om så krävs DNS-vyer så att den interna appen pekar på privata IP-adresser och besökare på offentliga destinationer. Ska jag använda en CDNJag hänvisar subdomäner till CDN-namnet via CNAME och aktiverar TLS där. För automatiska certifikat via ACME/Let's Encrypt ställer jag valfritt in DNS-01 utmaningar via TXT om HTTP-01 inte matchar. Automatisering är viktigt här så att förnyelser utförs i god tid. Loggar och notifieringar hjälper till att upptäcka fel i god tid.

Prestanda- och tillgänglighetsmönster

Jag ökar tillgängligheten med enkla medel: Flera A/AAAA-poster (round robin) delar belastning utan ytterligare tjänster, förutsatt att backend är stateless eller delar sessioner. Vid underhåll tar jag tillfälligt bort enskilda IP-adresser och höjer sedan posten igen. En TTL-körning som är för kort kan belasta resolvers; jag hittar en balans mellan svarshastighet och cache-träfffrekvens. Jag sätter upp tydliga processer för failovers utan hälsokontroller: I händelse av fel byter jag poster, övervakar dem aktivt och återställer dem igen efter återhämtning.

Säkerhet och zonhygien

Jag avaktiverar onödiga Överföring av zoner (AXFR) och publicerar endast de NSsom verkligen är auktoritativa. Jag tar regelbundet bort gamla eller föräldralösa underdomäner så att inga skuggytor skapas. För IDN:er kontrollerar jag Punycode-stavning för att undvika skrivfel och fel med specialtecken. Rollbaserad åtkomst i konsolen säkerställer att endast rätt personer ändrar zoner. Och helt pragmatiskt: Jag dokumenterar kortfattat ändringar i teamverktyget - detta minskar avsevärt antalet frågor under drift.

Strategi för migrering och rollback

Innan en flytt sänker jag TTL (24-48 timmar i förväg), speglar alla Rekord till den nya zonen och testa upplösningen direkt via de nya namnservrarna. Först när allt är korrekt ställer jag in Namngivare hos registrator. Efter delegeringen övervakar jag trafik och fel. Om något går fel rullar jag tillbaka på ett kontrollerat sätt eller korrigerar enskilda poster. Jag planerar DNSSEC-migreringar särskilt konservativt och lämnar den gamla signaturkedjan på plats tills den nya är säkert på plats. Slutligen återställer jag TTL till produktionskompatibla värden.

Kortfattad jämförelse av leverantörer med avseende på prestanda och flexibilitet

Prestanda, funktioner och DNS frihet bestämma hur flexibelt jag rullar ut projekt. I praktiken levererar de stora värdarna solida Svarstidermen skiljer sig åt när det gäller drift, funktioner och support. Jag bedömer urvalet utifrån prestanda, funktionsomfång, hjälpkvalitet och DNS-alternativ. Följande översikt visar en komprimerad bild som jag kan använda för att fatta beslut. I slutändan är det vad mitt projekt verkligen behöver som räknas, inte den största funktionslistan.

Leverantör	Prestanda	Funktionernas omfattning	Stöd	DNS-flexibilitet	Ranking
webhoster.de	Hög	Mycket omfattande	Topp	Maximalt	1
Hetzner	Hög	Omfattande	Bra	Hög	2
Contabo	Medium	Standard	O. K.	Medium	3

Kortfattat sammanfattat

Jag satte en Hetzner DNS-zon på ett strukturerat sätt: Skapa zon, ange namnserver hos registrator, ange core records för webb och e-post, testa sedan. Med lämplig TTL Jag förkortar omställningstiderna och ökar dem igen efter avslut för mindre belastning. SPF, DKIM och DMARC stärker leveransen och skyddar domänen mot missbruk. Jag håller subdomäner konsekventa och separerar interna från offentliga destinationer. Med den här exempelkonfigurationen och de dagliga kontrollerna förblir din hetzner dns-konfiguration tillförlitlig, snabb och enkel att underhålla.