Hetzner DNS konfigurācija lai tīmekļa vietne, apakšdomēni un pasts darbotos bez aizķeršanās un izmaiņas stātos spēkā ātri. Šajā rokasgrāmatā es parādīšu nepieciešamos iestatījumus Hetzner DNS, izmēģinātu konfigurācijas piemēru un praktiskas testēšanas metodes, lai jūs jau sākumā varētu izvairīties no kļūdām un saglabāt savu zonu tīru.
Centrālie punkti
Tālāk sniegts īss pārskats par to, kas ir svarīgi, lai nodrošinātu uzticamu DNS zonu.
- Nosaukumu serveris pareizi ievadiet reģistratūrā
- A/AAAA tīmekļa vietnei, MX/TXT pastam
- TTL Atbilstoši izvēlieties un gaidiet, kad tiks izplatīts
- SPF/DKIM pret surogātpasta un spoofing
- Uzraudzība un testus pēc izmaiņām
DNS īsumā: kas jums patiešām ir nepieciešams
Es piešķiru domēnu, izmantojot Ieraksti īpašus galamērķus, lai pārlūkprogrammas un pasta serveri varētu atrast manus pakalpojumus. A A-Record norāda uz IPv4 adresi, AAAA norāda uz IPv6 adresi, bet MX nosaka e-pasta vēstuļu piegādi. CNAME veido aizstājvārdu, kas norāda uz citu nosaukumu, savukārt TXT satur informāciju par SPF vai verifikācijas. Tīrs bāzes scenārijs sastāv no A/AAAA galvenajam domēnam, CNAME www, MX pastam un SPF-TXT. Šādā veidā es saglabāju zonu skaidru, ātri kopjamu un atvērtu vēlākajiem paplašinājumiem.
Domēna pievienošana Hetzner DNS konsolei
DNS konsolē vispirms izveidoju jaunu Zona un pārbaudiet, vai domēna rakstība ir precīzi pareiza. Pēc tam es aktivizēju manuālo uzturēšanu Ierakstilai es varētu izveidot un mainīt konkrētus ierakstus. Padoms: es iepriekš pierakstu IP adreses un pasta galamērķus, lai visu varētu ievadīt bez pārtraukuma. Šādā veidā es izvairos no pārrakstīšanās kļūdām un ierakstus sakārtoju mierīgā secībā. Tiklīdz zona ir gatava, es plānoju nosaukumu serveru maiņu un tai sekojošās pārbaudes.
Pareizi ievadiet vārda serveri ar reģistratoru
Pēc zonas izveides es ievada Nosaukumu serveris no Hetzner, lai administrēšana būtu centralizēta DNS konsoles vietnē. Parastie ieraksti ir šādi ns1.first-ns.de, robotns2.second-ns.de un robotns3.second-ns.com. Domēniem .de vai .at es izveidoju savus nosaukumu serverus, izmantojot. Līme-Recordslai tiktu saglabātas atsauces un IP. Ja iepriekš to nekad neesat darījis, varat atrast atsevišķus soļus rokasgrāmatā, lai Līmes ierakstu iestatīšana. Pēc tam man ir nepieciešams laiks, lai veiktu pāreju, jo atjauninājumi visā pasaulē var tikt saņemti dažādos ātrumos.
Konfigurācijas piemērs: izpildāmas vietnes un e-pasta izveide
Tipiskai tīmekļa vietnei es izmantoju A-Record saknes domēnam, CNAME domēnam www un piemērotus pasta ierakstus. SPF-TXT neļauj ārējiem serveriem sūtīt e-pasta vēstules domēna vārdā. Pēc izvēles es pievienoju AAAA ierakstu, ja tīmekļa serveris IPv6 nodrošina. Ārējiem pasta pakalpojumiem, piemēram, ForwardMX, es pielāgoju MX un saglabāju to specifikācijas. Turpmāk sniegtajā tabulā ir parādīts stabils sākumpunkts daudzām konfigurācijām.
| Nosaukums | Tips | Vērtība | Piezīme |
|---|---|---|---|
| @ | A | 195.201.210.43 | Web servera IPv4 |
| @ | AAAA | Pēc izvēles: 2a01:4f8:xxxx:xxxx::1 | Web servera IPv6 |
| www | CNAME | @ | Alias uz saknes |
| @ | MX | mx1.forwardmx.net | Prio 10 |
| @ | TXT | "v=spf1 include:_spf.forwardmx.net -all" | SPF pret spoofing |
DNSSEC aktivizēšana un DS ieraksta iestatīšana
Ja man ir svarīga manipulāciju drošība, es aktivizēju DNSSEC zonai. Hetzner konsolē es ģenerēju paraksta atslēgas un pēc tam saņemu nepieciešamos dokumentus. DS datiko es iemaksāšu reģistratūrā. Es pārbaudu, vai algoritms un digest ir pārnests pareizi. Pēc tam es gaidu, kamēr ķēdes no reģistratora uz zonu apstiprinās pareizi. Pirms lielākām atslēgu rotācijām es samazinu TTL un plānoju laika logu, lai resolveri laikus redzētu jaunos parakstus. Svarīgi: ja izmaiņu laikā rodas kļūda, saņēmējiem validācija neizdodas - tāpēc man ir sagatavota atgriešanās (neizdzēst vecās atslēgas pārāk agri) un veicu pārbaudi ar validācijas resolveriem.
Pareizi iestatiet TTL un izprotiet pavairošanu
Portāls TTL nosaka, cik ilgi resolveri saglabā ierakstu kešatmiņā. Konversijām es izvēlos īsu TTL (piemēram, 300 sekundes), lai izmaiņas būtu redzamas ātri. Pēc galīgās iestatīšanas es atkal palielinu vērtības, lai ietaupītu pieprasījumus un panāktu konsekventu izšķirtspēju. Tiem, kas bieži ievieto, patīk pieturēties pie 600-1200 sekundēm, bet tie, kas reti veic izmaiņas, izmanto 3600-14400. Praktisku pārskatu par lēmumu sniedz mans skatījums uz Optimāla TTL izvēle.
Apex domēna, CAA un sertifikātu kontrole
SaaS mērķiem par Zone Apex Es atceros, ka CNAME nav atļauts @. Tāpēc es izmantoju pakalpojumu sniedzēja A/AAAA vai tīmekļa servera līmenī iestatīju novirzīšanu uz www. Sertifikāta piešķiršanu es kontrolēju ar CAA ierakstikuras CA ir pilnvarotas izsniegt sertifikātus. Piemēram, es uzturu tikai to CA, kuru faktiski izmantoju, un pēc izvēles pievienoju pasta adresi ziņojumiem. Ja mainu CA, pirms sertifikātu izsniegšanas uz īsu brīdi palielinu TTL un atjauninu CAA. Attiecībā uz aizstājējzīmēm, izmantojot ACME DNS-01, es pārliecinos, ka TXT ieraksti zem _acme-challenge var ātri iestatīt un automātiski notīrīt, lai nepaliek vecie izaicinājumi.
Tīra apakšdomēnu un pakalpojumu izveide
Katrai apakšdomēnai izveidoju piemērotu A- vai CNAME-ieraksts atkarībā no tā, vai apakšdomēna norāda tieši uz IP vai vārdu. Piemērs: blog.example.de kā A-record uz bloga VM, cdn.example.de kā CNAME uz CDN nosaukumu. Lai izvairītos no riskiem, API es stingri nošķiru iekšējos un publiskos nosaukumus. Standartizēti nosaukumi, piemēram, api, app, img, atvieglo uzturēšanu un uzraudzību. Šādā veidā es saglabāju zonas struktūru un varu skaidri piešķirt izmaiņas.
aizstājējzīmes, SRV un īpašie ierakstu veidi
Es izmantoju Wildcard Records (*.example.de), piemēram, konfigurācijām ar vairākiem klientiem. Es pārliecinos, ka precīziem ierakstiem vienmēr ir priekšroka pār aizstājējzīmēm. Tādiem pakalpojumiem kā SIP, Matrix vai Autodiscover es izveidoju SRV-Records un pārbaudiet formātu un prioritātes. TXT ieraksti ar garu saturu (piemēram, 2048 bitu DKIM) tiek sadalīti vairākos citātu segmentos, lai analizatori varētu tos pareizi apvienot. Es izvairos no vairākiem SPF ierakstiem un apvienoju ierakstus derīgā SPF, lai nepārkāptu meklēšanas ierobežojumu.
Uzticama e-pasta piegāde: SPF, DKIM un DMARC
Uzticamam e-pastam es izmantoju MX tīru SPF-TXT, kas aptver manas nosūtīšanas sistēmas. Es arī aktivizēju DKIM izmantotajā pasta pakalpojumā un publicējiet DKIM selektoru kā TXT zem selector._domainkey. Es izmantoju DMARC, lai noteiktu, kā saņēmēji rīkojas ar e-pastiem, kas neiztur SPF/DKIM pārbaudi. Es bieži sāku ar "p=none", izvērtēju ziņojumus un vēlāk pārslēdzos uz "karantīnā" vai "noraidīt". Šāda secība samazina riskus un pakāpeniski palielina piegādes kvalitāti.
SPF/DKIM/DMARC padziļināšana praksē
SPF es izmantoju pēc iespējas mazāk: tikai nepieciešamos iekļaut-mehānismi un nekad vairāk par vienu SPF uz vienu hostname. Lai ievērotu 10 DNS meklējumu ierobežojumu, es samazinu ķēdes vai izmantoju IP4/IP6 mehānismus, ja tie ir stabili. Attiecībā uz DKIM rotācija Es darbinu divus aktīvos selektorus (veco/jaunu), publicēju jauno atslēgu, pārslēdzu pasta pakalpojumu un tikai pēc dažām dienām dzēšu veco. Ar DMARC Sākotnēji iestatīju ziņošanas adreses (rua/ruf) un pārbaudīju izlīdzināšanu (aspf/adkim). Apakšdomēniem varu izmantot sp= definēt atsevišķu politiku, ja tie tiek nosūtīti atsevišķi. Šādā veidā es reaģēju uz reāliem datplūsmas datiem, nevis pieņēmumiem.
Reversais DNS (PTR) tīrai pasta piegādei
Papildus MX, SPF un DKIM es iestatīju arī Reversais DNS (PTR) izejošā pasta serveriem. IP PTR norāda uz resursvietas nosaukumu, kas, savukārt, pareizi atrisina to pašu IP, izmantojot A/AAAA (Atpakaļgaitas/priekšēja saskaņošana). PTR katram IP es iestatīju tieši IP īpašniekam (piemēram, servera saskarnē) - nevis domēna zonas pārvaldībā. IPv6 es izmantoju nibble formātu. Piemērots PTR samazina surogātpasta klasifikāciju un palīdz uzlabot reputāciju. Ja pasts tiek sūtīts, izmantojot ārējo pakalpojumu, es atstāju tā PTR tādu, kāds tas ir, un izvairos no jauktiem sūtītāja avotiem bez SPF pielāgošanas.
Tipiskas kļūdas un ātri risinājumi
Ja domēns netiek atrisināts, vispirms pārbaudu. TTLvārdu servera ieraksti un pareiza ierakstu rakstība. Otrais skatījums tiek vērsts uz PavairošanaDaži resolveri kešatmiņā atrodas ilgāk, īpaši pēc TTL palielināšanas. Lai atpazītu reģionālās atšķirības, es salīdzinu izšķirtspēju, izmantojot dažādus DNS kontrolierus. Vietējo problēmu gadījumā uz laiku pārslēdzos uz publiskiem resolveriem, piemēram, 1.1.1.1.1 vai 8.8.8.8.8. Ja kļūda rodas tikai iekšējos tīklos, pārbaudu iekšējos resolverus un noteikumus konteineru, Kubernetes vai CoreDNS konfigurācijās.
Testēšanas metodes: dig, nslookup un end-to-end.
Es testēju ne tikai ierakstus, bet visu ceļu:
- dig A/AAAA/CNAME/MX/TXT: pārbauda atbildes, TTL un autoritāti.
- dig + izsekošanaSkatīt deleģēšanas ķēdi un vārda servera darbību
- SMTP testiHELO/EHLO, TLS un bannera pārbaude
- HTTPS realSertifikātu ķēde, uzņēmēja nosaukums, novirzīšana
Šādā veidā es varu atpazīt arī kļūdas, kas nav redzamas tīrajās DNS atbildēs, piemēram, nepareizus VirtualHost kartējumus vai sertifikātus, kuru derīguma termiņš beidzas. Pēc izmaiņu veikšanas pirms galīgo secinājumu izdarīšanas nogaidu vismaz vienu TTL.
Efektīvs darbs ar Hetzner konsoli
Es grupēju saistītos Ieraksti laiku, iestatiet īsu TTL termiņu pirms būtisku izmaiņu veikšanas un pēc tam publicējiet visu vienā piegājienā. Pirms saglabāšanas es vēlreiz pārbaudu MX-prioritātes, SPF sintakse un A ieraksta mērķa IP. Servera administrēšanai un procesiem izmantojiet kompaktās instrukcijas, kas atrodamas vietnē Hetzner Robot padomi. Pēc izvietošanas, Es testēt http, https un pastu ar reāliem pieprasījumiem, ne tikai ar ping. Tas ļauj man atpazīt kļūdas, ko tīri DNS pieprasījumi neuzrāda.
Automatizācija: API, veidnes un ACME
Es ietaupu laiku, izmantojot automatizāciju. Regulārai izvietošanai es izmantoju API DNS konsole, lai izveidotu, mainītu vai dzēstu ierakstus. Es strādāju ar šabloniem atkārtotiem modeļiem (piemēram, Web + Mail + DMARC) un ievietoju tikai projektam specifiskas vērtības. Lietotnē Let's Encrypt DNS-01 es iekļauju automatizētu TXT ierakstu rakstītāju un integrēju to atjaunošanas darbplūsmā. Svarīgi: API žetonus es izmantoju tāpat kā paroles, piešķiru tos konkrētiem projektiem un atsaucu piekļuvi, kad tie vairs nav vajadzīgi.
Uzlabotas konfigurācijas: Split-Horizon, CDN un ACME
Ja nepieciešams, nodalu iekšējos un ārējos lietotājus. DNS-apskati, lai iekšējā lietotne norādītu uz privātiem IP, bet apmeklētāji - uz publiskiem galamērķiem. Vai es varu izmantot CDNEs atsaucos uz apakšdomēniem CDN nosaukumā, izmantojot CNAME, un aktivizēju TLS tur. Automātiskiem sertifikātiem, izmantojot ACME/Let's Encrypt, es pēc izvēles iestatu DNS-01 izaicinājumus, izmantojot TXT, ja HTTP-01 neatbilst. Automatizācija ir svarīga, lai atjaunināšana tiktu veikta savlaicīgi. Žurnāli un paziņojumi palīdz savlaicīgi atpazīt kļūdas.
Veiktspējas un pieejamības modeļi
Es palielinu pieejamību ar vienkāršiem līdzekļiem: Vairāki A/AAAA ieraksti (apļveida) sadalīt slodzi bez papildu pakalpojumiem, ja backends ir bezstāvokļa vai koplieto sesijas. Uzturēšanas laikā es uz laiku noņemu atsevišķus IP un pēc tam atkal paaugstinu ierakstu. Pārāk īss TTL var radīt slodzi resolveriem; es atrodu līdzsvaru starp atbildes ātrumu un kešatmiņas trāpījumu skaitu. Es nosaku skaidrus procesus avārijas atjaunošanai bez veselības pārbaudēm: Ja notiek kļūme, es nomainu ierakstus, aktīvi tos uzraugu un pēc atveseļošanās tos atkal atiestatu.
Drošība un zonas higiēna
Es deaktivizēju nevajadzīgu Zonu pārcelšana (AXFR) un publicē tikai NSkas ir patiesi autoritatīvi. Es regulāri dzēšu vecās vai pamestās apakšdomēnas, lai netiktu radītas ēnu virsmas. Attiecībā uz IDN es pārbaudu Pinycode-rakstību, lai izvairītos no pārrakstīšanās un speciālo rakstzīmju kļūdām. Uz lomām balstīta piekļuve konsolei nodrošina, ka zonas maina tikai pareizie cilvēki. Un pavisam pragmatiski: es īsi dokumentēju izmaiņas komandas rīkā - tas ievērojami samazina vaicājumu skaitu darbības laikā.
Migrācijas un atiestatīšanas stratēģija
Pirms pārvietošanas es pazeminu TTL (24-48 stundas iepriekš), atspoguļoju visus Ieraksti jaunajā zonā un pārbaudiet izšķirtspēju tieši, izmantojot jaunos vārda serverus. Tikai tad, kad viss ir pareizi, es iestatu Nosaukumu serveris pie reģistratora. Pēc deleģēšanas es pārraugu datplūsmu un kļūdas. Ja kaut kas nav kārtībā, es kontrolēti atgriežos atpakaļ vai laboju atsevišķus ierakstus. DNSSEC migrāciju plānoju īpaši konservatīvi un atstāju veco paraksta ķēdi, līdz jaunā ir droši ieviesta. Visbeidzot, es atjaunoju TTL līdz ražošanas prasībām atbilstošām vērtībām.
Īss pakalpojumu sniedzēju veiktspējas un elastības salīdzinājums
Veiktspēja, funkcijas un DNS brīvība izlemt, cik elastīgi īstenot projektus. Praksē lielie serveri nodrošina stabilu Reakcijas laiksbet atšķiras pēc darbības, funkcijām un atbalsta. Izvēli vērtēju pēc veiktspējas, funkciju klāsta, palīdzības kvalitātes un DNS iespējām. Tālāk sniegtais pārskats sniedz saīsinātu priekšstatu, ko varu izmantot, lai pieņemtu lēmumu. Galu galā ir svarīgi tas, kas manam projektam patiešām ir nepieciešams, nevis lielākais funkciju saraksts.
| Nodrošinātājs | Veiktspēja | Funkciju darbības joma | Atbalsts | DNS elastīgums | Reitings |
|---|---|---|---|---|---|
| webhoster.de | Augsts | Ļoti plašs | Top | Maksimālais | 1 |
| Hetzner | Augsts | Plašs | Labi | Augsts | 2 |
| Contabo | Vidēja | Standarta | O. K. | Vidēja | 3 |
Īss kopsavilkums
Es iestatīju Hetzner DNS-zonu strukturētā veidā: Izveidojiet zonu, ievadiet vārda serveri ar reģistratoru, iestatiet galvenos ierakstus tīmeklim un pastam, pēc tam testējiet. Izmantojot piemērotu TTL Es saīsinu maiņas laikus un pēc pabeigšanas tos atkal pagarinu, lai samazinātu slodzi. SPF, DKIM un DMARC pastiprina piegādi un aizsargā domēnu pret ļaunprātīgu izmantošanu. Uzturot apakšdomēnus konsekventus un nodalot iekšējos un publiskos galamērķus. Izmantojot šo paraugkonfigurāciju un ikdienas pārbaudes, jūsu hetzner dns konfigurācija ir uzticama, ātra un viegli kopjama.
