DNS: tylus žudikas, apie kurį niekas negalvoja iki avarijos.

Serveris veikia. Programa atsako. Duomenų bazė gyva. Tačiau svetainė nepasiekiama jau dvi valandas, o pagalbos tarnyba skęsta užklausose. Žiūrite į monitoringą — viskas žalia. Žiūrite į nginx žurnalus — tyla, nė vienos užklausos. Ir tada suvokiate: problema ne serveryje. Problema ta, kad iki serverio niekas nepasiekia.

DNS. Vėl DNS.

Tai sistema, kurią sukonfigūruoji pirmą dieną ir pamiršti metams. Iki kitos avarijos trečią nakties.

KAIP VEIKIA DNS — BE VANDENS

DNS — tai interneto telefonų knyga. Jūs žinote vardą, DNS žino numerį. Naršyklė žino domeną, DNS grąžina IP.

Kai naudotojas įveda example.com, prasideda grandinė:

1. Naršyklė tikrina vietinę talpyklą. Jei neseniai jau rezolvavo — paima iš ten.
2. Jei ne — klausia sistemos resolverio (maršrutizatorius, ISP DNS, arba 1.1.1.1 jei taip sukonfigūravote).
3. Resolveris nežino — eina prie root serverių. Jų yra 13, ir jie žino viską aukščiausio lygio.
4. Root serveriai sako: „Už .com atsako šie serveriai.”
5. .com TLD serveriai sako: „Už example.com atsako šie nameserveriai.”
6. Domeno nameserveriai grąžina galutinį IP.
7. Naršyklė pagaliau prisijungia prie serverio.

Visa ši kelionė trunka 20–150 milisekundžių. Pirmojo užklausimo metu. Po to atsakymas saugomas talpykloje.

Čia atsiranda TTL — Time To Live. Tai sekundžių skaičius, kiek talpykloje išlieka atsakymas. TTL = 3600 reiškia, kad valandą visi gaus talpykloje esantį atsakymą, nekliudydami jūsų nameserverių. Skamba kaip optimizacija — ir taip yra. Tačiau būtent TTL tampa pagrindine problema, kai reikia kažką skubiai pakeisti.

DNS ĮRAŠŲ TIPAI: KAS UŽ KĄ ATSAKINGA

Dauguma žino tik A įrašą ir tuo sustoja. Tai kaip žinoti tik pirmą pavarą — važiuoti galima, bet lėtai ir neteisingai.

A įrašas susieja domeną su IPv4 adresu. Pats pagrindinis. example.com → 192.0.2.1 (IP rezervuotas dokumentacijai pagal RFC 5737).

AAAA įrašas — tas pats IPv6. 2026 metais ignoruoti IPv6 reiškia sąmoningai atkirsti dalį auditorijos.

CNAME įrašas — pseudonimas. www.example.com nurodo į example.com, o ne tiesiogiai į IP. Patogu: pakeičiate vieną A įrašą, visi CNAME automatiškai pasirenka naują reikšmę. Svarbu: CNAME negalima naudoti root domene (apex). Tik subdomenams. Kitaip sugadinsite MX ir NS. Kai kurie DNS tiekėjai tai apeina savo plėtiniais — ALIAS arba ANAME — bet tai jau jų vidinė magija.

MX įrašas nurodo, kur pristatinėti el. paštą domenui. Be jo laiškai tiesiog dingsta kažkur internete. MX turi prioritetą — kuo mažesnis skaičius, tuo aukštesnis prioritetas. Keli MX įrašai su skirtingais prioritetais suteikia pašto rezervavimą.

TXT įrašas — visų tekstinių duomenų sąvartynas. Domeno patvirtinimas Google, AWS, Cloudflare. SPF, DKIM, DMARC. Viskas gyvena TXT. Nestruktūrizuota, bet lankstu.

NS įrašas nurodo, kurie nameserveriai yra autoritetingi zonai. Tai saugumo požiūriu kritiškas įrašas: jei užpuolikas pakeičia NS — jis gauna visišką kontrolę virš jūsų DNS.

PTR įrašas — atvirkštinis DNS. IP → domenas. Pašto serveriai visada tikrina PTR gaudami laiškus. Nėra PTR — laiškas į šlamštą arba atmetamas. Konfigūruojamas ne pas registratorių, o pas prieglobos tiekėją.

CAA įrašas apriboja, kurios sertifikatų institucijos gali išduoti SSL sertifikatus domenui. Viena eilutė — ir joks pašalinis CA neišduos sertifikato jūsų domenui, net jei įrodys domeno kontrolę kitais metodais.

SRV įrašas aprašo konkretų servisą: protokolą, serverį, prievadą, prioritetą. Naudojamas VoIP, įmonių susirašinėjimo sistemose, kai kuriuose žaidimų serveriuose.

SOA — Start of Authority. Tarnybinis įrašas su zonos metaduomenimis: pagrindinis nameserveris, administratoriaus el. paštas, serijos numeris secondary serverių sinchronizacijai. Retai liečiamas, bet verta žinoti.

KAIP DNS ŽUDO SERVISUS — REALŪS SCENARIJAI

Tai ne teorija. Tai kas nutinka reguliariai.

DNS tiekėjas krito. Jūsų serveris puikioje būklėje. Tačiau DNS zona yra pas registratorių, kuris naktį patyrė gedimą. Niekas negali rezolvuoti domeno. Naudotojams svetainė mirusi — nors ji veikia ir laukia jungčių. 2021 metų spalį BGP konfigūracijos klaida nugriovė Facebook, Instagram ir WhatsApp daugiau nei septynioms valandoms. Techniškai serveriai veikė. Tačiau BGP maršrutai iki Facebook DNS serverių buvo atšaukti, DNS nustojo atsakyti, ir milijardai naudotojų pamatė tuščią ekraną.

TTL nesumažino prieš migraciją. Perkeliate į naują serverį. A įrašo TTL — 86400 (para, kaip daugelio registratorių numatytoji reikšmė). Atnaujinote įrašą, tačiau pusė pasaulio dar 24 valandas eina prie senojo IP. Jei senasis serveris jau išjungtas — tiems naudotojams jūsų nėra. Sprendimas paprastas ir žinomas: prieš dvi paras iki migracijos sumažinate TTL iki 300. Po perkėlimo — grąžinate atgal.

Nėra automatinio failover. Pagrindinis serveris krito. Rezervinis paruoštas ir laukia. Tačiau DNS vis dar nurodo į negyvą IP, nes perjungimą konfigūruoti buvo planuojama „vėliau”. „Vėliau” atėjo penktadienio vakarą.

Domeno užgrobimas. Užpuolikas gauna prieigą prie registratoriaus paskyros — per nutekėjusį slaptažodį, sukčiavimą arba valdymo skydelio pažeidžiamumą. Pakeičia NS įrašus į savuosius. Dabar jis valdo jūsų DNS. Gali peradresuoti srautą, išduoti SSL sertifikatą jūsų domenui, perimti el. paštą. Jūsų serveriai gyvi, jūsų kodas nepalietas — tačiau servisas faktiškai jo kontroliuojamas. 2019 metais būtent taip veikė Sea Turtle kampanija — tariamos iranietiškos priklausomybės aktoriai kompromitavo registratorius ir DNS tiekėjus, po to perėmė vyriausybių ir telekomunikacijų įmonių srautą daugiau nei 13 šalių. Cisco Talos tai pavadino „pirmuoju viešai patvirtintu atveju, kai buvo sukompromituotas pats DNS registratorius.”

Talpyklos apnuodijimas. Užpuolikas įterpia suklastotus DNS atsakymus į resolverio talpyklą. Naudotojai gauna suklastotą IP ir patenka pas užpuoliko serverį, manydami kad pas jūsų. Ataka žinoma nuo 1990-ųjų. Sprendžiama DNSSEC — tačiau daugelis vis dar neįjungė.

Subdomain takeover. Išjungėte servisą — S3 bucket, Heroku programą, GitHub Pages — bet pamiršote pašalinti CNAME įrašą iš DNS. Įrašas kabo ir nurodo į nebeegzistuojantį resursą. Užpuolikas užregistruoja tą resursą savo vardu, ir jūsų subdomenas dabar rodo jo turinį. Triviali ataka, aptinkama skeneriais automatiškai. Lengva patikrinti: peržiūrėkite visus CNAME įrašus zonoje ir įsitikinkite, kad kiekvienas iš jų realiai kažkur veda.

DNS amplification. Serveris su atviru resolveriu gali tapti ginklu svetimose rankose. Veikia taip: užpuolikas nori nugriauti auką, tačiau vietoj tiesioginės atakos naudoja jūsų DNS kaip stiprintuvą. Siunčia mažą užklausą (60 baitų) su suklastotu aukos IP — DNS veikia per UDP, kur nėra handshake ir šaltinio IP lengva suklastoti. Jūsų resolveris sąžiningai atsako dideliu paketu (3000+ baitų) — bet ne užpuolikui, o aukai, nes būtent jos IP yra užklausoje.

Iš čia kyla iki 50x stiprinimo koeficientas: atsakymo dydžio ir užklausos santykis. Užpuolikas išnaudojo 1 Mbps savo srauto — auka gavo 50 Mbps. Ypač didelius atsakymus duoda ANY užklausos ir TXT įrašai domenams su DNSSEC — kriptografinės parašai labai išpučia paketo dydį.

Jei turite atvirą resolverį — jūsų serveris dalyvauja atakose prieš kitus. Prieglobos tiekėjas gauna piktnaudžiavimo pranešimus, IP reputacija krenta, pralaidumas naudojamas kažkieno kito srautui. Milijonai atvirų resolverių visame internete reguliariai naudojami būtent taip. Patikrinkite, ar turite atvirą resolverį:

dig @JŪSŲ_IP example.com

Jei atsakė — uždarykite rekursiją išoriniams adresams bind/unbound nustatymuose, arba užblokuokite 53 prievadą ugniasienėje visiems adresams, išskyrus savuosius tinklus.

Atviras resolveris — tai DNS serveris, atsakantis į rekursines užklausas iš bet kokio IP internete, o ne tik iš savų klientų. Normalus resolveris aptarnauja tik savo tinklą. Atviras — atsako visiems, kas ir daro jį naudingu amplification atakoms.

Uždaroma trimis būdais. Per nftables — paprasčiausias, nereikia liesti DNS serverio:

nft add rule inet filter input udp dport 53 \
    ip saddr != { 127.0.0.1, 10.0.0.0/8, 192.168.0.0/16 } drop

Per bind — išjungti rekursiją konfigūracijos lygmeniu:

# /etc/named.conf
options {
    recursion yes;
    allow-recursion { 127.0.0.1; 10.0.0.0/8; };
};

Per unbound:

# /etc/unbound/unbound.conf
server:
    access-control: 0.0.0.0/0 refuse
    access-control: 127.0.0.1/32 allow
    access-control: 10.0.0.0/8 allow

Jei nevaldote viešo DNS serverio — tiesiog užblokuokite 53 prievadą ugniasienėje visiems išoriniams adresams ir daugiau apie tai negalvokite.

APIE KĄ PAPRASTAI NERAŠOMA

DNSSEC egzistuoja nuo 2005 metų. Prideda kriptografinį parašą prie DNS atsakymų — resolveris gali patikrinti, kad atsakymas tikras, o ne suklastotas. 2026 metais nemaža dalis domenų vis dar veikia be DNSSEC. Argumentas „sunku sukonfigūruoti” seniai pasenęs: Cloudflare įjungia DNSSEC vienu mygtuko paspaudimu.

DNS perduodamas atviru tekstu. Visada. Jūsų ISP mato kiekvieną domeną, kurį rezolvuojate. Įmonės ugniasienė — taip pat. Kiekvienas, sėdintis tarp jūsų ir resolverio, mato pilną domenų sąrašą — be jokio įsilaužimo, tiesiog pasyviai klausydamas srauto.

DNS over TLS (DoT) ir DNS over HTTPS (DoH) sprendžia tai skirtingais būdais, bet su vienu tikslu — užšifruoti DNS užklausą taip, kad niekas negalėtų jos perskaityti kelyje.

Kodėl tai svarbu? DNS — vienintelis protokolas, kurio negalima užblokuoti. 53 prievadas atviras visur — kitaip niekas neveikia. Būtent todėl neužšifruotas DNS yra skylė, kurią visi ignoruoja.

Jūsų ISP, prieglobos tiekėjas, įmonės ugniasienė arba tiesiog kažkas tame pačiame tinkle mato kiekvieną domeną, prie kurio jūngiasi jūsų serveris. Užklausos į išorines API, į paketų saugyklas, į monitoringo sistemas — visa tai žvalgyba be jokio įsilaužimo, tiesiog pasyviai klausantis.

Neužšifruotą DNS galima pakeisti kelyje. Paketas atrodo kaip legitimūs DNS atsakymas — resolveris priima, naudotojas patenka ne ten. Būtent taip veikia man-in-the-middle ataka DNS lygmeniu. Su DoT/DoH pakeitimas neįmanomas: ryšys užšifruotas ir autentifikuotas sertifikatu.

Galiausiai: ISP ir įmonių tinklai blokuoja domenus būtent per DNS. DoH tai apeina, nes užklausa neatskiriama nuo įprasto HTTPS srauto.

DoT veikia 853 prievade ir apgaubia įprastą DNS TLS ryšiu. Švaru ir aišku, tačiau lengvai blokuojama ugniasienėje — pakanka uždaryti 853 prievadą.

DoH veikia 443 prievade — tame pačiame kaip įprastas HTTPS. DNS užklausos atrodo kaip įprasti interneto puslapių užklausos. Užblokuoti jas nesugadinant viso HTTPS praktiškai neįmanoma.

Naršyklės — Firefox, Chrome, Edge — palaiko DoH iš karto. Firefox pagal nutylėjimą naudoja Cloudflare 1.1.1.1, apeidamas sistemos DNS. Chrome ir Edge veikia kitaip: jie atnaujina sistemos DNS iki DoH, jei tiekėjas tai palaiko, tačiau sistemos resolverio neapeina. Serveryje bet kuriuo atveju reikia konfigūruoti rankiniu būdu.

Linux serveryje DoT paprasčiausiai įjungiama per systemd-resolved:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net
DNSOverTLS=yes

Arba per stubby lankstesnei konfigūracijai:

apt install stubby          # Debian/Ubuntu
dnf install stubby          # RHEL/Fedora

# /etc/stubby/stubby.yml — pagrindiniai parametrai:
# resolution_type: GETDNS_RESOLUTION_STUB
# dns_transport_list: GETDNS_TRANSPORT_TLS
# tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
# upstream_recursive_servers: 1.1.1.1, 9.9.9.9

Po to stubby klauso 127.0.0.1:53 ir perduoda visas užklausas per TLS. /etc/resolv.conf įrašote nameserver 127.0.0.1 — ir visas sisteminis DNS eina užšifruotas.

DNS tunelizavimas — savavališkų duomenų perdavimas DNS paketuose. Ugniasienė blokuoja viską, išskyrus DNS 53 prievade. Tačiau DNS srautas visada leidžiamas — kitaip niekas neveikia. Ir būtent per jį malware perduoda komandas ir išfiltruoja duomenis. Sunku aptikti: DNS užklausos atrodo normaliai, tik jų labai daug ir domeno vardai įtartinai ilgi.

Registratorius ir DNS tiekėjas — skirtingi dalykai. Pirkote domeną pas registratorių, ir jis pagal nutylėjimą taip pat talpina jūsų DNS zoną. Patogu, tačiau sukuria vieną gedimo tašką. Jei registratorius krenta — DNS krenta kartu. Protingesnis variantas: domenas pas registratorių, DNS zona pas Cloudflare arba kitą specializuotą tiekėją su normaliu SLA.

Anycast — kai vienas IP adresas aptarnaujamas iš daugybės taškų visame pasaulyje vienu metu. Cloudflare, Google Public DNS ir kiti stambūs DNS tiekėjai veikia būtent taip. Užklausa iš Singapūro eina į artimiausią duomenų centrą, o ne per Atlantą. Rezolvavimas trunka vienetus milisekundžių. Cloudflare tinklas 2026 metais apima 300+ miestų daugiau nei 100 šalių. Vienas nameserveris ant VPS Vokietijoje to neužtikrins.

Zone transfer (AXFR) — DNS zonos sinchronizavimo mechanizmas tarp primary ir secondary nameserverių. Reikalingas dalykas, tačiau jei neapribotas pagal IP — bet kas gali parsisiųsti pilną jūsų DNS įrašų sąrašą viena komanda. Visi subdomenai, visi vidiniai servisai, visi IP adresai — paruoštas infrastruktūros žemėlapis žvalgybai prieš ataką. Patikrinkite:

dig @ns1.example.com example.com AXFR

Jei grąžino įrašus — turite atvirą zone transfer. Nameserverio nustatymuose apribokite AXFR tik savo secondary serverių IP adresais.

Split-horizon DNS — kai tas pats domenas grąžina skirtingus atsakymus priklausomai nuo to, kas klausia. Vidiniame tinkle: db.example.com → 10.0.0.5 (vidinis IP). Iš išorės — NXDOMAIN, tarsi tokio domeno neegzistuoja. Naudojama norint paslėpti vidinę infrastruktūrą nuo išorinio pasaulio: iš išorės matomi tik viešieji servisai, vidiniai — nematomi. Įgyvendinama per bind views arba atskirą vidinį DNS serverį su savomis zonomis.

KAIP TEISINGAI SUKONFIGŪRUOTI DNS

TTL — pirmas dalykas, apie kurį galvojama paskiausiai. Paprasta taisyklė: stabiliems įrašams laikykite 3600. Likus 48 valandoms iki bet kokių pakeitimų — sumažinkite iki 300. Baigus keitimus — grąžinkite. Tai vienintelis būdas greitai perjungti srautą be keliavalančio laukimo.

Du nameserveriai — minimumas, ne tikslas. Vienas NS — vienas gedimo taškas. Registratoriai reikalauja mažiausiai dviejų, tačiau geriau daugiau, skirtinguose tinkluose ir geografiniuose regionuose. Cloudflare duoda du NS nemokamai — tačiau dėl anycast jie aptarnaujami iš 300+ taškų visame pasaulyje, kas patikimiau nei keturi įprasti NS ant atskirų VPS.

2FA pas registratorių — ne parinktis. Domeno užgrobimas per sukompromituotą registratoriaus paskyrą nutinka reguliariai. 2FA sustabdo daugumą tokių atvejų. Jei jūsų registratorius nepalaiko 2FA — keiskite registratorių.

CAA įrašas — viena eilutė, uždaranti visą atakų klasę. Pavyzdys:

example.com. CAA 0 issue "letsencrypt.org"

Dabar tik Let’s Encrypt gali išduoti sertifikatą jūsų domenui. Bet kuris kitas CA atsisakys — net jei kažkas įrodys domeno kontrolę kitais metodais.

SPF, DKIM, DMARC — privaloma trejybė jei naudojate el. paštą. SPF nurodo, iš kurių serverių leidžiama siųsti. DKIM pasirašo laiškus kriptografiškai. DMARC nurodo, ką daryti su laiškais, kurie nepraėjo patikrinimo — atmesti, karantinuoti arba tiesiog užregistruoti. Be viso šito jūsų laiškai patenka į šlamštą, o užpuolikai gali siųsti sukčiavimo laiškus jūsų domeno vardu.

PTR įrašą sukonfigūruokite jei naudojate savo pašto serverį. Patikrinkite:

dig -x JŪSŲ_IP +short

Turi grąžinti jūsų pašto serverio vardą. Konfigūruojama prieglobos tiekėjo valdymo skydelyje, ne pas registratorių.

DNS įrašų monitoringas — tai, ką visi pamiršta. Serverio monitoringas sukonfigūruotas. SSL sertifikato monitoringas sukonfigūruotas. Tačiau jei domeno A įrašas staiga pasikeitė — niekas nesužinos, kol naudotojai nepradės skųstis. UptimeRobot, Zabbix arba bet koks specializuotas DNS monitorius tai išsprendžia per penkias minutes.

Registry lock — apsauga nuo neteisėto domeno perkėlimo pas kitą registratorių. Be jos pakanka gauti prieigą prie paskyros — ir domeną galima perkelti per kelias valandas. Registry lock reikalauja rankinio bet kokio perkėlimo patvirtinimo per atskirą kanalą. Prieinamas pas daugumą stambių registratorių, dažnai nemokamai. Produkciniam domenams — privalomas.

GREITAS AUDITAS: PATIKRINKITE DABAR

Atidarykite terminalą ir paleiskite savo domeną per šiuos patikrinimus:

# Dabartiniai DNS įrašai
dig example.com A
dig example.com MX
dig example.com NS
dig example.com CAA
dig example.com TXT

# Atvirkštinis DNS pašto serveriui
dig -x JŪSŲ_IP +short

# DNSSEC patikrinimas
dig example.com +dnssec

# Atviras resolveris — neturėtų atsakyti
dig @JŪSŲ_IP example.com

# Atviras zone transfer — neturėtų grąžinti įrašų
dig @ns1.example.com example.com AXFR

# Pakeitimų sklidimas pasaulyje
# dnschecker.org arba whatsmydns.net

Kas turėtų būti:
— A įrašas nurodo į teisingą IP
— TTL protingas (ne 86400 pagal nutylėjimą)
— Mažiausiai du NS iš skirtingų tinklų
— CAA įrašas yra
— MX sukonfigūruotas, PTR atitinka pašto serverio vardą
— SPF, DKIM, DMARC TXT įrašuose
— DNSSEC įjungtas
— 2FA aktyvus pas registratorių
— Registry lock įjungtas
— Zone transfer uždarytas išoriniams IP
— Nėra atviro resolverio
— Visi CNAME įrašai nurodo į veikiančius resursus
— DNS įrašų monitoringas sukonfigūruotas

IŠVADA

DNS atlieka vieną užduotį: atvesti naudotoją prie jūsų serverio. Jei DNS sugedęs — nesvarbu, koks geras serveris. Niekas jo nepasiekia.

Tačiau DNS — viena labiausiai neįvertinamų infrastruktūros dalių. Sukonfigūruojama paleidžiant, iškart pamirštama. O ji tuo metu tyliai tampa gedimo tašku, atakos vektoriumi ir paros delsų šaltiniu migracijų metu.

Viena valanda auditui. TTL, NS, CAA, SPF/DKIM/DMARC, registratoriaus 2FA, įrašų monitoringas. Tai nesudėtinga. Tai tiesiog retai daroma — iki pirmosios avarijos.