Две локације, једна приватна DNS зона: чији су записи?

Додате хост на зеленој локацији, он се разрешава за зелене кориснике, а жута канцеларија и даље добија NXDOMAIN. То није квар VPN-а ни покварен резолвер; то је празнина у власништву унутар приватне зоне. Две независно уређиване листе записа не постају једна зона само зато што локације могу да стигну једна до друге. Решење је план објављивања, а не још једно правило заштитног зида.

Симптом именује власника који недостаје

Свака локација вероватно има локално преписивање, Pi-hole запис или dnsmasq линију коју је неко додао када је име било потребно. Зелени запис постоји само на зеленом резолверу, па клијент на жутој локацији пита свој резолвер и добија истинит "нема таквог имена". Застарео одговор изгледа другачије: хост се преселио, једна локација је ажурирала своју копију, а друга и даље враћа стару адресу.

Ниједан образац се дуго не решава брисањем кеша. Кеш прослеђујућег резолвера је копија одговора који је некада примио, а не ауторитет који објављује нова имена, па кеш који данас ради не говори ништа о сутрашњем хосту. BIND документација описује примарну, секундарну, рекурзивну и прослеђујућу улогу одвојено управо због овога.

Дакле, питање дизајна је уско и може се одговорити: ко сме да створи запис и како тај запис стиже до сваког резолвера који мора да одговори за њега?

Опција А: једна ауторитативна зона са секундарним серверима

Покрените примарни сервер за internal.example.com и пустите подржане секундарне сервере да преузму зону на свакој локацији. Рекурзивни резолвер сваке локације пита свој локални секундарни сервер, па одговори долазе из ауторитативног извора, а не из кеша, и промена направљена једном се преноси уместо да се поново куца.

Такав распоред тражи изричите одлуке које је лако одложити и скупо прескочити. Ко сме да уређује зону? Којим серверима је дозвољено да је преносе и преко којих адреса? Шта клијенти треба да виде док је тунел између локација неисправан? Секундарни сервер наставља да одговара из своје последње копије, што је обично жељено понашање, али то мора да буде изречен избор, а не изненађење током прекида.

Ограничите преносе зоне на познате секундарне сервере по адреси и користите потписе трансакција тамо где их имплементација подржава. Отворен пренос је копија вашег интерног именског простора за свакога ко може да дође до порта.

Цена је координација: један пут уређивања, један преглед промена и заједничко разумевање ко је дежуран када је запис погрешан.

Опција Б: поддомен за сваку локацију

Делегирајте green.internal.example.com зеленој локацији и yellow.internal.example.com жутој. Свака локација постаје ауторитативна за своја имена, а родитељска зона носи само записе делегације. Надметање око једне датотеке нестаје, и локални тим може да дода хост без чекања на централну промену.

Делегација мора да постоји у родитељској зони, са NS записима који показују на ауторитативне сервере локације. Условно прослеђивање за поддомен је ваљана алтернатива када пуна делегација није практична, али то је подешавање резолвера, а не објављена чињеница, па је сваком резолверу потребно исто правило.

Цена се помера уместо да нестане: родитељској зони и даље треба власник, а стварање нове локације је сада промена на два места уместо на једном.

Нека сваки резолвер следи избор

Дајте клијентима одобрени резолвер и домен претраге кроз њихову подржану конфигурацију и уверите се да резолвер има дозвољену VPN руту до било ког удаљеног DNS сервера који мора да пита. Апликацијама су такође потребне руте до приватних адреса које ти одговори враћају, јер исправно име без путање и даље је прекинута веза.

Ако Pi-hole пружа локално разрешавање, запишите које записе поседује и које упите прослеђује. Две независно уређиване Pi-hole листе се и даље не репликују. У Pi-hole v6 прилагођене dnsmasq линије се постављају опцијама на страни хоста као што су TOML, CLI или променљиве окружења и нису изложене кроз API; учитавање датотека /etc/dnsmasq.d/ је одвојена опција која је према подразумеваном искључена.

Затим тестирајте са обе стране именом које би требало да буде видљиво свуда:

$ 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 одговор вам каже да ли жути резолвер сматра себе ауторитативним, пита секундарни или само прослеђује. То су различити дизајни са различитим начинима отказа, а одговор обично показује који сте заиста применили.

Завршите са три случаја прихватања: име са сваке локације, запис промењен у року од сата и недоступна веза између локација. Дизајн који прође само први има план објављивања на папиру и локално преписивање у продукцији.