Դոմեններ և DNS

01Երեք տարբեր դերեր՝ registrar, nameserver-ներ, DNS hosting

Դրանք հաճախ շփոթում են, որովհետև մեկ ընկերությունը կարող է անել երեքն էլ։ Registrar-ն այն տեղն է, որտեղ գնում և երկարաձգում եք դոմենը (օրինակ՝ Namecheap, Porkbun կամ Cloudflare Registrar), այն խոսում է registry-ի հետ, որը կառավարում է TLD-ն, օրինակ՝ .com-ը։ Registrar-ի պանելում նշում եք, թե որ nameserver-ներն են authoritative ձեր դոմենի համար։ Nameserver-ները պատկանում են DNS host-ին, և DNS host-ն այն տեղն է, որտեղ ապրում են ձեր իրական գրառումները՝ A, CNAME, MX և այլն։ Այսինքն՝ կարող եք դոմենը գնել մի registrar-ից, nameserver-ները ուղղել Cloudflare-ին և բոլոր գրառումները կառավարել Cloudflare-ում։ Եթե գրառումները խմբագրում եք registrar-ում, մինչդեռ nameserver-ները ցույց են տալիս այլ տեղ, ոչինչ չի կատարվում, և սա շփոթության շատ տարածված աղբյուր է։ Անալոգիա՝ registrar-ը հողային ռեեստրն է, nameserver-ները ցուցանակն են, որ ասում է՝ որ գրասենյակն է պահում հասցեագիրքը, իսկ DNS host-ը հենց այդ գրասենյակն է։

• Registrar՝ սեփականություն, երկարաձգում, nameserver-ների կարգավորում, WHOIS/RDAP կոնտակտ, transfer lock։
• Nameserver-ներ՝ որ DNS պրովայդերն է authoritative պատասխանում դոմենի համար։
• DNS hosting՝ իրենք՝ գրառումները։

02Ինչպես է աշխատում lookup-ը

Ձեր սարքը հարցնում է recursive resolver-ին (ձեր ISP, 1.1.1.1, 8.8.8.8)։ Եթե պատասխանը քեշում չէ, resolver-ը root սերվերին հարցնում է, թե որտեղ է .com-ը, .com սերվերներին՝ թե որ nameserver-ներն են սպասարկում example.com-ը, հետո այդ authoritative nameserver-ներից խնդրում է գրառումը։ Յուրաքանչյուր պատասխան քեշավորվում է իր TTL-ի (time to live) չափով՝ վայրկյաններով։ Հաջորդ անգամ այդ resolver-ն օգտագործող ցանկացած մեկը քեշավորված պատասխանը ստանում է ակնթարթորեն։ Այս քեշավորման շնորհիվ է DNS-ը մասշտաբավորվում ամբողջ ինտերնետի վրա, և նաև դրա պատճառով են փոփոխությունները ոչ միանգամից ամենուր տեսանելի։

1# Ask a specific resolver, then follow the whole chain
2dig example.com A @1.1.1.1
3dig +trace example.com
4# Which nameservers are authoritative?
5dig example.com NS +short
6# Ask the authoritative server directly (skips caches)
7dig example.com A @ns1.example-dns.net +short

03Գրառումների տեսակներ, որոնք իրականում կօգտագործեք

A-ն անունը կապում է IPv4 հասցեի, AAAA-ն՝ IPv6-ի։ CNAME-ը մի անունը դարձնում է մեկ այլ անվան alias․ այն չի կարող գտնվել root դոմենի (apex) վրա այլ գրառումների կողքին, ուստի պրովայդերներն apex-ի համար առաջարկում են ALIAS, ANAME կամ CNAME flattening։ MX-ն աշխարհին ասում է, թե որ սերվերներն են ընդունում էլ. փոստը՝ առաջնահերթությամբ (փոքրը փորձվում է առաջինը)։ TXT-ն պահում է տեքստ, որն օգտագործվում է դոմենի հաստատման և էլ. փոստի անվտանգության համար․ SPF-ը թվարկում է, թե ով կարող է ձեր անունից նամակ ուղարկել, DKIM-ը հրապարակում է ստորագրման բանալի, DMARC-ն ասում է, թե ստացողներն ինչ անեն չանցած նամակների հետ։ NS-ը պատվիրակում է zone, CAA-ն սահմանափակում է, թե որ certificate authority-ները կարող են սերտիֆիկատ թողարկել ձեր դոմենի համար, իսկ SRV-ն նկարագրում է ծառայություններ՝ պորտով։ Յուրաքանչյուր գրառում ունի անուն, տեսակ, արժեք և TTL։

1example.com.        300  IN A      203.0.113.10
2example.com.        300  IN AAAA   2001:db8::10
3www.example.com.    300  IN CNAME  example.com.
4example.com.        3600 IN MX     10 mail.example-mail.com.
5example.com.        3600 IN TXT    "v=spf1 include:_spf.example-mail.com -all"
6_dmarc.example.com. 3600 IN TXT    "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
7example.com.        3600 IN CAA    0 issue "letsencrypt.org"

04TTL և «propagation»

DNS-ն իրականում չի «տարածվում»․ քեշերն են ժամկետանց դառնում։ Եթե գրառումն ունի 86400 (մեկ օր) TTL, հին արժեքը քեշավորած resolver-ը կարող է այն օգտագործել փոփոխությունից հետո մինչև մեկ օր։ Nameserver-ների փոփոխությունն ավելի դանդաղ է, քանի որ TLD մակարդակում պատվիրակումը հաճախ ունի մեկ-երկու օրվա TTL։ Միգրացիայի գործնական բաղադրատոմսը՝ TTL-ն իջեցրեք 300 վայրկյանի առնվազն հին TTL-ի մեկ ժամանակահատված առաջ, կատարեք փոփոխությունը, ստուգեք մի քանի resolver-ներից և TTL-ը կրկին բարձրացրեք, երբ ամեն ինչ կայուն լինի։ Որոշ resolver-ներ քեշավորում են նաև բացասական պատասխանները («այս անունը գոյություն չունի»)՝ ըստ SOA գրառման, ուստի գրառումները ստեղծեք նախքան դրանց մասին հայտարարելը։

• 300 վ այն գրառումների համար, որոնք կարող եք շուտով փոխել, 3600 վ կամ ավելի՝ կայունների համար։
• Ստուգեք մի քանի resolver-ներից, ոչ միայն ձեր լափթոփից։
• Բրաուզերի և OS-ի քեշերը կարող են պահել հին պատասխանները․ flush արեք կամ ստուգեք dig-ով։

05Գրառումների ստուգում dig-ով և nslookup-ով

dig-ը ստանդարտ գործիքն է Linux-ում և macOS-ում, nslookup-ն աշխատում է ամենուր, ներառյալ Windows-ը։ Միշտ ստուգեք և՛ authoritative պատասխանը, և՛ հանրային resolver-ը, որպեսզի իմանաք՝ խնդիրը ձեր գրառո՞ւմն է, թե՞ քեշը։ Էլ. փոստի համար ստուգեք MX-ը և SPF-ի, DKIM-ի (selector subdomain-ի վրա) ու DMARC-ի TXT գրառումները։ Սերտիֆիկատների համար ստուգեք CAA-ն։ Առցանց գործիքները, որոնք հարցում են անում բազմաթիվ երկրներից, օգնում են հաստատել, որ փոփոխությունը հասել է resolver-ների մեծ մասին։ +short flag-ը տպում է միայն պատասխանը, ինչը հարմար է սկրիպտներում և runbook-ներում։

1dig +short example.com A
2dig +short www.example.com CNAME
3dig +short example.com MX
4dig +short example.com TXT
5dig +short selector1._domainkey.example.com TXT
6nslookup -type=MX example.com 8.8.8.8
7# Windows / PowerShell
8Resolve-DnsName example.com -Type A -Server 1.1.1.1

06Production խորհուրդներ

Դոմենն ինքնին դիտարկեք որպես կրիտիկական ենթակառուցվածք։ Միացրեք auto-renew-ը և registrar lock-ը, օգտագործեք երկգործոն նույնականացմամբ հաշիվ և կոնտակտային էլ. փոստը պահեք մի փոստարկղում, որը հինգ տարի հետո էլ դեռ ձերը կլինի։ Միացրեք DNSSEC-ը, եթե ձեր registrar-ը և DNS host-ն այն աջակցում են, որպեսզի պատասխանները հնարավոր չլինի կեղծել։ Պահեք ձեր zone ֆայլի արտահանված պատճենը։ Nameserver-ները տեղափոխելուց առաջ նոր host-ում նախ վերստեղծեք բոլոր գրառումները, հատկապես MX-ն ու TXT-ն, այլապես էլ. փոստը լուռ կկոտրվի։ Ջնջեք «կախված» գրառումները, որոնք ցույց են տալիս այլևս չօգտագործվող ծառայություններ, որովհետև դրանք կարող են զավթվել ուրիշների կողմից։

07Delegation, glue record-ներ և SOA

Zone-ը DNS ծառի այն մասն է, որի համար պատասխանատու է nameserver-ների մեկ խումբ։ .com zone-ը ձեր A record-ը չի պահում. այն պահում է NS record-ներ, որոնք example.com-ը delegate են անում ձեր nameserver-ներին։ Եթե ձեր nameserver-ները գտնվում են նույն դոմենի ներսում (ns1.example.com), առաջանում է «հավի և ձվի» խնդիր, ուստի ծնող zone-ը նաև պահում է դրանց IP հասցեները որպես glue record-ներ, որոնք սահմանվում են registrar-ում։ Յուրաքանչյուր zone սկսվում է SOA record-ով. հիմնական nameserver-ը, կոնտակտը, serial համարը, որով secondary-ները հասկանում են, թե երբ է պետք թարմացումները փոխանցել, և negative caching-ի TTL-ը։ Վերջին արժեքը որոշում է, թե որքան ժամանակ են resolver-ները հիշում, որ անունը գոյություն չունի։ Lame delegation լինում է, երբ ծնողը մատնացույց է անում nameserver-ներ, որոնք իրականում չեն պատասխանում այդ zone-ի համար, ինչը որոշ resolver-ների մոտ դանդաղ կամ ձախողված lookup-ներ է առաջացնում։

1# Delegation as seen by the .com servers
2dig example.com NS @a.gtld-servers.net +norecurse
3# SOA: primary NS, serial, refresh, retry, expire, negative TTL
4dig example.com SOA +short
5# A name that does not exist returns NXDOMAIN plus the SOA
6dig nothing-here.example.com A

08DNSSEC. պատասխանների ստորագրում

Դասական DNS-ը չունի ապացուցելու միջոց, որ պատասխանն իսկական է, ուստի cache-poisoning հարձակումը կարող էր օգտատերերին ուղարկել կեղծ IP։ DNSSEC-ը ավելացնում է ստորագրություններ։ Ձեր DNS host-ը ստորագրում է յուրաքանչյուր record set (RRSIG record-ներ) zone key-ով, որը հրապարակված է որպես DNSKEY record։ Ծնող zone-ը պահում է DS record՝ ձեր key-ի hash-ը, որը դուք ավելացնում եք registrar-ում։ Validating resolver-ները հետևում են շղթային՝ root-ի key-ից դեպի .com, դեպի ձեր DS, դեպի ձեր DNSKEY, դեպի պատասխանի ստորագրությունը։ Եթե որևէ բան չի համընկնում, resolver-ը կեղծ պատասխանի փոխարեն վերադարձնում է SERVFAIL։ Գործառնական ռիսկն այն է, որ անհամապատասխանությունը կոտրում է նաև օրինական դոմենը. DNS host-ը փոխելը առանց նախապես DS record-ը հեռացնելու կամ թարմացնելու դոմենն անհասանելի է դարձնում բոլոր validating resolver-ների համար։ Managed provider-ները կառավարում են key rotation-ը, ձեր գործը DS record-ն է։

1dig example.com DNSKEY +dnssec +short
2dig example.com DS +short          # what the parent publishes
3dig example.com A +dnssec          # look for the "ad" flag from a validating resolver
4# Online: dnsviz.net shows the full chain of trust

09Ժամանակակից record-ներ. HTTPS/SVCB, CAA մանրամասներ և serve-stale

HTTPS record-ը (RFC 9460, SVCB-ի տեսակ) թույլ է տալիս դոմենին բրաուզերներին դեռ միանալուց առաջ ասել, թե որ պրոտոկոլներն է աջակցում (օրինակ՝ h3 և h2), այլընտրանքային port-եր, IP hint-եր և key-եր Encrypted Client Hello-ի համար։ Այն կարող է նաև դրվել apex-ի վրա և մատնացույց անել այլ hostname, ինչը մասամբ լուծում է apex-CNAME-ի հին խնդիրը այն բրաուզերների համար, որոնք աջակցում են։ Cloudflare-ը և այլ provider-ներ այն ավտոմատ հրապարակում են proxied hostname-ների համար։ CAA record-ները կարող են պարունակել նաև iodef (ուր CA-ները հաղորդում են մերժված հարցումների մասին) և issuewild (որ CA-ն կարող է wildcard թողարկել)։ Resolver-ի կողմում շատ իրականացումներ հետևում են serve-stale-ին (RFC 8767). եթե ձեր authoritative սերվերներն անհասանելի են, դրանք կարող են որոշ ժամանակ շարունակել մատուցել ժամկետանց պատասխաններ։ Սա օգնում է հասանելիությանը խափանումների ժամանակ, բայց նշանակում է, որ շատ կարճ TTL-ը երբեք արագ failover-ի երաշխիք չէ։

1dig example.com HTTPS +short
2# 1 . alpn="h3,h2" ipv4hint=203.0.113.10
3dig example.com CAA +short
4# 0 issue "letsencrypt.org"
5# 0 issuewild ";"          <- nobody may issue wildcards
6# 0 iodef "mailto:[email protected]"

10Անվտանգություն. takeover-ներ, zone-ի հիգիենա և anycast

Subdomain takeover լինում է, երբ record-ը, սովորաբար CNAME, մատնացույց է անում ձեր ջնջած third-party ռեսուրս, օրինակ՝ cloud storage bucket, PaaS հավելված կամ landing-page ծառայություն։ Ուրիշը վերցնում է այդ ռեսուրսի անունը և հիմա բովանդակություն է մատուցում ձեր subdomain-ով, իսկ ձեր cookie-ները նրա scope-ում են։ Կանխեք դա՝ DNS record-ները ջնջելով ռեսուրսից առաջ կամ դրա հետ միասին, և պարբերաբար audit անելով zone-ը։ Հիգիենայի այլ կանոններ. երբեք մի թույլատրեք բաց zone transfer-ներ (AXFR) որևէ մեկին, խուսափեք wildcard record-ներից, եթե դրանք նպատակային չեն, և ներքին hostname-ները մի պահեք հրապարակային DNS-ում, քանի որ դրանք բացահայտում են ձեր ցանցի քարտեզը։ Կայունության համար լավ DNS provider-ները օգտագործում են anycast. նույն nameserver IP-ն հայտարարվում է բազմաթիվ վայրերից, ուստի հարցումները գնում են մոտակա առողջ կետ, իսկ մեծ հեղեղները բաշխվում են։