Hetzner DNS seadete õige seadistamine - näide konfiguratsioon hetzner dns konfiguratsiooniga

Hetzner DNS konfiguratsioon nii, et veebisait, alamdomeenid ja e-post toimiksid ümbersõitudeta ja muudatused jõustuksid kiiresti. Selles juhendis näitan teile Hetzneri DNS-i vajalikke seadeid, proovitud näidiskonfiguratsiooni ja praktilisi testimismeetodeid, et saaksite varakult vältida vigu ja hoida oma tsooni puhtana.

Kesksed punktid

Järgnevad põhipunktid annavad kiire ülevaate sellest, mis on usaldusväärse DNS-tsooni jaoks oluline.

• Nimeserver sisestage registripidaja juures õigesti
• A/AAAA veebi jaoks, MX/TXT posti jaoks
• TTL Valige asjakohaselt ja oodake paljundamist
• SPF/DKIM rämpsposti ja võltsimise vastu
• Järelevalve ja testid pärast muudatusi

DNS lühidalt: mida te tegelikult vajate

Ma määran domeeni kaudu Rekordid konkreetsed sihtkohad, nii et brauserid ja e-posti serverid leiavad minu teenused üles. A A-rekord viitab IPv4-aadressile, AAAA IPv6-le ja MX määratleb e-kirjade kättetoimetamise. CNAME moodustab aliase, mis osutab teisele nimele, TXT aga sisaldab teavet, et SPF või kontrollimine. Puhas baastase koosneb A/AAAA põhidomeeni jaoks, CNAME www jaoks, MX posti jaoks ja SPF-TXT. Nii hoian tsooni selge, kiiresti hooldatavana ja avatud hilisematele laiendustele.

Domeeni lisamine Hetzneri DNS-konsoolile

DNS-konsoolis loon kõigepealt uue Tsoon ja kontrollige, et domeeni õigekiri oleks täpselt õige. Seejärel aktiveerin käsitsi hoolduse Rekordidet saaksin luua ja muuta konkreetseid kirjeid. Vihje: ma panen IP-aadressid ja posti sihtkohad eelnevalt kirja, et saaksin kõik katkestusteta sisestada. Nii väldin trükivigu ja panen kirjed rahulikult korda. Niipea kui tsoon on valmis, kavandan nimeserverite muutmise ja sellele järgneva kontrolli.

Sisestage nimeserver õigesti registripidaja juures

Pärast tsooni loomist sisestan ma Nimeserver Hetznerilt, nii et haldamine on tsentraliseeritud DNS-konsoolis. Tavalised kanded on järgmised ns1.first-ns.de, robotns2.second-ns.de ja robotns3.second-ns.com. .de või .at domeenide jaoks sean ma oma nimeserverid üles koos Liimi-plaadidet viited ja IP-d oleksid salvestatud. Kui te ei ole seda varem teinud, leiate üksikud sammud juhisest aadressil Seadistage liimikirjed. Seejärel võtan üleminekuks aega, sest uuendused võivad kogu maailmas saabuda erineva kiirusega.

Näidiskonfiguratsioon: Veebisaidi ja e-kirja käivitatavaks tegemine

Tüüpiliseks veebipresentatsiooniks kasutan ma A-rekord juurdomeeni jaoks, CNAME www jaoks ja sobivad kirjed posti jaoks. SPF-TXT takistab väliste serverite e-posti saatmist domeeni nimel. Valikuliselt lisan ma AAAA kirje, kui veebiserver IPv6 pakub. Väliste postiteenuste, näiteks ForwardMX, puhul kohandan MX-i ja salvestan nende spetsifikatsioonid. Järgnev tabel näitab kindlat lähtepunkti paljude seadistuste jaoks.

Nimi	Tüüp	Väärtus	Vihje
@	A	195.201.210.43	Veebiserver IPv4
@	AAAA	Vabatahtlik: 2a01:4f8:xxxx:xxxx::1	Veebiserver IPv6
www	CNAME	@	Alias root'ile
@	MX	mx1.forwardmx.net	Prio 10
@	TXT	"v=spf1 include:_spf.forwardmx.net -all"	SPF võltsimise vastu

Aktiveerige DNSSEC ja määrake DS-rekord

Kui manipuleerimise turvalisus on minu jaoks oluline, aktiveerin ma DNSSEC tsooni jaoks. Hetzneri konsoolis genereerin selleks allkirjastamisvõtmed ja seejärel saan vajalikud DS andmedmida ma hoiustan registripidaja juures. Ma kontrollin, et algoritm ja digesti on õigesti üle kantud. Seejärel ootan, kuni ahel registripidaja ja tsooni vahel valideerub nõuetekohaselt. Enne suuremaid võtmete pöördeid alandan TTL-i ja planeerin ajaakna, et lahendajad näeksid uusi allkirju õigeaegselt. Tähtis: kui muudatuse ajal tekib viga, ei õnnestu valideerimine vastuvõtjate jaoks - seepärast olen valmis tagasivõtmise (ärge kustutage vanu võtmeid liiga vara) ja testin valideerimisresolvijatega.

Seadistage TTL õigesti ja mõistke levikut

Die TTL määrab, kui kaua resolverid kirjet vahemällu salvestavad. Konverteerimiste puhul valin lühikese TTL (nt 300 sekundit), et muutused muutuksid kiiresti nähtavaks. Pärast lõplikku seadistamist suurendan väärtusi uuesti, et säästa taotlusi ja saavutada ühtlane resolutsioon. Need, kes võtavad sageli kasutusele, soovivad jääda 600-1200 sekundi juurde, samas kui need, kes teevad muudatusi harva, kasutavad 3600-14400. Praktilise ülevaate otsusest annab minu pilk Optimaalne TTL valik.

Apex domeen, CAA ja sertifikaadid kontrolli all

SaaSi eesmärkide puhul on Zone Apex Ma mäletan, et CNAME ei ole lubatud @. Seetõttu kasutan ma teenusepakkuja A/AAAA-d või sean veebiserveri tasandil ümbersuunamise www-le. Sertifikaadi määramiseks kontrollin ma koos CAA Recordsmillised sertifitseerimisasutused on volitatud sertifikaate väljastama. Näiteks ma säilitan ainult seda CA-d, mida ma tegelikult kasutan, ja lisan valikuliselt aruannete jaoks e-posti aadressi. Kui ma vahetan CA-d, suurendan ma lühidalt TTL-i ja uuendan CAA-d enne väljaandmist. ACME DNS-01 kaudu kasutatavatele wildcards'ile veendun, et TXT-kirjed on all _acme-challenge saab kiiresti määrata ja automaatselt puhastada, nii et vanu väljakutseid ei jääks maha.

Alamdomeenide ja teenuste puhas loomine

Iga alamdomeeni jaoks loen ma sobiva A- või CNAME-record, sõltuvalt sellest, kas alamdomeen osutab otse IP-le või nimele. Näide: blog.example.de kui A-kirje blogi VM-le, cdn.example.de kui CNAME CDN-nimele. APIde puhul teen riskide vältimiseks rangelt vahet sisemiste ja avalike nimede vahel. Standardiseeritud nimed, nagu api, app, img, aitavad hooldust ja järelevalvet hõlbustada. Nii hoian tsooni struktureerituna ja saan muudatusi selgelt määrata.

Metsikud kaardid, SRV ja spetsiaalsed kirjete tüübid

Ma kasutan Wildcard Records (*.example.de), näiteks mitme kliendi jaoks. Veendun, et täpsed kirjed on alati eelisjärjekorras metsikutest. Selliste teenuste puhul nagu SIP, Matrix või Autodiscover, loen ma SRV-Rekordid ja kontrollige vormingut ja prioriteete. TXT kirjed pika sisuga (nt 2048-bitine DKIM) jagatakse mitmeks tsitaadisegmendiks, et parsereid saaks neid õigesti ühendada. Ma väldin mitut SPF-kirjet ja ühendan kirjed kehtivaks SPF-iks, et mitte rikkuda otsingupiirangut.

Usaldusväärne e-posti kättetoimetamine: SPF, DKIM ja DMARC

Usaldusväärse e-kirja jaoks kasutan ma MX puhas SPF-TXT, mis katab minu saatmissüsteemid. Ma aktiveerin ka DKIM kasutatavas postiteenuses ja avaldage DKIM-selektor TXT-formaadis selector._domainkey all. Ma kasutan DMARCi, et määrata, kuidas vastuvõtjad käitlevad kirju, mis ei läbinud SPF/DKIMi. Alustan sageli "p=none", hindan aruandeid ja lülitan hiljem ümber "karantiini" või "reject" peale. Selline järjestus vähendab riske ja suurendab järk-järgult kohaletoimetamise kvaliteeti.

SPF/DKIM/DMARC süvendamine praktikas

Hoian SPF-i võimalikult lahja: ainult vajalik. lisada-mehhanismid ja mitte kunagi rohkem kui üks SPF per hostinimi. Et järgida 10 DNS-otsingu piirangut, vähendan ahelaid või kasutan IP4/IP6-mehhanisme, kui need on stabiilsed. Sest DKIM rotatsioon Ma kasutan kahte aktiivset selektorit (vana/uus), avaldan uue võtme, vahetan postiteenust ja kustutan vana alles mõne päeva pärast. Koos DMARC Esialgu määrasin aruandlusaadressid (rua/ruf) ja kontrollin joondamist (aspf/adkim). Alamdomeenide puhul saan kasutada sp= määratleda eraldi poliitika, kui nad saadavad eraldi. Nii reageerin ma eelduste asemel tegelikele liiklusandmetele.

Reverse DNS (PTR) puhta posti kättetoimetamiseks

Lisaks MX, SPF ja DKIM seadistasin lisaks MX, SPF ja DKIM ka Pööratud DNS (PTR) väljaminevate postiserverite jaoks. IP PTR viitab hostinimele, mis omakorda laheneb korrektselt samale IP-le A/AAAA kaudu (Edasi/tagasi vaste). PTR-i määran IP-i kohta otse IP-i omaniku juures (nt serveriliideses) - mitte domeeni tsoonihalduses. IPv6 puhul kasutan nibble formaati. Sobiv PTR vähendab rämpsposti klassifitseerimist ja aitab mainet. Kui post jookseb välise teenuse kaudu, jätan selle PTR-i selliseks, nagu see on, ja väldin segatud saatjaallikaid ilma SPF-i kohandamiseta.

Tüüpilised vead ja kiirlahendused

Kui domeen ei lahene, siis ma kontrollin kõigepealt järgmist TTLnimeserveri kirjed ja kirjete õige kirjapilt. Teine pilk läheb LevimineMõned resolverid vahemällu salvestavad pikemalt, eriti pärast TTL-i suurendamist. Ma võrdlen resolutsiooni, kasutades erinevaid DNS-kontrollijaid, et tuvastada piirkondlikke erinevusi. Kohalike probleemide korral lülitan ajutiselt üle avalikele lahendajatele, näiteks 1.1.1.1.1 või 8.8.8.8.8. Kui viga esineb ainult sisevõrkudes, kontrollin sisemisi resolvereid ja reegleid konteinerites, Kubernetes'is või CoreDNS-i konfiguratsioonides.

Testimismeetodid: dig, nslookup ja otsast-otsast-otsani

Ma ei testi mitte ainult kirjeid, vaid kogu teed:

• dig A/AAAA/CNAME/MX/TXT: Vastuste, TTL ja volituste kontrollimine.
• dig +traceVt delegatsiooniahelat ja nimeserveri käitumist
• SMTP testidKontrollida HELO/EHLO, TLS ja bännerit.
• HTTPS reaalneSertifikaadi kett, hostinimi, ümbersuunamised

Sel viisil tunnen ära ka vead, mis ei ole puhtalt DNS-vastustes nähtavad, näiteks ebaõiged VirtualHost'i kaardistused või aeguvad sertifikaadid. Pärast muudatuste tegemist ootan vähemalt ühe TTLi, enne kui teen lõplikke järeldusi.

Tõhus töö Hetzneri konsooliga

Rühmitan omavahel seotud Kirjed aega, seadke lühike TTL enne suuremate muudatuste tegemist ja avaldage kõik korraga. Enne salvestamist kontrollin uuesti MX-prioriteedid, SPF-süntaks ja A-kirje siht-IP. Serveri haldamiseks ja protsesside jaoks on kompaktsed juhised aadressil Hetzneri roboti näpunäited. Pärast kasutuselevõttu testin http, https ja posti tõeliste päringutega, mitte ainult pingi kaudu. See võimaldab mul tuvastada vigu, mida puhtad DNS päringud ei näita.

Automatiseerimine: API, mallid ja ACME

Ma säästan aega automatiseerimise kaudu. Regulaarseks kasutuselevõtuks kasutan ma API DNS-konsoolist kirjete loomiseks, muutmiseks või kustutamiseks. Töötan korduvate mustrite (nt Web + Mail + DMARC) mallidega ja sisestan ainult projektispetsiifilisi väärtusi. Let's Encrypt DNS-01 puhul lisan automaatse TXT-kirjete kirjutaja ja integreerin selle uuendamise töövoogu. Oluline: ma käsitlen API-tokeneid nagu paroole, määran need konkreetsetele projektidele ja tühistan juurdepääsu, kui neid enam ei vajata.

Täiustatud seadistused: Split-Horizon, CDN ja ACME

Vajaduse korral eraldan sise- ja väliskasutajad DNS-vaateid nii, et siserakendus viitab privaatsetele IP-dele ja külastajad avalikele sihtkohtadele. Kas ma kasutan CDNMa viitan alamdomeenidele CDN-i nimele CNAME kaudu ja aktiveerin seal TLS-i. ACME/Let's Encrypt'i kaudu automaatsete sertifikaatide jaoks määran ma valikuliselt DNS-01 väljakutsed TXT kaudu, kui HTTP-01 ei vasta. Automatiseerimine on siinkohal oluline, et uuendused toimuksid õigeaegselt. Logid ja teavitused aitavad tõrkeid õigeaegselt ära tunda.

Tulemuslikkuse ja kättesaadavuse mustrid

Ma suurendan kättesaadavust lihtsate vahenditega: Mitmed A/AAAA kirjed (round robin) jagavad koormust ilma lisateenusteta, tingimusel, et backendid on olekuta või jagavad seansse. Hoolduse ajal eemaldan ma ajutiselt üksikud IP-d ja tõstan seejärel sissekande uuesti. Liiga lühike TTL võib koormata resolvereid; ma leian tasakaalu reageerimiskiiruse ja vahemälu tabavuse vahel. Määran tühjad protsessid ümberlülitamiseks ilma tervisekontrollideta: Rikke korral vahetan kirjed, jälgin neid aktiivselt ja nullistan need pärast taastumist uuesti.

Ohutus ja tsoonihügieen

Ma deaktiveerin mittevajalikud Tsooni ülekanded (AXFR) ja avaldada ainult NSmis on tõeliselt autoriteetsed. Ma kustutan regulaarselt vanu või orvuks jäänud alamdomeene, et ei tekiks varjupindu. IDNide puhul kontrollin ma Punycode-kirjutus, et vältida kirjavigu ja erimärgivigu. Rolupõhine juurdepääs konsoolis tagab, et ainult õiged inimesed muudavad tsoone. Ja üsna pragmaatiliselt: ma dokumenteerin muudatused lühidalt meeskonnavahendis - see vähendab oluliselt päringuid töö käigus.

Migratsiooni- ja tagasivõtustrateegia

Enne kolimist alandan TTL-i (24-48 tundi enne), peegelda kõiki Rekordid uude tsooni ja testida resolutsiooni otse uute nimeserverite kaudu. Alles siis, kui kõik on õige, määran ma Nimeserver registripidaja juures. Pärast delegeerimist jälgin liiklust ja vigu. Kui midagi läheb valesti, võtan kontrollitud viisil tagasi või parandan üksikuid kirjeid. DNSSECi migratsiooni kavandan ma eriti konservatiivselt ja jätan vana allkirjaahela paika, kuni uus on turvaliselt paigas. Lõpuks nullistan TTL-i tootmisele vastavate väärtuste juurde.

Lühivõrdlus teenusepakkujate tulemuslikkuse ja paindlikkuse kohta

Tulemuslikkus, funktsioonid ja DNS-vabadus otsustada, kui paindlikult ma projekte ellu viin. Praktikas pakuvad suured hosterid kindlaid Reageerimisaegkuid erinevad töö, funktsioonide ja toetuse poolest. Hindan valikut vastavalt jõudlusele, funktsioonide valikule, abi kvaliteedile ja DNS-valikutele. Järgnev ülevaade näitab kokkuvõtlikku pilti, mida saan kasutada otsuste tegemisel. Lõpuks loeb see, mida minu projekt tegelikult vajab, mitte suurim funktsioonide nimekiri.

Teenusepakkuja	Tulemuslikkus	Funktsioonide ulatus	Toetus	DNS paindlikkus	Edetabel
webhoster.de	Kõrge	Väga ulatuslik	Top	Maksimaalne	1
Hetzner	Kõrge	Ulatuslik	Hea	Kõrge	2
Contabo	Keskmine	Standard	O. K.	Keskmine	3

Lühikokkuvõte

Ma seadsin Hetzner DNS-tsooni struktureeritud viisil: Looge tsoon, sisestage nimeserver registripidaja juures, määrake veebi ja posti põhikirjed, seejärel testige. Sobiva TTL Ma lühendan üleminekuaegu ja suurendan neid uuesti pärast lõpetamist, et vähendada koormust. SPF, DKIM ja DMARC tugevdavad kohaletoimetamist ja kaitsevad domeeni väärkasutuse eest. Hoian alamdomeenid järjepidevalt ja eraldan sisemised sihtkohad avalikest sihtkohtadest. Selle näidiskonfiguratsiooni ja igapäevaste kontrollide abil jääb teie hetzneri dns-konfiguratsioon usaldusväärseks, kiireks ja kergesti hooldatavaks.