Dve lokaciji, ena zasebna cona DNS: čigavi so zapisi?

Dodate gostitelja na zeleni lokaciji, ta se razreši za zelene uporabnike, rumena pisarna pa še vedno prejme NXDOMAIN. To ni okvara VPN niti pokvarjen razreševalnik; to je vrzel v lastništvu znotraj zasebne cone. Dva neodvisno urejena seznama zapisov ne postaneta ena cona samo zato, ker se lokaciji lahko dosežeta. Rešitev je načrt objavljanja, ne še eno pravilo požarnega zidu.

Simptom poimenuje manjkajočega lastnika

Vsaka lokacija ima verjetno lokalno prepisovanje, vnos v Pi-hole ali vrstico dnsmasq, ki jo je nekdo dodal, ko je bilo potrebno ime. Zeleni zapis obstaja le na zelenem razreševalniku, zato odjemalec na rumeni lokaciji vpraša svoj razreševalnik in prejme resničen "takega imena ni". Zastarel odgovor je videti drugače: gostitelj se je preselil, ena lokacija je posodobila svojo kopijo, druga pa še vedno vrača stari naslov.

Noben vzorec se dolgo ne odpravi s praznjenjem predpomnilnika. Predpomnilnik posredovalnega razreševalnika je kopija odgovora, ki ga je nekoč prejel, ne avtoriteta, ki objavlja nova imena, zato predpomnilnik, ki danes deluje, ne pove ničesar o jutrišnjem gostitelju. Dokumentacija BIND opisuje vloge primarni, sekundarni, rekurzivni in posredovalni ločeno prav zaradi tega razloga.

Vprašanje zasnove je torej ozko in odgovorljivo: kdo sme ustvariti zapis in kako ta zapis doseže vsak razreševalnik, ki mora odgovoriti zanj?

Možnost A: ena avtoritativna cona s sekundarnimi strežniki

Zaženite primarni strežnik za internal.example.com in pustite podprtim sekundarnim strežnikom, da pridobijo cono na vsaki lokaciji. Rekurzivni razreševalnik vsake lokacije vpraša svoj lokalni sekundarni strežnik, zato odgovori prihajajo iz avtoritativnega vira in ne iz predpomnilnika, sprememba, narejena enkrat, pa se prenese, namesto da bi se znova vtipkala.

Takšna ureditev zahteva izrecne odločitve, ki jih je lahko odložiti in drago izpustiti. Kdo sme urejati cono? Kateri strežniki jo smejo prenašati in po katerih naslovih? Kaj naj odjemalci vidijo, medtem ko je tunel med lokacijama nedelujoč? Sekundarni strežnik še naprej odgovarja iz svoje zadnje kopije, kar je običajno želeno vedenje, vendar mora biti izrečena izbira in ne presenečenje med izpadom.

Omejite prenose cone na znane sekundarne strežnike po naslovu in uporabite transakcijske podpise tam, kjer jih implementacija podpira. Odprt prenos je kopija vašega notranjega imenskega prostora za vsakogar, ki doseže vrata.

Cena je usklajevanje: ena pot urejanja, en pregled sprememb in skupno razumevanje, kdo je v pripravljenosti, ko je zapis napačen.

Možnost B: poddomena za vsako lokacijo

Delegirajte green.internal.example.com zeleni lokaciji in yellow.internal.example.com rumeni. Vsaka lokacija postane avtoritativna za svoja imena in nadrejena cona nosi le zapise delegiranja. Prepir o eni datoteki izgine in lokalna ekipa lahko doda gostitelja, ne da bi čakala na osrednjo spremembo.

Delegiranje mora obstajati v nadrejeni coni, z zapisi NS, ki kažejo na avtoritativne strežnike lokacije. Pogojno posredovanje za poddomeno je veljavna alternativa, kadar popolno delegiranje ni praktično, vendar je to nastavitev razreševalnika in ne objavljeno dejstvo, zato vsak razreševalnik potrebuje isto pravilo.

Cena se premakne, namesto da bi izginila: nadrejena cona še vedno potrebuje lastnika in ustvarjanje nove lokacije je zdaj sprememba na dveh mestih namesto na enem.

Naj vsak razreševalnik sledi izbiri

Odjemalcem dajte odobreni razreševalnik in iskalno domeno prek njihove podprte konfiguracije in poskrbite, da ima razreševalnik dovoljeno pot VPN do katerega koli oddaljenega strežnika DNS, ki ga mora vprašati. Tudi aplikacije potrebujejo poti do zasebnih naslovov, ki jih vračajo ti odgovori, ker je pravilno ime brez poti še vedno pretrgana povezava.

Če Pi-hole zagotavlja lokalno razreševanje, zapišite, katere zapise ima in katere poizvedbe posreduje. Dva neodvisno urejena seznama Pi-hole se še vedno ne replicirata. V Pi-hole v6 se vrstice dnsmasq po meri nastavijo z možnostmi na strani gostitelja, kot so TOML, CLI ali okoljske spremenljivke, in niso izpostavljene prek API; nalaganje datotek iz /etc/dnsmasq.d/ je ločena možnost, ki je privzeto izklopljena.

Nato preizkusite z obeh strani z imenom, ki bi moralo biti vidno povsod:

$ 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

Odgovor SOA vam pove, ali se rumeni razreševalnik ima za avtoritativnega, ali sprašuje sekundarni strežnik ali samo posreduje. To so različne zasnove z različnimi načini odpovedi in odgovor običajno pokaže, katero ste dejansko uvedli.

Končajte s tremi primeri sprejetja: ime z vsake lokacije, zapis, spremenjen v eni uri, in nedosegljiva povezava med lokacijama. Zasnova, ki prestane le prvega, ima na papirju načrt objavljanja in v proizvodnji lokalno prepisovanje.