DNS serveriai yra viena iš tų infrastruktūros dalių, kurias paprastai pastebime tik tada, kai kažkas neveikia. Tačiau gerai sukonfigūruotas ir optimizuotas DNS gali žymiai pagerinti tinklo našumą, saugumą ir patikimumą. Šiame straipsnyje pasidalinsiu praktiškais patarimais, kaip tinkamai nustatyti DNS serverius ir išspausti iš jų maksimalų našumą.
Kodėl DNS konfigūracija yra svarbesnė nei galvojate
Daugelis administratorių tiesiog nustato Google DNS (8.8.8.8) ar Cloudflare (1.1.1.1) ir mano, kad darbas atliktas. Realybė kiek sudėtingesnė. DNS užklausos sudaro nemažą dalį tinklo trafiko, o kiekviena papildoma milisekundė DNS atsakyme reiškia lėtesnį puslapių įkėlimą, programų veikimą ir bendrai blogesnę vartotojų patirtį.
Pavyzdžiui, jei jūsų DNS serveris atsako per 100ms vietoj 10ms, o vidutinis vartotojas per dieną atlieka 500 DNS užklausų, tai per metus susidaro apie 45 sekundžių papildomo laukimo laiko. Padauginkite tai iš vartotojų skaičiaus ir gausite įspūdingą skaičių. Be to, DNS yra kritinė saugumo grandis – per jį galima blokuoti kenkėjiškas svetaines, apsisaugoti nuo phishing atakų ir kontroliuoti tinklo prieigą.
Pasirinkimas tarp viešų ir privačių DNS serverių
Viešieji DNS serveriai (Google, Cloudflare, Quad9) yra patrauklus variantas dėl savo paprastumo ir patikimumo. Jie veikia iš daugelio geografinių lokacijų, turi puikų uptime ir dažniausiai būna greiti. Tačiau yra keletas aspektų, kuriuos verta apsvarstyti.
Pirma, privatumas. Naudodami viešus DNS, jūs perduodate informaciją apie visas savo DNS užklausas trečiajai šaliai. Taip, daugelis teigia, kad nefiksuoja logų, bet ar tikrai norite rizikuoti su verslo duomenimis? Antra, vidinio tinklo vardai. Jei turite vidinę infrastruktūrą su privačiais domenų vardais, viešieji DNS serveriai jų neišspręs.
Savo DNS serverio paleidimas nėra toks sudėtingas, kaip atrodo. BIND, PowerDNS ar Unbound yra brandūs ir gerai dokumentuoti sprendimai. Galite paleisti juos virtualioje mašinoje ar konteineryje, o konfigūracija paprastam scenarijui užtrunka gal valandą ar dvi. Hibridinis variantas – savo DNS serveris, kuris perduoda užklausas viešiems serveriams (forwarding) – dažnai yra auksinis viduriukas.
Caching strategijos ir TTL valdymas
DNS kešavimas yra viena iš svarbiausių optimizavimo priemonių. Kiekvienas DNS serveris turėtų kešuoti atsakymus, kad nereikėtų kaskart kreiptis į autoritatyvinius serverius. Bet čia slypi keletas niuansų.
TTL (Time To Live) reikšmės nustato, kiek ilgai įrašas bus laikomas keše. Mažos TTL reikšmės (pvz., 60 sekundžių) reiškia, kad pakeitimai bus matomi greičiau, bet generuoja daugiau užklausų. Didelės reikšmės (pvz., 86400 sekundžių arba 24 valandos) sumažina apkrovą, bet pakeitimai sklinda lėčiau.
Praktiškai, daugumai įrašų tinka TTL apie 3600-7200 sekundžių (1-2 valandos). Jei planuojate atlikti pakeitimus, iš anksto sumažinkite TTL iki 300-600 sekundžių, palaukite, kol senas įrašas išnyks iš kešų, tada atlikite pakeitimą ir vėliau vėl padidinkite TTL.
Keš dydis taip pat svarbus. Jei jūsų DNS serveris aptarnauja 1000 vartotojų, kurie lanko maždaug 10000 unikalių domenų per dieną, keš turėtų būti pakankamai didelis, kad sutalpintų dažniausiai naudojamus įrašus. BIND parametras max-cache-size ar Unbound msg-cache-size leidžia tai kontroliuoti. Pradėkite nuo 256-512 MB ir stebėkite statistiką.
Saugumo aspektai ir DNSSEC
DNS protokolas iš prigimties nėra saugus – atsakymai nėra pasirašyti, todėl galimi įvairūs atakų scenarijai: cache poisoning, man-in-the-middle, DNS spoofing. DNSSEC (DNS Security Extensions) sprendžia šias problemas pridėdamas kriptografinius parašus prie DNS įrašų.
DNSSEC įjungimas nėra trivialus procesas, bet jis verta pastangų, ypač jei valdote kritinę infrastruktūrą. Jums reikės sugeneruoti raktų poras (ZSK ir KSK), pasirašyti zoną ir įkelti DS įrašus į parent zoną. Skamba bauginančiai, bet šiuolaikiniai DNS serveriai turi automatizavimo įrankius.
Pavyzdžiui, BIND su dnssec-policy direktyva gali automatiškai valdyti raktus ir pasirašyti zonas. PowerDNS turi pdnsutil įrankį, kuris supaprastina procesą. Svarbu ne tik įjungti DNSSEC, bet ir nustatyti automatinį raktų rotavimą – ZSK raktai turėtų būti keičiami kas 1-3 mėnesius, KSK – kas metai ar dvejus.
Kitas svarbus saugumo aspektas – rate limiting. DNS serveriai dažnai naudojami DDoS atakoms, ypač amplification atakoms. Įjunkite rate limiting, kad apribotumėte užklausų skaičių iš vieno IP per laiko vienetą. BIND naudoja rate-limit direktyvą, Unbound – ratelimit parametrą.
Query logging ir monitoringas
Negalite optimizuoti to, ko nematote. DNS užklausų logavimas ir monitoringas yra būtini norint suprasti, kaip jūsų DNS serveris naudojamas ir kur yra problemos.
Tačiau būkite atsargūs su logavimu – DNS serveris gali generuoti milžinišką kiekį logų. Viso trafiko logavimas gamyboje dažnai nėra praktiška nei dėl vietos, nei dėl našumo. Geriau naudokite selektyvų logavimą ar statistikos rinkimą.
BIND gali siųsti statistiką per statistics-channels, kurią galima eksportuoti į Prometheus ar kitą monitoringo sistemą. Unbound turi unbound-control stats komandą. Stebėkite tokius metriką kaip: užklausų per sekundę, keš hit ratio, vidutinis atsakymo laikas, SERVFAIL atsakymų skaičius.
Jei pastebite didelį SERVFAIL ar NXDOMAIN atsakymų skaičių, tai gali reikšti problemas su upstream serveriais ar neteisingą konfigūraciją. Žemas keš hit ratio rodo, kad TTL reikšmės per mažos arba keš dydis nepakankamas. Didelis atsakymo laikas gali signalizuoti tinklo problemas ar perkrautus upstream serverius.
Geografinis paskirstymas ir anycast
Jei jūsų infrastruktūra išsidėsčiusi keliose geografinėse lokacijose, verta pagalvoti apie DNS serverių paskirstymą. Vartotojas Vilniuje neturėtų kreiptis į DNS serverį Niujorke – latency bus per didelis.
Paprasčiausias variantas – kiekviename regione turėti lokalų DNS serverį ir konfigūruoti DHCP taip, kad vartotojai gautų artimiausio serverio adresą. Sudėtingesnis, bet elegantiškas sprendimas – anycast. Tai kai tas pats IP adresas skelbiamas iš kelių lokacijų, o tinklo maršrutizavimas automatiškai nukreipia užklausas į artimiausią serverį.
Anycast DNS reikalauja BGP konfigūravimo ir bent minimalaus tinklo inžinerijos supratimo, bet rezultatas verta pastangų. Cloudflare ir Google savo DNS serverius veikia būtent anycast principu – todėl 1.1.1.1 ir 8.8.8.8 yra greiti iš bet kurios pasaulio vietos.
Jei anycast per sudėtingas, galite naudoti GeoDNS – tai kai autoritatyvinis DNS serveris grąžina skirtingus atsakymus priklausomai nuo užklausos šaltinio geografinės lokacijos. PowerDNS turi GeoIP backend’ą, o BIND gali naudoti GeoIP2 modulį.
Rekursiniai vs autoritatyvūs serveriai
Svarbu suprasti skirtumą tarp šių dviejų DNS serverių tipų ir kodėl jie neturėtų būti maišomi viename serveryje.
Rekursinis DNS serveris priima užklausas iš klientų ir atlieka visą reikiamą darbą, kad gautų atsakymą – kreipiasi į root serverius, TLD serverius, autoritatyvinius serverius. Jis kešuoja atsakymus ir aptarnauja daug klientų. Autoritatyvinis DNS serveris tiesiog atsako į užklausas apie domenus, už kuriuos jis atsakingas – jis neieško informacijos kitur ir nekešuoja.
Kodėl nereikėtų jų maišyti? Saugumo ir našumo sumetimais. Rekursinis serveris turėtų būti prieinamas tik jūsų tinklo klientams (kitaip tapsite open resolver ir būsite naudojami atakoms). Autoritatyvinis serveris turi būti viešai prieinamas, bet neturėtų atlikti rekursijos. Jei tas pats serveris daro abu darbus, konfigūracija tampa sudėtingesnė ir pavojingesnė.
BIND leidžia konfigūruoti abi funkcijas viename serveryje, bet geriau naudoti atskirus egzempliorius. Galite naudoti Unbound rekursijai ir PowerDNS autoritatyviam DNS – tai skirtingi įrankiai skirtingoms užduotims, optimizuoti savo funkcijoms.
Kai viskas susidėlioja į vietą
DNS konfigūravimas ir optimizavimas nėra vienkartinis darbas – tai nuolatinis procesas. Pradėkite nuo paprastos konfigūracijos: lokalus rekursinis serveris su kešavimu ir forwarding į patikimus upstream serverius. Įjunkite bazinį monitoringą ir stebėkite metriką kelias savaites.
Kai suprasite savo trafiko profilį, galėsite pradėti optimizuoti. Gal pastebėsite, kad tam tikri domenai užklausami labai dažnai – galite padidinti jų TTL. Gal pamatysite, kad tam tikru paros metu apkrova išauga – galite pridėti papildomą serverį ar padidinti keš dydį.
DNSSEC įjunkite tada, kai jau jaučiatės patogiai su bazine konfigūracija. Rate limiting ir kitos saugumo priemonės turėtų būti įjungtos nuo pat pradžių, bet jų parametrus galėsite derinti stebėdami realų naudojimą.
Nepamirškite dokumentuoti savo konfigūraciją ir pakeitimus. DNS problemos dažnai pasireiškia ne iš karto, o po kelių dienų ar savaičių, kai TTL baigiasi ir seni įrašai išnyksta iš kešų. Turėdami gerą dokumentaciją ir monitoringą, galėsite greitai identifikuoti ir išspręsti problemas.
Ir paskutinis patarimas – testuokite pakeitimus. Turite staging aplinką? Puiku, išbandykite ten. Neturite? Bent jau naudokite named-checkconf ar unbound-checkconf prieš perkraudami produkcinį serverį. DNS klaidos gali padaryti nepasiekiamą visą jūsų infrastruktūrą, todėl geriau būti atsargiems.