Savas DNS resolveris: kodėl reikalingas, kurį pasirinkti ir kaip per 10 minučių sukonfigūruoti Unbound.

Kiekvienąkart kai jūsų serveris atnaujina paketus, tikrina sertifikatą, jungiasi prie išorinės API arba siunčia metrikas į monitoringo sistemą — jis rezolvuoja domeną. Ir ta užklausa keliauja į 1.1.1.1 arba 8.8.8.8. Cloudflare mato kad jūsų serveris 3 nakties ėjo prie paketų saugyklos, paskui prie mokėjimų API, paskui prie grėsmių duomenų bazės. Pilnas jūsų infrastruktūros žemėlapis — be jokio įsilaužimo, tiesiog iš DNS žurnalų.

Savas resolveris tai išsprendžia. Užklausos apdorojamos lokaliai, saugomos serverio talpykloje, o į išorę keliauja tik tai ko nebuvo talpykloje — ir tada šifruota.

KODĖL SAVAS RESOLVERIS

Privatumas — akivaizdžiausia priežastis. Išorinis DNS tiekėjas mato kiekvieną domeną prie kurio jungiasi serveris. Tai ne paranoja — tai realūs duomenys kurie renkami, analizuojami ir gali nutekėti. Savas resolveris palieka tą informaciją pas jus.

Nepriklausomybė — mažiau akivaizdi bet kritičiau svarbi. 1.1.1.1 patikimas, tačiau tai svetimas serveris. 2021 metų spalį krito Facebook pačių DNS serveriai — ir viskas kas nuo jų priklausė nustojo veikti. 1.1.1.1 tą dieną veikė, tačiau rytoj gali nepasisekti būtent jūsų tiekėjui. Savas resolveris eina tiesiogiai prie root serverių ir nepriklauso nuo nieko.

Kaip tai veikia: root serveriai — tai DNS hierarchijos viršūnė. Jų yra 13 grupių, jie praktiškai visada prieinami ir žino kur ieškoti bet kurio domeno. Įprastas resolveris kaip 1.1.1.1 pats eina pas juos ir talpina atsakymus — jūs naudojatės jo talpykla. Savas resolveris daro tą patį, tik asmeniškai jums — ir nepriklauso nuo niekieno kito talpyklos.

Greitis — malonus priedas. Dažnai naudojami domenai nusėda lokalinėje talpykloje. npm registry, GitHub, Docker Hub — visa tai rezolvuojama per vienetus milisekundžių neišeinant į internetą.

Kontrolė — tai kas atveria naujas galimybes. Norite užblokuoti konkretų domeną DNS lygmeniu? Pridėti vidinius įrašus lokaliniam tinklui? Registruoti visas serverio DNS užklausas auditui? Su savu resolveriu visa tai daroma konfigūracijos faile.

Domenų blokavimas per local-zone — viena paprasčiausių ir naudingiausių galimybių. Pridėkite į konfigūraciją:

server:
    # Užblokuoti domeną — grąžinti REFUSED
    local-zone: "example.com" refuse

    # Užblokuoti reklamines tinklas
    local-zone: "doubleclick.net" refuse
    local-zone: "googlesyndication.com" refuse

    # Nukreipti į savo IP (vidiniams servisams)
    local-zone: "internal.example.com" static
    local-data: "internal.example.com A 10.0.0.5"

refuse — resolveris grąžins REFUSED, naršyklė parodys DNS klaidą. static su local-data — grąžins nurodytą IP vietoj tikrojo. Patogu vidiniams servisams kurie turėtų rezolvuotis į privatų IP.

TRYS VARIANTAI: UNBOUND, BIND, POWERDNS

Resolverio pasirinkimas priklauso nuo užduoties. Visi trys sprendžia skirtingas problemas.

Unbound — specializuotas talpyklingas resolveris. Nesistengia daryti visko iš karto: priima užklausas, ieško atsakymų pas root serverius, talpina rezultatus, tikrina DNSSEC. Sukonfigūruojamas per 10 minučių, atminties sąnaudos priklauso nuo talpyklos dydžio — su šio straipsnio konfigūracija apie 150-200 MB, veikia stabiliai metų metus be priežiūros. Jei reikalingas lokalinis resolveris serveriui ar nedideliam tinklui — tai tinkamas pasirinkimas.

Bind (named) — pramoninis standartas egzistuojantis nuo 1980-ųjų. Veikia po didesne dalimi pasaulio DNS infrastruktūros. Gali būti vienu metu ir talpyklinis resolveris ir autoritetinis serveris jūsų domenams. Palaiko GeoDNS — skirtingi atsakymai naudotojams iš skirtingų šalių. Palaiko split-horizon — skirtingi atsakymai vidiniame ir išoriniame tinkle. Galingas įrankis su atitinkama mokymosi kreive.

PowerDNS — modernusis variantas tiems kas nori valdyti DNS programiškai. Zonos saugomos MySQL arba PostgreSQL, įrašai valdomi per REST API. Galima parašyti skriptą kuris automatiškai sukuria DNS įrašus paleidžiant naują serverį. Pasirinkimas automatizuotoms sistemoms ir tiems kas nenori rankiniu būdu redaguoti tekstinių failų.

Lokaliniam resolveriui viename serveryje — Unbound. Pilnaverčiam DNS serveriui su zonomis — Bind. Dinaminiam valdymui per API — PowerDNS.

UNBOUND: DIEGIMAS IR KONFIGŪRACIJA

Diegimas — viena komanda:

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

Po diegimo Unbound klauso 127.0.0.1:53 ir yra pasiruošęs priimti užklausas. Tačiau bazinė konfigūracija reikalauja kelių pakeitimų.

Atidarykite konfigūracijos failą:

nano /etc/unbound/unbound.conf

Minimali veikianti konfigūracija:

server:
    # Klausome tik localhost
    interface: 127.0.0.1
    port: 53

    # Leidžiame užklausas tik iš localhost
    access-control: 127.0.0.1/32 allow
    access-control: 0.0.0.0/0 refuse

    # DNSSEC
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

    # Slepiame versiją ir tapatybę
    hide-version: yes
    hide-identity: yes

    # Talpykla
    cache-min-ttl: 300
    cache-max-ttl: 86400
    msg-cache-size: 50m
    rrset-cache-size: 100m

    # Našumas
    num-threads: 2
    so-reuseport: yes

    # Žurnalavimas
    verbosity: 1
    log-queries: no

Atsisiųskite DNSSEC root anchors:

unbound-anchor -a /var/lib/unbound/root.key

Patikrinkite konfigūraciją ir paleiskite:

unbound-checkconf
systemctl enable --now unbound

Patikrinimas kad veikia:

dig @127.0.0.1 cloudflare.com
dig @127.0.0.1 cloudflare.com +dnssec

Antroji užklausa su +dnssec turėtų grąžinti įrašus su ad žyma (authenticated data) — tai reiškia DNSSEC patikrinimas praėjo.

PRIJUNGIMAS PRIE SISTEMOS RESOLVERIO

Unbound veikia, tačiau serveris jo dar nenaudoja — systemd-resolved vis dar siunčia užklausas į 1.1.1.1. Reikia perjungti sistemos DNS į 127.0.0.1.

Svarbu: DNSSEC ir DoT systemd-resolved reikia išjungti. Jei paliksite įjungtus — systemd-resolved bandys pats validuoti DNSSEC ir šifruoti užklausas viršaus to ką jau daro Unbound. Dvigubas darbas, ir blogiau — konfigūracijos konfliktas. Unbound pats rūpinasi visu tuo, systemd-resolved čia yra tik perdavėjas.

# /etc/systemd/resolved.conf
[Resolve]
DNS=127.0.0.1
DNSOverTLS=no
DNSSEC=no

systemctl restart systemd-resolved
resolvectl status | grep "Current DNS Server"

Turėtų rodyti 127.0.0.1. Jei matote 1.1.1.1 arba Hetzner IP — kažkas nepavyko, patikrinkite netplan arba /etc/resolv.conf.

Patikrinimas kad rezolvavimas eina per Unbound:

resolvectl query cloudflare.com

DOT UPSTREAM: ŠIFRUOJAME IŠEINANČIAS UŽKLAUSAS

Lokalinis resolveris išsprendžia problemą serverio viduje — užklausos nekeliauja pas svetimą resolverį. Tačiau kai Unbound neranda atsakymo talpykloje, vis tiek eina prie išorinių serverių — forvarderių. Tas išeinantis srautas pagal nutylėjimą keliauja atviru tekstu per UDP 53 prievadą. Tai reiškia tiekėjas vis dar gali matyti kokius domenus rezolvuoja jūsų serveris — tiesiog ne nuolat, o tik kai talpykla neturi atsakymo.

DoT upstream šifruoja būtent šias išeinančias užklausas. Tiekėjas mato šifruotą srautą 853 prievade — tačiau nemato kokius domenus rezolvuojate.

Pridėkite į konfigūraciją:

forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 8.8.8.8@853#dns.google
    forward-addr: 9.9.9.9@853#dns.quad9.net

Paleiskite iš naujo:

systemctl restart unbound

Dabar Unbound talpina lokaliai, o užklausos kurių nėra talpykloje šifruojamos per DoT ir perduodamos sukonfigūruotiems forwarderiams — 1.1.1.1, 8.8.8.8 arba 9.9.9.9. Tiekėjas mato tik šifruotą srautą 853 prievade.

PATIKRINIMAS IR DERINIMAS

Talpyklos statistika:

unbound-control stats_noreset | grep -E "total|cache"

Kiek užklausų apdorota ir koks procentas iš talpyklos — parodys kaip efektyviai veikia resolveris.

DNSSEC testas:

# Šis domenas turėtų grąžinti SERVFAIL — jis tyčia sugadintas testams
dig @127.0.0.1 dnssec-failed.org

# Šis turėtų rezolvuotis normaliai
dig @127.0.0.1 cloudflare.com +dnssec

Jei dnssec-failed.org grąžina SERVFAIL — DNSSEC validacija veikia teisingai.

Žurnalai:

journalctl -u unbound -f

SAVAS RESOLVERIS IŠ NAMŲ KOMPIUTERIO

Unbound bazinėje konfigūracijoje klauso tik 127.0.0.1 — prieinamas išimtinai iš paties serverio. Tačiau jį galima saugiai atidaryti konkrečiam IP — pavyzdžiui jūsų namų kompiuteriui. Tada vietoj 8.8.8.8 tinklo nustatymuose įrašote savo serverio IP, ir visas DNS srautas eina per jūsų resolverį.

Sužinokite savo namų IP:

curl ifconfig.me

Atidarykite Unbound tam IP — pridėkite į konfigūraciją:

server:
    interface: 0.0.0.0
    access-control: 0.0.0.0/0 refuse
    access-control: 127.0.0.1/32 allow
    access-control: JŪSŲ_NAMŲ_IP/32 allow

Atidarykite 53 prievadą nftables tik jūsų IP — jokiu kitu būdu:

ip saddr JŪSŲ_NAMŲ_IP udp dport 53 accept
ip saddr JŪSŲ_NAMŲ_IP tcp dport 53 accept

Paleiskite Unbound iš naujo:

systemctl restart unbound

Patikrinkite iš namų kompiuterio kad resolveris atsako:

dig @JŪSŲ_SERVERIO_IP cloudflare.com

Jei atsakė — įrašykite serverio IP DNS nustatymuose tinklo adapterio nustatymuose.

Svarbu: namų IP paprastai dinaminis — keičiasi iš naujo prisijungus. Jei IP pasikeitė, resolveris nustos atsakyti. Reikės atnaujinti nftables taisyklę ir Unbound konfigūraciją. Nuolatiniam naudojimui geriau gauti statinį IP iš tiekėjo arba naudoti Dynamic DNS.

KADA REIKALINGAS BIND ARBA POWERDNS

Unbound — resolveris. Jis negali būti autoritetinis serveris jūsų domenams, nepalaiko zonų, nedaro GeoDNS.

Jei reikia talpinti savo DNS zonas, konfigūruoti split-horizon DNS, daryti GeoDNS su skirtingais atsakymais skirtingoms šalims, arba kurti pilnavertę DNS infrastruktūrą — tai Bind užduotis. Bind gali būti vienu metu ir resolveris ir autoritetinis serveris, palaiko sudėtingus ACL ir view konfigūracijas vidinių ir išorinių zonų atskyrimui.

PowerDNS renkamasi kai DNS reikia administruoti programiškai: zonos saugomos duomenų bazėje, įrašai valdomi per REST API, galima parašyti savo backend. Tai pasirinkimas automatizuotoms sistemoms ir debesijos tiekėjams.

Išsami Bind konfigūracija su praktiniais pavyzdžiais — zonos, GeoDNS, split-horizon — nagrinėjama DNS serverio konfigūravimo kurse: du pamokų su pilnu gyliu nuo bazinės konfigūracijos iki pažangių galimybių.

IŠVADA

Savas resolveris — tai ne rocket science. Unbound įdiegiamas per penkias minutes, reikalauja 150-200 MB RAM su standartine talpyklos konfigūracija, ir iškart suteikia privatumą, nepriklausomybę nuo išorinių tiekėjų ir lokalinį talpinimą.

Daugumai serverių to pakanka. Jei užduotys auga iki savo zonų talpinimo ir sudėtingo DNS srauto maršrutizavimo lygio — kitas žingsnis yra Bind.