Kaksi toimipistettä, yksi yksityinen DNS-vyöhyke: kuka omistaa tietueet?

Lisäät isännän vihreään toimipisteeseen, se ratkeaa vihreille käyttäjille, ja keltainen toimisto saa edelleen NXDOMAINin. Kyse ei ole VPN-virheestä eikä rikkinäisestä resolverista; kyse on omistajuusaukosta yksityisellä vyöhykkeellä. Kaksi erikseen muokattua tietueluetteloa ei muutu yhdeksi vyöhykkeeksi vain siksi, että toimipisteet tavoittavat toisensa. Ratkaisu on julkaisusuunnitelma, ei uusi palomuurisääntö.

Oire nimeää puuttuvan omistajan

Jokaisessa toimipisteessä on todennäköisesti paikallinen ohitus, Pi-hole-merkintä tai dnsmasq-rivi, jonka joku lisäsi, kun nimeä tarvittiin. Vihreä tietue on vain vihreässä resolverissa, joten keltaisessa oleva asiakas kysyy omalta resolveriltaan ja saa totuudenmukaisen "ei sellaista nimeä". Vanhentunut vastaus näyttää erilaiselta: isäntä siirtyi, yksi toimipiste päivitti kopionsa ja toinen palauttaa yhä vanhan osoitteen.

Kumpikaan kuvio ei korjaannu pitkäksi aikaa välimuistin tyhjennyksellä. Edelleenlähettävän resolverin välimuisti on kopio vastauksesta, jonka se joskus sai, ei valtuus, joka julkaisee uusia nimiä, joten tänään toimiva välimuisti ei kerro mitään huomisen isännästä. BINDin dokumentaatio kuvaa ensisijaisen, toissijaisen, rekursiivisen ja edelleenlähettävän roolin erikseen juuri tästä syystä.

Suunnittelukysymys on siis kapea ja vastattavissa: kuka saa luoda tietueen, ja miten tietue saavuttaa jokaisen resolverin, jonka on vastattava siitä?

Vaihtoehto A: yksi valtuutettu vyöhyke ja toissijaiset

Aja ensisijainen palvelin kohteelle internal.example.com ja anna tuettujen toissijaisten hakea vyöhyke kussakin toimipisteessä. Kunkin toimipisteen rekursiivinen resolver kysyy paikalliselta toissijaiseltaan, joten vastaukset tulevat valtuutetusta lähteestä eikä välimuistista, ja kerran tehty muutos siirretään uudelleen kirjoittamisen sijaan.

Järjestely vaatii nimenomaisia päätöksiä, jotka on helppo lykätä ja kalliita jättää väliin. Kuka saa muokata vyöhykettä? Mitkä palvelimet saavat siirtää sen ja mitä osoitteita pitkin? Mitä asiakkaiden pitäisi nähdä, kun toimipisteiden välinen tunneli on alhaalla? Toissijainen vastaa edelleen viimeisestä kopiostaan, mikä on yleensä haluttu käyttäytyminen, mutta sen on oltava ilmoitettu valinta eikä yllätys katkon aikana.

Rajoita vyöhykkeensiirrot tunnettuihin toissijaisiin osoitteen perusteella ja käytä tapahtuma-allekirjoituksia siellä, missä toteutus tukee niitä. Avoin siirto on kopio sisäisestä nimiavaruudestasi kenelle tahansa, joka yltää porttiin.

Hinta on koordinointi: yksi muokkauspolku, yksi muutosten tarkastus ja yhteinen käsitys siitä, kuka on päivystysvuorossa, kun tietue on väärin.

Vaihtoehto B: aliverkkotunnus toimipistettä kohden

Delegoi green.internal.example.com vihreälle toimipisteelle ja yellow.internal.example.com keltaiselle. Jokaisesta toimipisteestä tulee valtuutettu omille nimilleen, ja ylävyöhyke kantaa vain delegointitietueet. Kiista yhdestä tiedostosta katoaa, ja paikallinen tiimi voi lisätä isännän odottamatta keskitettyä muutosta.

Delegoinnin on oltava ylävyöhykkeellä, NS-tietuein, jotka osoittavat toimipisteen valtuutettuihin palvelimiin. Ehdollinen edelleenlähetys aliverkkotunnukselle on pätevä vaihtoehto, kun täysi delegointi ei ole käytännöllinen, mutta se on resolverin asetus eikä julkaistu tosiasia, joten jokainen resolver tarvitsee saman säännön.

Hinta siirtyy eikä katoa: ylävyöhyke tarvitsee yhä omistajan, ja uuden toimipisteen luominen on nyt muutos kahdessa paikassa yhden sijaan.

Anna jokaisen resolverin seurata valintaa

Anna asiakkaille hyväksytty resolver ja hakutoimialueen heidän tuetun määrityksensä kautta ja varmista, että resolverilla on sallittu VPN-reitti mihin tahansa etäiseen DNS-palvelimeen, jota sen on kysyttävä. Sovellukset tarvitsevat myös reitit niihin yksityisiin osoitteisiin, jotka nämä vastaukset palauttavat, koska oikea nimi ilman reittiä on yhä katkennut yhteys.

Jos Pi-hole tarjoaa paikallisen ratkaisun, kirjoita ylös, mitkä tietueet se omistaa ja mitkä kyselyt se välittää eteenpäin. Kaksi erikseen muokattua Pi-hole-luetteloa ei silti replikoidu. Pi-hole v6:ssa mukautetut dnsmasq-rivit asetetaan isäntäpuolen asetuksilla, kuten TOML, CLI tai ympäristömuuttujat, eikä niitä paljasteta API:n kautta; /etc/dnsmasq.d/-tiedostojen lataaminen on erillinen asetus, joka on oletuksena pois päältä.

Testaa sitten molemmilta puolilta nimellä, jonka pitäisi näkyä kaikkialla:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

SOA-vastaus kertoo, pitääkö keltainen resolver itseään valtuutettuna, kysyykö se toissijaiselta vai vain välittääkö se eteenpäin. Ne ovat erilaisia suunnitelmia, joilla on erilaiset vikatilat, ja vastaus yleensä kertoo, minkä todella otit käyttöön.

Päätä kolmeen hyväksymistapaukseen: yksi nimi kustakin toimipisteestä, tunnin sisällä muutettu tietue ja toimipisteiden välinen linkki poissa käytöstä. Suunnitelma, joka läpäisee vain ensimmäisen, on paperilla julkaisusuunnitelma ja tuotannossa paikallinen ohitus.