Dvije lokacije, jedna privatna DNS zona: kome pripadaju zapisi?

Dodate host na zelenoj lokaciji, on se razrješava za zelene korisnike, a žuta kancelarija i dalje dobija NXDOMAIN. To nije kvar VPN-a ni pokvaren resolver; to je praznina u vlasništvu unutar privatne zone. Dvije nezavisno uređivane liste zapisa ne postaju jedna zona samo zato što lokacije mogu doći jedna do druge. Rješenje je plan objavljivanja, a ne još jedno pravilo vatrozida.

Simptom imenuje vlasnika koji nedostaje

Svaka lokacija vjerovatno ima lokalno preklapanje, Pi-hole unos ili dnsmasq liniju koju je neko dodao kada je ime bilo potrebno. Zeleni zapis postoji samo na zelenom resolveru, pa klijent na žutoj pita svoj resolver i dobija istinito "nema tog imena". Zastario odgovor izgleda drugačije: host se preselio, jedna lokacija je ažurirala svoju kopiju, a druga i dalje vraća staru adresu.

Nijedan se obrazac ne rješava dugo brisanjem keša. Keš prosljeđujućeg resolvera je kopija odgovora koji je nekada primio, a ne autoritet koji objavljuje nova imena, pa keš koji danas radi ne govori ništa o sutrašnjem hostu. BIND dokumentacija opisuje primarne, sekundarne, rekurzivne i prosljeđujuće uloge odvojeno upravo zbog toga.

Dakle, dizajnersko pitanje je usko i odgovorivo: ko smije stvoriti zapis i kako taj zapis stiže do svakog resolvera koji mora odgovoriti za njega?

Opcija A: jedna autoritativna zona sa sekundarima

Pokrenite primarni za internal.example.com i pustite podržane sekundare da preuzmu zonu na svakoj lokaciji. Rekurzivni resolver svake lokacije pita svoj lokalni sekundar, pa odgovori dolaze iz autoritativnog izvora, a ne iz keša, i promjena napravljena jednom se prenosi umjesto da se ponovo kuca.

Takav raspored traži izričite odluke koje je lako odgoditi i skupo preskočiti. Ko smije uređivati zonu? Kojim serverima je dozvoljeno da je prenose i preko kojih adresa? Šta klijenti treba da vide dok je tunel između lokacija neispravan? Sekundar nastavlja odgovarati iz svoje posljednje kopije, što je obično ponašanje koje želite, ali to mora biti izrečen izbor, a ne iznenađenje tokom prekida.

Ograničite prijenose zone na poznate sekundare po adresi i koristite potpise transakcija gdje ih implementacija podržava. Otvoren prijenos je kopija vašeg internog imenskog prostora za svakoga ko može doći do porta.

Cijena je koordinacija: jedan put uređivanja, jedan pregled promjena i zajedničko razumijevanje ko je dežuran kada je zapis pogrešan.

Opcija B: poddomena za svaku lokaciju

Delegirajte green.internal.example.com zelenoj lokaciji i yellow.internal.example.com žutoj. Svaka lokacija postaje autoritativna za svoja imena, a roditeljska zona nosi samo zapise delegacije. Nadmetanje oko jednog fajla nestaje, a lokalni tim može dodati host bez čekanja na centralnu promjenu.

Delegacija mora postojati u roditelju, s NS zapisima koji pokazuju na autoritativne servere lokacije. Uslovno prosljeđivanje za poddomenu valjana je alternativa kada je puna delegacija nepraktična, ali to je postavka resolvera, a ne objavljena činjenica, pa svaki resolver treba isto pravilo.

Cijena se pomjera umjesto da nesta: roditeljskoj zoni i dalje treba vlasnik, a stvaranje nove lokacije sada je promjena na dva mjesta umjesto na jednom.

Neka svaki resolver slijedi izbor

Dajte klijentima odobreni resolver i domenu pretrage kroz njihovu podržanu konfiguraciju i pobrinite se da resolver ima dozvoljenu VPN rutu do bilo kojeg udaljenog DNS servera koji mora pitati. Aplikacijama su također potrebne rute do privatnih adresa koje ti odgovori vraćaju, jer ispravno ime bez putanje i dalje je prekinuta veza.

Ako Pi-hole pruža lokalno razrješavanje, zapišite koje zapise posjeduje i koje upite prosljeđuje. Dvije nezavisno uređivane Pi-hole liste i dalje se ne repliciraju. U Pi-hole v6 prilagođene dnsmasq linije postavljaju se opcijama na strani hosta kao što su TOML, CLI ili varijable okruženja i nisu izložene kroz API; učitavanje datoteka /etc/dnsmasq.d/ odvojena je opcija koja je prema zadanim postavkama isključena.

Zatim testirajte s obje strane imenom koje bi trebalo biti vidljivo svuda:

$ 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 odgovor vam kaže vjeruje li žuti resolver da je autoritativan, pita li sekundar ili samo prosljeđuje. To su različiti dizajni s različitim načinima otkaza, a odgovor obično pokazuje koji ste zaista primijenili.

Završite s tri slučaja prihvatanja: ime sa svake lokacije, zapis promijenjen u roku od sata i nedostupna veza između lokacija. Dizajn koji prođe samo prvi ima plan objavljivanja na papiru i lokalno preklapanje u produkciji.