Divas vietas, viena privāta DNS zona: kam pieder ieraksti?

Jūs pievienojat saimnieku zaļajā vietā, tas tiek atrisināts zaļajiem lietotājiem, un dzeltenā birojs joprojām saņem NXDOMAIN. Tā nav VPN kļūme un nav salauzts resolvers; tā ir īpašumtiesību plaisa privātajā zonā. Divi neatkarīgi rediģēti ierakstu saraksti nekļūst par vienu zonu tikai tāpēc, ka vietas var sasniegt viena otru. Risinājums ir publikācijas plāns, nevis vēl viens ugunsmūra noteikums.

Simptoms nosauc trūkstošo īpašnieku

Katrai vietai, iespējams, ir lokāls pārraksts, Pi-hole ieraksts vai dnsmasq rinda, ko kāds pievienoja, kad bija vajadzīgs nosaukums. Zaļais ieraksts pastāv tikai zaļajā resolverī, tāpēc klients dzeltenajā vietā jautā savam resolverim un saņem patiesu "tāda nosaukuma nav". Novecojusi atbilde izskatās citādi: saimnieks ir pārvietots, viena vieta atjaunināja savu kopiju, bet otra joprojām atgriež veco adresi.

Neviens no modeļiem uz ilgu laiku netiek izlabots, iztīrot kešatmiņu. Pārsūtošā resolvera kešatmiņa ir kādreiz saņemtas atbildes kopija, nevis autoritāte, kas publicē jaunus nosaukumus, tāpēc šodien strādājoša kešatmiņa neko neizsaka par rītdienas saimnieku. BIND dokumentācija primāro, sekundāro, rekursīvo un pārsūtošo lomu apraksta atsevišķi tieši šī iemesla dēļ.

Tātad dizaina jautājums ir šaurs un atbildams: kas drīkst izveidot ierakstu, un kā šis ieraksts nonāk pie katra resolvera, kuram par to jāatbild?

A variants: viena autoritatīva zona ar sekundārajiem

Palaidiet primāro internal.example.com un ļaujiet atbalstītajiem sekundārajiem iegūt zonu katrā vietā. Katras vietas rekursīvais resolvers jautā savam lokālajam sekundārajam, tāpēc atbildes nāk no autoritatīva avota, nevis kešatmiņas, un vienreiz veikta izmaiņa tiek pārnesta, nevis pārrakstīta.

Šāds izkārtojums prasa skaidrus lēmumus, kurus ir viegli atlikt un dārgi izlaist. Kas drīkst rediģēt zonu? Kuriem serveriem ir atļauts to pārnest, un pa kādām adresēm? Kas klientiem jāredz, kamēr tunelis starp vietām ir izslēgts? Sekundārais turpina atbildēt no savas pēdējās kopijas, kas parasti ir vēlamā uzvedība, taču tam jābūt paziņotai izvēlei, nevis pārsteigumam pārtraukuma laikā.

Ierobežojiet zonas pārsūtīšanu ar zināmajiem sekundārajiem pēc adreses un izmantojiet darījumu parakstus tur, kur ieviešana tos atbalsta. Atvērta pārsūtīšana ir jūsu iekšējās nosaukumvietas kopija ikvienam, kas sasniedz portu.

Izmaksas ir koordinācija: viens rediģēšanas ceļš, viena izmaiņu pārskatīšana un kopīga izpratne par to, kas ir dežūrā, kad ieraksts ir nepareizs.

B variants: apakšdomēns katrai vietai

Deleģējiet green.internal.example.com zaļajai vietai un yellow.internal.example.com dzeltenajai. Katra vieta kļūst autoritatīva par saviem nosaukumiem, un vecākzona nes tikai deleģēšanas ierakstus. Strīds par vienu failu pazūd, un vietējā komanda var pievienot saimnieku, negaidot centrālu izmaiņu.

Deleģēšanai jāpastāv vecākzonā, ar NS ierakstiem, kas norāda uz vietas autoritatīvajiem serveriem. Nosacīta pārsūtīšana apakšdomēnam ir derīga alternatīva, kad pilna deleģēšana nav praktiska, taču tā ir resolvera iestatījums, nevis publicēts fakts, tāpēc katram resolverim vajadzīgs tas pats noteikums.

Izmaksas pārvietojas, nevis pazūd: vecākzonai joprojām vajadzīgs īpašnieks, un jaunas vietas izveide tagad ir izmaiņa divās vietās, nevis vienā.

Lai katrs resolvers ievēro izvēli

Dodiet klientiem apstiprināto resolveri un meklēšanas domēnu caur viņu atbalstīto konfigurāciju un pārliecinieties, ka resolverim ir atļauts VPN maršruts uz jebkuru attālinātu DNS serveri, kas tam jāvaicā. Lietojumprogrammām arī vajadzīgi maršruti uz privātajām adresēm, ko atgriež šīs atbildes, jo pareizs nosaukums bez ceļa joprojām ir pārtraukts savienojums.

Ja Pi-hole nodrošina lokālu atrisināšanu, pierakstiet, kuri ieraksti tam pieder un kurus vaicājumus tas pārsūta. Divi neatkarīgi rediģēti Pi-hole saraksti joprojām netiek replicēti. Pi-hole v6 pielāgotās dnsmasq rindas tiek iestatītas ar saimnieka puses opcijām, piemēram, TOML, CLI vai vides mainīgajiem, un netiek atklātas caur API; /etc/dnsmasq.d/ failu ielāde ir atsevišķa opcija, kas pēc noklusējuma ir izslēgta.

Pēc tam pārbaudiet no abām pusēm ar nosaukumu, kam jābūt redzamam visur:

$ 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 atbilde pasaka, vai dzeltenais resolvers uzskata sevi par autoritatīvu, vaicā sekundāro vai tikai pārsūta. Tie ir dažādi dizaini ar dažādiem kļūmju režīmiem, un atbilde parasti norāda, kuru jūs faktiski ieviesāt.

Pabeidziet ar trim pieņemšanas gadījumiem: viens nosaukums no katras vietas, viena stundas laikā mainīts ieraksts un savienojums starp vietām nav pieejams. Dizains, kas iztur tikai pirmo, uz papīra ir publikācijas plāns un ražošanā lokāls pārraksts.