Dy faqe, një zonë private DNS: kujt i takojnë regjistrimet?

Shtoni një host në faqen e gjelbër, ai zgjidhet për përdoruesit e gjelbër, dhe zyra e verdhë vazhdon të marrë NXDOMAIN. Ky nuk është dështim VPN dhe as zgjidhës i prishur; është një boshllëk pronësie brenda zonës private. Dy lista regjistrimesh të redaktuara në mënyrë të pavarur nuk bëhen një zonë e vetme vetëm sepse faqet mund të arrijnë njëra-tjetrën. Zgjidhja është një plan publikimi, jo një rregull tjetër firewalls.

Simptoma emërton pronarin që mungon

Çdo faqe ka me gjasë një mbivendosje lokale, një hyrje Pi-hole ose një rresht dnsmasq që dikush e shtoi kur duhej një emër. Regjistrimi i gjelbër ekziston vetëm në zgjidhësin e gjelbër, kështu që një klient në të verdhën pyet zgjidhësin e vet dhe merr një "nuk ka një emër të tillë" të vërtetë. Një përgjigje e vjetër duket ndryshe: hosti u zhvendos, një faqe përditësoi kopjen e saj dhe tjetra vazhdon të kthejë adresën e vjetër.

Asnjëri model nuk rregullohet për një kohë të gjatë me pastrimin e cache-s. Cache-i i një zgjidhësi përcjellës është një kopje e një përgjigjeje që ka marrë dikur, jo një autoritet që publikon emra të rinj, prandaj një cache që punon sot nuk thotë asgjë për hostin e nesërm. Dokumentacioni i BIND përshkruan rolet primar, sekondar, rekurziv dhe përcjellës veçmas pikërisht për këtë arsye.

Pra pyetja e projektimit është e ngushtë dhe e përgjigjshme: kush mund të krijojë një regjistrim, dhe si arrin ai regjistrim në çdo zgjidhës që duhet të përgjigjet për të?

Opsioni A: një zonë autoritare me sekondarë

Nisni një primar për internal.example.com dhe lërini sekondarët e mbështetur të marrin zonën në çdo faqe. Zgjidhësi rekurziv i secilës faqe pyet sekondarin e vet lokal, prandaj përgjigjet vijnë nga një burim autoritar dhe jo nga një cache, dhe një ndryshim i bërë një herë transferohet në vend që të rishkruhet.

Kjo marrëveshje kërkon vendime të qarta që shtyhen lehtë dhe kushtojnë shtrenjtë të anashkalohen. Kush mund të redaktojë zonën? Cilët servera lejohen ta transferojnë atë, dhe përmes cilave adresa? Çfarë duhet të shohin klientët ndërsa tuneli midis faqeve është jashtë funksionit? Një sekondar vazhdon të përgjigjet nga kopja e tij e fundit, që zakonisht është sjellja e dëshiruar, por duhet të jetë një zgjedhje e deklaruar dhe jo një surprizë gjatë një ndërprerjeje.

Kufizoni transferimet e zonës te sekondarët e njohur sipas adresës dhe përdorni nënshkrime transaksioni atje ku implementimi i mbështet. Një transferim i hapur është një kopje e hapësirës tuaj të brendshme të emrave për këdo që arrin portën.

Kostoja është koordinimi: një rrugë redaktimi, një rishikim ndryshimesh dhe një kuptim i përbashkët se kush është në detyrë kur një regjistrim është i gabuar.

Opsioni B: një nëndomain për çdo faqe

Delegoni green.internal.example.com faqes së gjelbër dhe yellow.internal.example.com asaj të verdhë. Çdo faqe bëhet autoritare për emrat e veta, dhe zona prind mban vetëm regjistrimet e delegimit. Konkurrenca për një skedar të vetëm zhduket, dhe një ekip lokal mund të shtojë një host pa pritur një ndryshim qendror.

Delegimi duhet të ekzistojë në zonën prind, me regjistrime NS që tregojnë drejt serverave autoritarë të faqes. Një përcjellje me kusht për nëndomain-in është një alternativë e vlefshme kur një delegim i plotë nuk është praktik, por është një konfigurim zgjidhësi dhe jo një fakt i publikuar, prandaj çdo zgjidhës ka nevojë për të njëjtin rregull.

Kostoja zhvendoset në vend që të zhduket: zona prind vazhdon të ketë nevojë për një pronar, dhe krijimi i një faqeje të re është tani një ndryshim në dy vende në vend të një.

Bëni çdo zgjidhës të ndjekë zgjedhjen

Jepuni klientëve zgjidhësin e miratuar dhe domenin e kërkimit përmes konfigurimit të tyre të mbështetur, dhe sigurohuni që zgjidhësi ka një rrugë VPN të lejuar drejt çdo serveri DNS të largët që duhet të pyesë. Aplikacionet gjithashtu kanë nevojë për rrugë drejt adresave private që kthejnë ato përgjigje, sepse një emër i saktë pa rrugë mbetet një lidhje e prishur.

Nëse Pi-hole ofron zgjidhje lokale, shkruani cilat regjistrime zotëron dhe cilat kërkesa përcjell. Dy lista Pi-hole të redaktuara në mënyrë të pavarur vazhdojnë të mos replikohen. Në Pi-hole v6, rreshtat e personalizuar dnsmasq vendosen përmes opsioneve në anën e hostit si TOML, CLI ose variabla mjedisi dhe nuk ekspozohen përmes API-së; ngarkimi i skedarëve të /etc/dnsmasq.d/ është një opsion i veçantë që është i fikur si parazgjedhje.

Më pas provoni nga të dyja anët me një emër që duhet të jetë i dukshëm kudo:

$ 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

Përgjigja SOA ju tregon nëse zgjidhësi i verdhë e konsideron veten autoritar, po pyet një sekondar apo thjesht po përcjell. Këto janë projektime të ndryshme me mënyra dështimi të ndryshme, dhe përgjigja zakonisht identifikon cilën keni vendosur në të vërtetë.

Përfundoni me tre raste pranimi: një emër nga secila faqe, një regjistrim i ndryshuar brenda orës dhe lidhja midis faqeve e padisponueshme. Një projektim që kalon vetëm të parin ka një plan publikimi në letër dhe një mbivendosje lokale në prodhim.