Izpratne par DNS ierakstu veidiem
DNS ierakstu veidi ir pamata elementi, kas nosaka, kā domēns uzvedas internetā. Kad kāds atver mājaslapu, sūta e-pastu, verificē servisu vai pieslēdz lietotni konkrētam hostname, DNS parasti ir pirmais iesaistītais slānis. Daudzas domēna un hostinga problēmas, kas sākumā šķiet sarežģītas, patiesībā ir vienkāršas DNS kļūdas: A ieraksts norāda uz nepareizu IP, MX ieraksts nav izveidots, CNAME konfliktē ar citu ierakstu vai TXT vērtība ievadīta nepareizā sintaksē. Tāpēc izpratne par DNS ierakstiem ir noderīga ne tikai administratoriem, bet arī mājaslapu īpašniekiem, izstrādātājiem un visiem, kuri pārvalda domēnus.
Praktiski DNS darbojas kā izkliedēta adrešu grāmata. Tā vietā, lai cilvēkiem būtu jāatceras skaitliskas IP adreses, viņi izmanto nosaukumus, piemēram, example.com vai mail.example.com. Tomēr DNS dara vairāk nekā tikai pārtulko vārdus uz IP. Tas nosaka, kur jānogādā e-pasts, palīdz pierādīt domēna īpašumtiesības ārējiem servisiem, publicē anti-spam politikas un atbalsta apakšdomēnus un dažus servisu atklāšanas scenārijus. Ja jūs pārvaldāt domēnu caur domēnu reģistrāciju, hostējat mājaslapu uz hostinga vai izmantojat virtuālos serverus, ar DNS ierakstiem nāksies strādāt agrāk vai vēlāk.
Svarīgākais, ko atcerēties, ir tas, ka DNS darbojas kā zona ar vairākiem ierakstiem, nevis kā viens vienīgs iestatījums. Vienam domēnam vienlaikus var būt daudz ierakstu, un katram no tiem ir konkrēts uzdevums. Saknes domēns var izmantot A ierakstu mājaslapai, MX ierakstus e-pastam, TXT ierakstus SPF un verifikācijai, kā arī vairākus apakšdomēnus ar pilnīgi atsevišķu konfigurāciju. Kad saprotat biežākos ierakstu veidus, kļūst daudz vieglāk diagnosticēt problēmas, jo DNS vairs neizskatās pēc nejauša saraksta panelī, bet gan pēc strukturētas sistēmas.
A ieraksts ir vispazīstamākais. Tas sasaista hostname ar IPv4 adresi. Ja jūsu mājaslapa darbojas uz servera ar IP 203.0.113.10, A ieraksts example.com var norādīt tieši uz šo adresi. AAAA ieraksts dara to pašu, tikai IPv6 adresei. Praktiski, kad pārlūks vaicā, kur atrodas example.com, DNS serveris atbild ar IP no A vai AAAA ieraksta.
example.com. 3600 IN A 203.0.113.10 example.com. 3600 IN AAAA 2001:db8::10
CNAME ieraksts atšķiras. Tas nenorāda tieši uz IP adresi, bet pasaka, ka viens hostname ir cita hostname aizstājvārds. Piemēram, www.example.com var būt CNAME uz example.com, bet shop.example.com var būt CNAME uz ārēja SaaS servisa hostname. CNAME ir ērts, jo, ja mērķa hostname IP mainās, alias ieraksts nav jāpārraksta. Tomēr ir noteikums, ko bieži aizmirst: hostname ar CNAME nedrīkst vienlaikus saturēt konfliktējošus A, MX vai citus ierakstus tajā pašā nosaukumā.
www.example.com. 3600 IN CNAME example.com.
MX ieraksts kontrolē e-pasta piegādi. Tas pasaka citiem e-pasta serveriem, kurš mail host ir atbildīgs par jūsu domēna ienākošo pastu. Ja kāds sūta vēstuli uz info@example.com, sūtītāja serveris pārbauda MX ierakstus domēnam example.com un pēc tam pieslēdzas norādītajam pasta serverim. MX ierakstiem parasti ir prioritātes vērtība, kur mazāks skaitlis nozīmē augstāku prioritāti. Bieža kļūda ir izveidot MX ierakstu, bet aizmirst, ka pašam mail hostname arī jāatrisinās uz A vai AAAA ierakstu.
example.com. 3600 IN MX 10 mail.example.com. mail.example.com. 3600 IN A 203.0.113.20
TXT ieraksti ir ļoti elastīgi. Mūsdienu DNS vidē tie bieži tiek izmantoti verifikācijai un politiku publicēšanai. Servisi, piemēram, Microsoft 365, Google vai sertifikātu izsniedzēji, lūdz pievienot TXT ierakstu, lai pārbaudītu domēna īpašumtiesības. Arī e-pasta aizsardzība lielā mērā balstās uz TXT ierakstiem. SPF tiek publicēts ar TXT palīdzību un nosaka, kuri serveri drīkst sūtīt pastu jūsu domēna vārdā. Tā kā TXT vērtības mēdz būt garas, biežākās kļūdas ir nepareizas atstarpes, trūkstošas pēdiņas vai nepareizs hostname.
example.com. 3600 IN TXT "v=spf1 mx ip4:203.0.113.20 -all" _acme-challenge.example.com. 3600 IN TXT "verification-token"
Ar e-pastu cieši saistīti ir arī DKIM un DMARC. DKIM izmanto TXT ierakstus zem selektora, piemēram, default._domainkey.example.com, lai publicētu publisko atslēgu, ar kuru pārbauda parakstītas vēstules. DMARC parasti atrodas pie _dmarc.example.com un norāda, kā saņēmējiem rīkoties, ja SPF vai DKIM pārbaudes neizdodas. Kopā MX, SPF, DKIM un DMARC veido praktisko DNS pamatu biznesa e-pastam. Ja cilvēki sūdzas, ka vēstules nonāk spam, DNS ļoti bieži ir daļa no iemesla.
NS ieraksts nosaka, kuri vārdu serveri ir autoritatīvi domēnam vai deleģētam apakšdomēnam. Reģistratora līmenī NS ieraksti pasaka internetam, kur atrodas domēna DNS zona. Pašā zonā NS var arī deleģēt apakšdomēnu citam DNS pakalpojumu sniedzējam vai iekšējam serverim. SOA ieraksts satur zonas administratīvo informāciju, piemēram, primāro autoritatīvo serveri un sērijas numuru, ko izmanto zonas atjauninājumiem.
example.com. 3600 IN NS ns1.provider.net. example.com. 3600 IN NS ns2.provider.net.
Vēl viens izplatīts ieraksts ir PTR, ko izmanto reverse DNS. Atšķirībā no A ieraksta, kas sasaista nosaukumu ar IP, PTR sasaista IP adresi ar hostname. Reverse DNS ir īpaši svarīgs pasta serveriem, jo daudzi saņēmēji pārbauda, vai sūtītāja IP ir jēgpilns PTR ieraksts. Atšķirībā no parastajiem DNS ierakstiem PTR parasti kontrolē IP adreses piegādātājs, nevis jūsu ierastais DNS panelis.
Ir arī specializēti ieraksti, kas sastopami retāk, bet joprojām ir noderīgi. SRV ieraksti palīdz klientiem atrast servisus ar hostname un porta informāciju. CAA ieraksti nosaka, kurām sertifikātu autoritātēm ir atļauts izsniegt SSL sertifikātus jūsu domēnam. Mazas mājaslapas tos var nekad manuāli nerediģēt, bet lielākās infrastruktūrās tie palīdz samazināt kļūdas un ieviest lielāku kontroli.
_sip._tcp.example.com. 3600 IN SRV 10 5 5060 sip.example.com. example.com. 3600 IN CAA 0 issue "letsencrypt.org"
Kā pareizi lasīt DNS un izvairīties no biežākajām kļūdām
Strādājot ar DNS, svarīgākie paradumi ir konsekvence un pacietība. Vienmēr pārbaudiet hostname, ieraksta tipu, mērķa vērtību un TTL. TTL nosaka, cik ilgi atbildi drīkst glabāt kešatmiņā. Ja jūs nomaināt A ierakstu un neredzat rezultātu uzreiz, tas ne vienmēr nozīmē, ka izmaiņa nav nostrādājusi; ļoti bieži atbilde vienkārši vēl ir kešota. Pirms migrācijām administratori bieži samazina TTL, veic izmaiņu, pārbauda datplūsmu un pēc tam TTL atkal palielina.
Viena no biežākajām kļūdām ir nepareizi kombinēt ierakstus ar vienu un to pašu nosaukumu. Piemēram, hostname nedrīkst vienlaikus saturēt gan CNAME, gan A ierakstu. Vēl viena bieža problēma ir saknes domēna un apakšdomēna sajaukšana. TXT vai MX ieraksts, kas publicēts nepareizajā vietā, panelī var izskatīties pareizs, bet reālajā darbībā tas pilnīgi nestrādās. Īpaši jūtīga ir e-pasta DNS konfigurācija, kur pat neliela sintakses kļūda SPF, DKIM vai DMARC var salauzt validāciju.
Praktisks veids, kā pārbaudīt DNS, ir vaicāt to tieši. Tādi rīki kā nslookup, dig vai tiešsaistes DNS pārbaudes servisi ļauj ātri apstiprināt, vai ieraksts ir publicēts un redzams no ārpuses. Piemēram, A vai MX ieraksta pārbaude bieži palīdz ātri saprast, vai problēma ir pašā DNS vai kaut kur citur, piemēram, web servera konfigurācijā vai ugunsmūrī.
nslookup example.com nslookup -type=MX example.com dig example.com A dig example.com TXT
Vēl viens praktisks padoms ir pārbaudīt izmaiņas no vairākiem skatpunktiem: lokālā datora DNS kešatmiņa, publiskie resolveri un pats autoritatīvais DNS serveris ne vienmēr rāda vienu un to pašu tajā pašā sekundē. Tāpēc pēc izmaiņām ir vērts salīdzināt rezultātus, piemēram, ar nslookup pret vietējo resolveri un dig pret konkrētu publisku DNS serveri. Tas palīdz nošķirt “ieraksts nav publicēts” no “ieraksts ir publicēts, bet vēl nav visur izplatījies”.
Ja vienā domēnā pārvaldāt mājaslapu, e-pastu un ārējos servisus, DNS kļūst daudz vieglāk pārvaldāms, ja dokumentējat izmaiņas. Saglabājiet vienkāršu sarakstu ar apakšdomēniem, ierakstu nozīmi un servisiem, kuri no tiem ir atkarīgi. DNS nav sarežģīts tāpēc, ka ieraksti būtu mistiski. Tas kļūst sarežģīts tikai tad, ja neviens vairs neatceras, kāpēc konkrētais ieraksts vispār tika pievienots.
Beigās izpratne par DNS ierakstu veidiem nozīmē izpratni par to, kāpēc domēns uzvedas tieši tā, kā tas uzvedas. A un AAAA savieno vārdus ar serveriem, CNAME izveido aliasus, MX novirza e-pastu, TXT publicē verifikācijas un politikas datus, NS un SOA nosaka autoritāti, PTR nodrošina reverse lookup, bet specializētie SRV vai CAA ieraksti risina konkrētākus uzdevumus. Kad šīs lomas kļūst skaidras, DNS paneļi vairs neizskatās haotiski un sāk šķist loģiski un paredzami.