Nimeämispalvelin laitteillesi, ei avoin vahvistin.

Valitse rooli

Rekursiivinen resolveri, kuten Unbound, ja suodatuskäyttöliittymä, kuten AdGuard Home, ratkaisevat toisiinsa liittyviä mutta erillisiä ongelmia. Päätä, tekeekö palvelu rekursion itse vai välittääkö se ylävirtaan, ja ymmärrä, kuka osapuoli silloin näkee kyselyt.

Pidä se yksityisenä

Rajoittamatonta julkista resolveria voidaan käyttää väärin heijastushyökkäyksiin. Sido se yksityiseen verkkoon tai salli vain valtuutetut lähteet, mukaan lukien IPv6. Jos käytät salattua DNS, todenna tai muuten rajoita pääsyä asianmukaisesti sen sijaan, että olettaisit HTTPS:n tekevän siitä yksityisen.

Aseta lokituskäytäntö

DNS-kyselyt voivat paljastaa arkaluontoista selaus- ja sovellustoimintaa. Poista tarpeeton säilytys käytöstä, suojaa säilytettävät tietueet ja selitä laajuus käyttäjille. Salattu siirto suojaa reitin; se ei estä resolveria itseään näkemästä kyselyitä.

Testaa useampaa kuin yhtä nimeä

Varmista DNSSEC-käyttäytyminen, kun se on käytössä, IPv4 ja IPv6 -tulokset, suodatuksen poikkeukset ja palautuminen, kun ylävirta epäonnistuu. Pidä turvallinen tapa korjata pääsy ilman, että olet yksinomaan korjattavan resolverin varassa.

Todista, etteivät ulkopuoliset voi kysellä sitä

Sido resolveri aiottuun rajapintaan, määritä sallitut asiakasalueet ja rajoita palomuuria. Vahvista kokoonpano ennen uudelleenkäynnistystä. Kysy sitä valtuutetulta asiakkaalta ja toista sitten luotetun verkon ulkopuolelta: pyyntö tulee hylätä tai aikakatkaista. Tarkista IPv6 erikseen. Resolveri, joka hyväksyy mielivaltaisia internet-kyselyitä, voi muuttua väärinkäytön lähteeksi.

• Aja kokoonpanon validoija ennen muutosten soveltamista
• Testaa sallittu asiakas ja estetty asiakas
• Pidä yksityiskohtaiset kyselydiagnostiikat väliaikaisina

unbound-checkconf

Virallinen dokumentaatio: Määrittämätön käyttöoikeuksien hallintakokoonpano

Pidä salatut DNS -väitteet täsmällisinä

DNS-over-HTTPS tai DNS-over-TLS salaa tietyn siirtopolun. Ratkaisin vastaanottaa silti kyselyn, ja välittävä ratkaisin voi siirtää sen toiselle operaattorille. Tarkista ylävirran valinta ja säilytys. Jos paljastat salatun ratkaisimen päätepisteen, tee sen käyttöoikeuskäytännöstä yhtä harkittu kuin tavallisesta DNS-portista.

Valitse resolveriketju ennen portin avaamista

Hyödyllinen yksityinen rakenne on VPN-asiakasohjelma, joka kysyy AdGuard Homea, ja AdGuard välittää eteenpäin Unboundille loopbackissa. Unbound suorittaa tällöin rekursion; AdGuard lisää suodatuksen ja hallintakäyttöliittymän. Vaihtoehtoisesti käytä vain Unboundia pienemmän pinon saamiseksi. Anna jokaiselle kuuntelijalle erillinen osoite/portti ja piirrä välityssuunta: Unboundin lähettäminen takaisin AdGuardille muodostaa silmukan. Päätä, mitkä yksityiset asiakkaat saavat käyttää palvelua, ennen kuin julkaiset mitään.

• Pidä julkinen saapuva TCP ja UDP 53 suljettuna, ellei käytössä ole erityistä valtuutettujen asiakkaiden käytäntöä.
• Anna suodatusliittymälle ja DNS-kuuntelijalle erilliset käyttöoikeussäännöt.
• Tarkista portin omistajuus ennen asennusta; olemassa oleva järjestelmän nimipalvelin voi jo varata aiottu osoite.

Virallinen dokumentaatio: AdGuard Home -asennus

Loopback-Unboundin lähtökohta

Järjestelmässä, johon Unbound on jo asennettu, seuraava katkelma havainnollistaa taustapalvelua, joka on tavoitettavissa vain isännältä. Integroi se jakelun kokoonpanoon sen sijaan, että korvaisit paketin asetukset tai luotettujen ankkurien hallinnan. Korkea portti antaa toisen DNS-käyttöliittymän käyttää porttia 53. Validoi koko voimassa oleva tiedosto ja lataa se sitten uudelleen asennetun palvelunhallinnan kautta. Etäasiakas tarvitsee erikseen hallitun tunnelin tai käyttöliittymän; tämä katkelma ei tarkoituksella luo julkista resolveria.

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-checkconf

Virallinen dokumentaatio: Unbound-määritysviite

Suorita hyväksymistarkistuslista kahdesta verkosta

Kysy ensin taustajärjestelmältä paikallisesti ja sitten tavalliselta asiakaspolulta. Tarkista tavalliset A/AAAA-tietueet, tarkoituksella olematon nimi ja DNSSEC-validointi dokumentoidulla testiverkkotunnuksella. Toista sallitun aliverkon ulkopuoliselta koneelta: sen ei pidä saada rekursiota. Tarkista, käyttääkö selain omaa salattua resolveriaan ja ohittaako se määritetyn laitteen DNS. Pidä muutoksen aikana saatavilla väliaikainen riippumaton resolver, jotta DNS -virhe ei poista hallintareittiäsi.

• Paikallinen diagnostiikka: dig @127.0.0.1 -p 5335 example.org A
• Tarkista sekä UDP- että TCP-tavoitettavuus sekä IPv6-kuuntelijat.
• Vahvista suodatuksen poikkeukset ja tallenna vain todella tarvittavat diagnostiikkatiedot.

Diagnosoi aikakatkaisut, silmukat ja validointivirheet

Frontendin aikakatkaisu toimivan paikallisen backendin kanssa viittaa frontendin osoitteeseen, palomuuriin tai edelleenohjauksen kohteeseen. Toistuvat itseohjautuvat kyselyt viittaavat silmukkaan. Laajat DNSSEC-virheet voivat liittyä väärään järjestelmäaikaan tai luottamusankkurien ylläpitoon; korjaa syy sen sijaan, että jättäisit validoinnin pois päältä. Jos vain suuret vastaukset epäonnistuvat, tutki TCP-varamekanismia ja verkkopolkua. Pidä kyselyloki väliaikaisena ja testaa uudelleenkäynnistys ja kokoonpanon palautus ennen kuin teet resolverista kaikkien laitteiden riippuvuuden.