Piliin ang role
Ang recursive resolver tulad ng Unbound at filtering interface tulad ng AdGuard Home ay sumasagot sa magkaugnay ngunit magkaibang problema. Magpasya kung ang serbisyo mismo ay nagre-recurse o nagpapasa sa upstream at unawain kung sinong partido ang makakakita ng mga query.
Panatilihing pribado
Ang walang restriksiyong pampublikong resolver ay maaaring abusuhin para sa reflection attacks. I-bind sa isang pribadong network o payagan lamang ang mga awtorisadong source, kabilang ang IPv6. Kung gumagamit ng naka-encrypt na DNS, mag-authenticate o limitahan ang access nang naaayon sa halip na ipagpalagay na ginagawa itong pribado ng HTTPS.
Magtakda ng logging policy
Ang DNS query ay maaaring magbunyag ng sensitibong browsing at application activity. I-disable ang hindi kinakailangang retention, protektahan ang mga record na itinatago at ipaliwanag ang saklaw sa mga user. Pinoprotektahan ng encrypted transport ang isang path; hindi nito pinipigilan ang resolver mismo na makita ang query.
Subukan ang higit sa isang pangalan
I-verify ang DNSSEC behaviour kung naka-enable, ang IPv4 at IPv6 na resulta, filtering exceptions at recovery kapag nabigo ang upstream. Panatilihin ang secure na paraan para ayusin ang access nang hindi umaasa lamang sa resolver na inaayos mo.
Patunayan na hindi ito maaaring i-query ng mga estranghero
I-bind ang resolver sa nilalayong interface, tukuyin ang pinapayagang client ranges at limitahan ang firewall. I-validate ang configuration bago mag-restart. I-query ito mula sa awtorisadong client, pagkatapos ulitin mula sa labas ng trusted network: dapat tanggihan o mag-time out ang request na iyon. Suriin nang hiwalay ang IPv6. Ang resolver na tumatanggap ng arbitrary internet queries ay maaaring maging pinagmumulan ng abuse.
- Patakbuhin ang configuration validator bago ilapat ang mga pagbabago
- Subukan ang isang pinapayagang client at isang tinatanggihang client
- Panatilihing pansamantala ang verbose query diagnostics
unbound-checkconfOpisyal na dokumentasyon: Walang hadlang na configuration ng access-control
Panatilihing tumpak ang mga naka-encrypt na claim ng DNS
Ang DNS-over-HTTPS o DNS-over-TLS ay nag-e-encrypt ng partikular na transport path. Natatanggap pa rin ng resolver ang query, at maaaring ipasa ito ng forwarding resolver sa ibang operator. Suriin ang pagpili ng upstream at retention. Kung maglalantad ka ng encrypted resolver endpoint, gawing kasing-sinadya ng ordinaryong DNS port ang access policy nito.
Piliin ang resolver chain bago magbukas ng port
Ang kapaki-pakinabang na private design ay isang VPN client na nag-query sa AdGuard Home, kung saan ang AdGuard ay nagpapasa sa Unbound sa loopback. Pagkatapos ay nagsasagawa ng recursion ang Unbound; nagdadagdag ang AdGuard ng filtering at management interface. Bilang alternatibo, gamitin lamang ang Unbound para sa mas maliit na stack. Bigyan ang bawat listener ng natatanging address/port at iguhit ang direksyon ng forwarding: ang pagpapadala pabalik ng Unbound sa AdGuard ay lumilikha ng loop. Magpasya kung aling mga private client ang maaaring gumamit ng serbisyo bago mag-publish ng anuman.
- Panatilihing sarado ang pampublikong inbound TCP at UDP 53 maliban kung may partikular na patakaran para sa awtorisadong kliyente.
- Bigyan ng magkahiwalay na access rules ang filtering interface at ang DNS listener.
- Suriin ang pagmamay-ari ng port bago ang pag-install; maaaring naka-bind na ang isang umiiral na system resolver sa nilalayong address.
Opisyal na dokumentasyon: Setup ng AdGuard Home
Isang panimulang punto ng loopback Unbound
Sa isang system na may naka-install nang Unbound, ang sumusunod na fragment ay naglalarawan ng backend na maaabot lamang sa host. Isama ito sa configuration ng distribution sa halip na i-overwrite ang mga setting ng package o pamamahala ng trust-anchor. Ang high port ay nagpapahintulot sa isa pang DNS frontend na gumamit ng port 53. I-validate ang kumpletong epektibong file, pagkatapos ay i-reload sa pamamagitan ng naka-install na service manager. Ang isang remote client ay nangangailangan ng hiwalay na kontroladong tunnel o frontend; ang fragment na ito ay sadyang hindi gumagawa ng pampublikong resolver.
server:
interface: 127.0.0.1
port: 5335
access-control: 127.0.0.0/8 allow
access-control: 0.0.0.0/0 refuse
access-control: ::0/0 refuse
# Validate the complete installed configuration:
unbound-checkconfOpisyal na dokumentasyon: Sanggunian sa configuration ng Unbound
Magpatakbo ng acceptance checklist mula sa dalawang network
I-query muna ang backend nang lokal, pagkatapos ang normal na client path. Suriin ang mga ordinaryong A/AAAA record, isang sadyang hindi umiiral na pangalan at DNSSEC validation gamit ang isang dokumentadong test domain. Ulitin mula sa isang makina sa labas ng pinapayagang subnet: hindi ito dapat makatanggap ng recursion. Suriin kung gumagamit ang browser ng sarili nitong encrypted resolver at nilalampasan ang naka-configure na device DNS. Panatilihing available ang isang pansamantalang independiyenteng resolver habang nagbabago upang ang isang DNS na pagkakamali ay hindi mag-alis ng iyong ruta ng administrasyon.
- Lokal na diagnostic: dig @127.0.0.1 -p 5335 example.org A
- Suriin ang UDP at TCP reachability, pati na ang IPv6 listeners.
- Kumpirmahin ang mga exception sa filtering at itala lamang ang mga diagnostic na aktwal na kailangan.
I-diagnose ang mga timeout, loop at pagkabigo sa validation
Ang timeout sa frontend na may gumaganang lokal na backend ay nagpapahiwatig ng address ng frontend, firewall o forwarding target. Ang paulit-ulit na self-directed na query ay nagpapahiwatig ng loop. Ang malawakang pagkabigo ng DNSSEC ay maaaring may kinalaman sa maling oras ng system o maintenance ng trust-anchor; ayusin ang sanhi sa halip na iwanang naka-disable ang validation. Kung malalaking reply lang ang nabibigo, siyasatin ang TCP fallback at ang network path. Panatilihing pansamantala ang query logging, at subukan ang restart at configuration restore bago gawing dependency ng bawat device ang resolver.