Teisingai nustatykite "Hetzner" DNS nustatymus - konfigūracijos pavyzdys su hetzner dns konfigūracija

"Hetzner DNS" konfigūracija kad svetainė, subdomenai ir paštas veiktų be trikdžių, o pakeitimai įsigaliotų greitai. Šiame vadove pateikiu būtinus "Hetzner DNS" nustatymus, išbandytą konfigūracijos pavyzdį ir praktinius testavimo metodus, kad galėtumėte anksti išvengti klaidų ir išlaikyti švarią zoną.

Centriniai taškai

Toliau pateikti pagrindiniai punktai padės greitai apžvelgti, kas svarbu, kad DNS zona būtų patikima.

• Vardų serveris teisingai įveskite registratoriaus
• A/AAAA žiniatinkliui, MX/TXT paštui
• TTL Tinkamai pasirinkite ir palaukite, kol informacija bus paskleista
• SPF/DKIM nuo nepageidaujamų laiškų ir suklastotų duomenų
• Stebėsena ir testai po pakeitimų

DNS trumpai: ko jums iš tikrųjų reikia

Aš priskiriu domeną per Įrašai konkrečias paskirties vietas, kad naršyklės ir pašto serveriai galėtų rasti mano paslaugas. A A-Record nurodo IPv4 adresą, AAAA - IPv6 adresą, o MX nurodo el. laiškų pristatymą. CNAME sudaro slapyvardį, nukreipiantį į kitą vardą, o TXT yra informacija, skirta SPF arba patikrinimus. Švarų bazinį scenarijų sudaro pagrindinio domeno A/AAAA, www CNAME, pašto MX ir SPF-TXT. Tokiu būdu zona išlieka aiški, greitai prižiūrima ir atvira vėlesniems plėtiniams.

Domeno įtraukimas į "Hetzner DNS" konsolę

DNS konsolėje pirmiausia sukuriu naują Zona ir patikrinkite, ar teisingai parašytas domenas. Tada įjungiu rankinę priežiūrą Įrašaikad galėčiau kurti ir keisti konkrečius įrašus. Patarimas: iš anksto pasižymiu IP adresus ir pašto paskirties vietas, kad galėčiau viską įvesti be pertraukų. Taip išvengiu spausdinimo klaidų ir nustatau įrašus ramia tvarka. Kai tik zona paruošta, suplanuoju vardų serverių keitimą ir vėlesnius patikrinimus.

Teisingai įveskite vardų serverį su registratoriumi

Sukūręs zoną, įvedu Vardų serveris iš "Hetzner", kad administravimas būtų sutelktas DNS konsolėje. Įprasti įrašai yra šie ns1.first-ns.de, robotns2.second-ns.de ir robotns3.second-ns.com. .de arba .at domenų atveju sukuriu savo vardų serverius su Klijų įrašaikad būtų išsaugotos nuorodos ir IP adresai. Jei niekada anksčiau to nedarėte, atskirus veiksmus galite rasti vadove Nustatyti klijų įrašus. Tuomet užtrunku šiek tiek laiko, kol pakeisiu programą, nes atnaujinimai visame pasaulyje gali būti siunčiami skirtingu greičiu.

Konfigūracijos pavyzdys: svetainės ir el. pašto paleidimas

Įprastai interneto svetainei naudoju A-Record šakniniam domenui, CNAME www ir tinkamus pašto įrašus. SPF-TXT neleidžia išoriniams serveriams siųsti el. laiškų domeno vardu. Pasirinktinai pridedu AAAA įrašą, jei žiniatinklio serveris IPv6 teikia. Išorinėms pašto paslaugoms, tokioms kaip ForwardMX, pritaikau MX ir saugau jų specifikacijas. Toliau pateiktoje lentelėje parodytas tvirtas pradinis daugelio nustatymų taškas.

Pavadinimas	Tipas	Vertė	Užuomina
@	A	195.201.210.43	Žiniatinklio serveris IPv4
@	AAAA	Pasirinktinai: 2a01:4f8:xxxx:xxxx::1	Žiniatinklio serveris IPv6
www	CNAME	@	Šaknies slapyvardis
@	MX	mx1.forwardmx.net	Prio 10
@	TXT	"v=spf1 include:_spf.forwardmx.net -all"	SPF apsauga nuo suklastojimo

Suaktyvinkite DNSSEC ir nustatykite DS įrašą

Jei man svarbus manipuliavimo saugumas, įjungiu DNSSEC zonai. "Hetzner" konsolėje sugeneruoju tam skirtus parašo raktus ir gaunu reikiamus DS duomenyskurį deponuoju registratoriui. Patikrinu, ar teisingai perduotas algoritmas ir digestas. Tada laukiu, kol bus tinkamai patvirtinta grandinė iš registratoriaus į zoną. Prieš didesnius raktų pasikeitimus sumažinu TTL ir suplanuoju laiko langą, kad resolveriai laiku pamatytų naujus parašus. Svarbu: jei atliekant pakeitimą įvyksta klaida, gavėjams patvirtinimas nepavyksta - todėl turiu pasiruošęs grįžimą atgal (per anksti neištrinkite senų raktų) ir išbandau su patvirtinimo resolveriais.

Teisingai nustatykite TTL ir supraskite sklaidą

Die TTL nustato, kiek laiko skirstytuvai talpina įrašą į spartinančiąją atmintį. Konversijoms pasirenku trumpą TTL (pvz., 300 sekundžių), kad pokyčiai būtų matomi greitai. Po galutinio nustatymo vėl padidinu reikšmes, kad sutaupyčiau užklausų ir pasiekčiau nuoseklią skiriamąją gebą. Tie, kurie dažnai diegia, mėgsta laikytis 600-1200 sekundžių, o tie, kurie retai atlieka pakeitimus, naudoja 3600-14400. Praktinę sprendimo apžvalgą pateikia mano žvilgsnis į Optimalus TTL pasirinkimas.

"Apex" domeno, CAA ir sertifikatų kontrolė

Dėl SaaS tikslų Zona "Apex Prisimenu, kad CNAME neleidžiama naudoti @. Todėl aš naudoju paslaugų teikėjo A/AAAA arba nustatau nukreipimą į www žiniatinklio serverio lygmeniu. Sertifikato priskyrimą kontroliuoju naudodamas CAA įrašaikurie CA yra įgalioti išduoti sertifikatus. Pavyzdžiui, aš prižiūriu tik tą CA, kurią iš tikrųjų naudoju, ir pasirinktinai pridedu ataskaitoms skirtą pašto adresą. Jei keičiu CA, prieš išduodamas trumpam padidinu TTL ir atnaujinu CAA. Naudodamasis ACME DNS-01, įsitikinu, kad TXT įrašai pagal _acme-challenge galima greitai nustatyti ir automatiškai išvalyti, kad neliktų senų iššūkių.

Švariai kurkite subdomenus ir paslaugas

Kiekvienam subdomenui sukuriu tinkamą A- arba CNAME-įrašas, priklausomai nuo to, ar subdomenas tiesiogiai nurodo į IP adresą, ar į vardą. Pavyzdys: blog.example.de kaip A-įrašas į tinklaraščio virtualųjį kompiuterį, cdn.example.de kaip CNAME į CDN vardą. API atveju griežtai skiriu vidinius ir viešuosius vardus, kad išvengčiau rizikos. Standartizuoti vardai, tokie kaip api, app, img, padeda atlikti priežiūrą ir stebėseną. Taip išlaikau zonos struktūrą ir galiu aiškiai priskirti pakeitimus.

Pakaitiniai ženklai, SRV ir specialūs įrašų tipai

Aš naudoju "Wildcard Records (*.example.de), pvz., kelių klientų konfigūracijoms. Užtikrinu, kad tikslūs įrašai visada būtų svarbesni už pakaitinius simbolius. Tokioms paslaugoms, kaip SIP, Matrix ar "Autodiscover", sukuriu SRV-įrašai ir patikrinkite formatą bei prioritetus. TXT įrašai su ilgu turiniu (pvz., 2048 bitų DKIM) suskirstomi į kelis citatų segmentus, kad analizatoriai galėtų juos tinkamai sujungti. Vengiu daugybinių SPF įrašų ir sujungiu įrašus į galiojantį SPF, kad nepažeisčiau paieškos ribos.

Patikimas el. pašto pristatymas: SPF, DKIM ir DMARC

Patikimam el. paštui naudoju MX švarų SPF-TXT, kuris apima mano siuntimo sistemas. Taip pat aktyvuoju DKIM naudojamoje pašto tarnyboje ir paskelbkite DKIM selektorių kaip TXT pagal selector._domainkey. Naudoju DMARC, kad apibrėžčiau, kaip gavėjai elgsis su laiškais, kurie neatitinka SPF/DKIM reikalavimų. Dažnai pradedu nuo "p=none", įvertinu ataskaitas ir vėliau perjungiu į "karantinas" arba "atmesti". Tokia seka mažina riziką ir palaipsniui didina pristatymo kokybę.

SPF/DKIM/DMARC gilinimas praktikoje

SPF palieku kuo mažiau: tik būtinas įtraukti-mechanizmai ir niekada ne daugiau kaip vienas SPF vienam kompiuterio vardui. Norėdamas laikytis 10 DNS paieškų ribos, mažinu grandines arba naudoju IP4/IP6 mechanizmus, jei jie yra stabilūs. Dėl DKIM rotacija Naudoju du aktyvius selektorius (seną ir naują), paskelbiu naują raktą, perjungiu pašto paslaugą ir tik po kelių dienų ištrinu senąjį. Su DMARC Iš pradžių nustatau ataskaitų teikimo adresus (rua/ruf) ir patikrinu išlyginimą (aspf/adkim). Subdomenams galiu naudoti sp= apibrėžti atskirą politiką, jei jie siunčiami atskirai. Taip reaguoju į realius srauto duomenis, o ne į prielaidas.

Atvirkštinis DNS (PTR) švariam pašto pristatymui

Be MX, SPF ir DKIM, nustatiau Atvirkštinis DNS (PTR) išeinančio pašto serveriams. IP PTR nurodo į prievadinio kompiuterio vardą, kuris savo ruožtu teisingai per A/AAAA (angl.Išankstinis / atvirkštinis atitikimas). PTR kiekvienam IP nustatau tiesiogiai su IP savininku (pvz., serverio sąsajoje) - ne domeno zonos valdyme. IPv6 naudoju nibble formatą. Tinkamas PTR sumažina nepageidaujamų pranešimų klasifikavimą ir padeda gerinti reputaciją. Jei paštas siunčiamas per išorinę paslaugą, palieku jos PTR tokį, koks jis yra, ir vengiu mišrių siuntėjo šaltinių be SPF pritaikymo.

Tipinės klaidos ir greiti sprendimai

Jei domenas neišsprendžiamas, pirmiausia patikrinu TTLvardų serverio įrašus ir teisingą įrašų rašybą. Antrasis žvilgsnis nukreiptas į SkleidimasKai kurie resolveriai talpina į talpyklą ilgiau, ypač padidinus TTL. Norėdamas atpažinti regioninius skirtumus, lyginu rezoliuciją naudodamas skirtingus DNS tikrintuvus. Jei kyla vietinių problemų, laikinai pereinu prie viešų skirstytuvų, pavyzdžiui, 1.1.1.1.1 arba 8.8.8.8.8. Jei klaida atsiranda tik vidiniuose tinkluose, patikrinu vidinius resolverius ir taisykles konteineriuose, "Kubernetes" arba "CoreDNS" konfigūracijose.

Bandymų metodai: dig, nslookup ir end-to-end

Testuoju ne tik įrašus, bet ir visą kelią:

• iškasti A/AAAA/CNAME/MX/TXT: patikrinti atsakymus, TTL ir autoritetą
• dig +traceŽr. delegavimo grandinę ir vardų serverio elgseną
• SMTP testaiPatikrinkite HELO/EHLO, TLS ir banerį
• HTTPS realusSertifikato grandinė, prieglobos vardas, nukreipimai

Tokiu būdu taip pat atpažįstu klaidas, kurių nematyti grynuose DNS atsakymuose, pvz., neteisingus "VirtualHost" atvaizdavimus arba pasibaigusius sertifikatus. Atlikęs pakeitimus, prieš darydamas galutines išvadas palaukiu bent vieną TTL.

Efektyvus darbas su "Hetzner" pulteliu

Grupuoju susijusius Įrašai laiko, nustatyti trumpą TTL terminą prieš atliekant svarbius pakeitimus ir viską paskelbti vienu kartu. Prieš išsaugodamas dar kartą patikrinu MX-prioritetai, SPF sintaksė ir A įrašo tikslinis IP. Serverio administravimui ir procesams skirtos kompaktiškos instrukcijos "Hetzner Robot" patarimai. Po diegimo, aš išbandyti http, https ir pašto su realiomis užklausomis, o ne tik per ping. Taip galiu atpažinti klaidas, kurių grynosios DNS užklausos nerodo.

Automatizavimas: API, šablonai ir ACME

Automatizuojant taupau laiką. Reguliariam diegimui naudoju API DNS konsolėje, kad galėtumėte kurti, keisti ar šalinti įrašus. Dirbu su pasikartojančių šablonų šablonais (pvz., "Web + Mail + DMARC") ir įterpiu tik konkretaus projekto reikšmes. Į "Let's Encrypt DNS-01" įtraukiu automatinį TXT įrašų rašiklį ir integruoju jį į atnaujinimo darbo eigą. Svarbu: su API žetonais elgiuosi kaip su slaptažodžiais, priskiriu juos konkretiems projektams ir panaikinu prieigą, kai jie nebereikalingi.

Išplėstinės sąrankos: "Split-Horizon", CDN ir ACME

Jei reikia, atskiriu vidaus ir išorės naudotojus. DNSperžiūros, kad vidinė programa nukreiptų į privačius IP adresus, o lankytojai - į viešas paskirties vietas. Ar naudoti CDNPer CNAME nukreipiu subdomenus į CDN pavadinimą ir aktyvuoju TLS. Automatiniams sertifikatams per "ACME/Let's Encrypt" pasirinktinai nustatau DNS-01 iššūkius per TXT, jei HTTP-01 neatitinka. Automatizavimas čia svarbus, kad atnaujinimai būtų atliekami laiku. Žurnalai ir pranešimai padeda laiku atpažinti nesėkmes.

Veikimo ir prieinamumo modeliai

Didinu prieinamumą paprastomis priemonėmis: Keletas A/AAAA įrašai (round robin) dalytis apkrovą be papildomų paslaugų, jei galinės stotys neturi būsenos arba dalijasi sesijomis. Atliekant techninę priežiūrą laikinai pašalinu atskirus IP ir vėl pakeliu įrašą. Per trumpas TTL paleidimas gali apkrauti resolverius; randu pusiausvyrą tarp atsako greičio ir talpyklos pataikymo dažnio. Nustatau aiškius procesus, skirtus failoversams be sveikatos patikrinimų: Gedimo atveju sukeičiu įrašus vietomis, aktyviai juos stebiu, o atsigavus vėl atstatau.

Sauga ir zonų higiena

Deaktyvuoju nereikalingus Zonų perkėlimai (AXFR) ir skelbti tik NSkurie iš tiesų yra autoritetingi. Reguliariai ištrinu senus ar našlaičiais tapusius subdomenus, kad neliktų šešėlinių paviršių. IDN atveju tikrinu Punycode-rašybos, kad išvengtumėte rašybos ir specialiųjų ženklų klaidų. Pagal vaidmenis pagrįsta prieiga konsolėje užtikrina, kad zonas keistų tik tinkami asmenys. Ir visai pragmatiškai: trumpai dokumentuosiu pakeitimus komandos įrankyje - tai gerokai sumažina užklausų skaičių darbo metu.

Migravimo ir atšaukimo strategija

Prieš persikraustymą sumažinu TTL (prieš 24-48 val.), atvaizduoju visus Įrašai į naująją zoną ir išbandykite perdavimą tiesiogiai per naujuosius vardų serverius. Tik tada, kai viskas teisinga, nustatau Vardų serveris pas registratorių. Po delegavimo stebiu srautą ir klaidas. Jei kas nors nepavyksta, kontroliuojamai atsuku atgal arba ištaisau atskirus įrašus. DNSSEC perkėlimą planuoju ypač konservatyviai ir palieku senąją parašų grandinę, kol bus saugiai įdiegta naujoji. Galiausiai atstatau TTL į gamybos reikalavimus atitinkančias vertes.

Trumpas paslaugų teikėjų palyginimas pagal našumą ir lankstumą

Veikimas, funkcijos ir DNS laisvė nuspręsti, kaip lanksčiai įgyvendinti projektus. Praktikoje didieji prieglobos paslaugų teikėjai teikia tvirtas Reagavimo laikastačiau skiriasi jų veikimas, funkcijos ir palaikymas. Pasirinkimą vertinu pagal našumą, funkcijų spektrą, pagalbos kokybę ir DNS parinktis. Toliau pateiktoje apžvalgoje pateikiamas sutrumpintas vaizdas, kurį galiu naudoti priimdamas sprendimus. Galiausiai svarbu tai, ko iš tikrųjų reikia mano projektui, o ne didžiausias funkcijų sąrašas.

Teikėjas	Veikimas	Funkcijų apimtis	Parama	DNS lankstumas	Reitingas
webhoster.de	Aukštas	Labai platus	Viršuje	Maksimalus	1
Hetzner	Aukštas	Platus	Geras	Aukštas	2
Contabo	Vidutinis	Standartinis	O. K.	Vidutinis	3

Trumpa santrauka

Nustatau Hetzner DNS-zoną struktūrizuotai: Sukurkite zoną, įveskite vardų serverį su registratoriumi, nustatykite pagrindinius įrašus žiniatinkliui ir paštui, tada išbandykite. Naudodami tinkamą TTL Sutrumpinu perjungimo laiką, o baigus darbą vėl jį pailginu, kad būtų mažesnė apkrova. SPF, DKIM ir DMARC sustiprina pristatymą ir apsaugo domeną nuo piktnaudžiavimo. Subdomenus laikau nuoseklius ir atskiriu vidinius ir viešus paskirties taškus. Naudojant šią pavyzdinę konfigūraciją ir kasdienius patikrinimus, jūsų hetzner dns konfigūracija išlieka patikima, greita ir lengvai prižiūrima.