Два обекта, една частна DNS зона: кой притежава записите?

Добавяте хост в зеления обект, той се резолвва за зелените потребители, а жълтият офис все още получава NXDOMAIN. Това не е повреда на VPN и не е счупен резолвер; това е празнина в собствеността в частната зона. Два независимо редактирани списъка със записи не стават една зона само защото обектите могат да се достигат. Решението е план за публикуване, а не още едно правило за защитна стена.

Симптомът посочва липсващия собственик

Вероятно всеки обект има локално заместване, запис в Pi-hole или ред в dnsmasq, добавен от някого, когато е трябвало име. Зеленият запис съществува само на зеления резолвер, затова клиент в жълтия пита своя резолвер и получава вярното "няма такова име". Остарелият отговор изглежда различно: хостът се е преместил, единият обект е обновил копието си, а другият все още връща стария адрес.

Нито един от двата модела не се оправя за дълго с изчистване на кеша. Кешът на препращащ резолвер е копие на отговор, който някога е получил, а не авторитет, който публикува нови имена, затова кеш, който работи днес, не казва нищо за утрешния хост. Документацията на BIND описва ролите първичен, вторичен, рекурсивен и препращащ поотделно точно поради тази причина.

Значи въпросът за дизайна е тесен и подлежи на отговор: кой може да създава запис и как този запис достига до всеки резолвер, който трябва да отговори за него?

Вариант A: една авторитетна зона с вторични сървъри

Стартирайте първичен сървър за internal.example.com и оставете поддържаните вторични да получават зоната във всеки обект. Рекурсивният резолвер на всеки обект пита местния вторичен, така че отговорите идват от авторитетен източник, а не от кеш, и промяна, направена веднъж, се прехвърля, вместо да се въвежда отново.

Тази подредба изисква изрични решения, които лесно се отлагат и скъпо се пропускат. Кой може да редактира зоната? Кои сървъри имат право да я прехвърлят и през кои адреси? Какво трябва да виждат клиентите, докато тунелът между обектите е спрян? Вторичният продължава да отговаря от последното си копие, което обикновено е желаното поведение, но трябва да е обявен избор, а не изненада по време на прекъсване.

Ограничете прехвърлянията на зоната до известните вторични по адрес и използвайте подписи на транзакции, където реализацията ги поддържа. Откритото прехвърляне е копие на вашето вътрешно пространство от имена за всеки, който може да достигне порта.

Цената е координация: един път за редактиране, един преглед на промени и споделено разбиране кой е на разположение, когато запис е грешен.

Вариант B: поддомейн за всеки обект

Делегирайте 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 ви казва дали жълтият резолвер смята, че е авторитетен, дали пита вторичен или само препраща. Това са различни дизайни с различни режими на отказ и отговорът обикновено показва кой от тях всъщност сте внедрили.

Завършете с три случая за приемане: име от всеки обект, запис, променен в рамките на часа, и недостъпна връзка между обектите. Дизайн, който минава само първия, има план за публикуване на хартия и локално заместване в продукция.