Dous sitios, unha zona DNS privada: quen posúe os rexistros?

Engade un host no sitio verde, resólvese para os usuarios verdes, e a oficina amarela segue recibindo NXDOMAIN. Non é un fallo de VPN nin un resolvedor roto; é un oco de propiedade dentro da zona privada. Dúas listas de rexistros editadas por separado non se converten nunha soa zona só porque os sitios poden alcanzarse. A solución é un plan de publicación, non outra regra de cortalumes.

O síntoma nomea o propietario que falta

Cada sitio probablemente ten unha anulación local, unha entrada de Pi-hole ou unha liña de dnsmasq que alguén engadiu cando facía falta un nome. O rexistro verde só existe no resolvedor verde, así que un cliente no amarelo pregunta ao seu propio resolvedor e recibe un "non existe ese nome" veraz. Unha resposta obsoleta vese distinta: o host moveuse, un sitio actualizou a súa copia e o outro segue devolvendo o enderezo antigo.

Ningún dos dous patróns se corrixe durante moito tempo baleirando a caché. A caché dun resolvedor reenviador é unha copia dunha resposta que recibiu unha vez, non unha autoridade que publique nomes novos, así que unha caché que funciona hoxe non di nada sobre o host de mañá. A documentación de BIND describe os papeis primario, secundario, recursivo e reenviador por separado exactamente por este motivo.

Así que a pregunta de deseño é estreita e ten resposta: quen pode crear un rexistro, e como chega ese rexistro a cada resolvedor que debe responder por el?

Opción A: unha zona autoritativa con secundarios

Execute un primario para internal.example.com e deixe que os secundarios compatibles obteñan a zona en cada sitio. O resolvedor recursivo de cada sitio consulta o seu secundario local, así que as respostas veñen dunha fonte autoritativa e non dunha caché, e un cambio feito unha vez transfírese en lugar de reescribirse.

Ese arranxo necesita decisións explícitas que son fáciles de pospoñer e caras de omitir. Quen pode editar a zona? Que servidores poden transferila e por que enderezos? Que deben ver os clientes mentres o túnel entre sitios está caído? Un secundario segue respondendo desde a súa última copia, que adoita ser o comportamento desexado, pero debe ser unha elección declarada e non unha sorpresa durante unha caída.

Limite as transferencias de zona aos secundarios coñecidos por enderezo e use sinaturas de transacción onde a implementación as admita. Unha transferencia aberta é unha copia do seu espazo de nomes interno para calquera que alcance o porto.

O custo é a coordinación: unha soa ruta de edición, unha soa revisión de cambios e un entendemento compartido de quen está de garda cando un rexistro é incorrecto.

Opción B: un subdominio por sitio

Delegue green.internal.example.com ao sitio verde e yellow.internal.example.com ao amarelo. Cada sitio pasa a ser autoritativo para os seus propios nomes e a zona pai só leva os rexistros de delegación. A disputa por un só ficheiro desaparece e un equipo local pode engadir un host sen esperar un cambio central.

A delegación debe existir na zona pai, con rexistros NS que apunten aos servidores autoritativos do sitio. Un reenvío condicional para o subdominio é unha alternativa válida cando unha delegación completa non é práctica, pero é unha configuración do resolvedor e non un feito publicado, así que cada resolvedor necesita a mesma regra.

O custo móvese en lugar de desaparecer: a zona pai segue necesitando un propietario, e crear un sitio novo agora é un cambio en dous lugares en vez de un.

Faga que cada resolvedor siga a elección

Dea aos clientes o resolvedor aprobado e o dominio de busca mediante a súa configuración compatible, e asegúrese de que o resolvedor teña unha ruta VPN permitida cara a calquera servidor DNS remoto ao que deba consultar. As aplicacións tamén necesitan rutas cara aos enderezos privados que devolven esas respostas, porque un nome correcto sen ruta segue sendo unha conexión rota.

Se Pi-hole proporciona resolución local, anote que rexistros posúe e que consultas reenvía. Dúas listas de Pi-hole editadas por separado seguen sen replicarse. En Pi-hole v6, as liñas personalizadas de dnsmasq defínense mediante opcións do lado do host como TOML, CLI ou variables de contorno e non se expoñen pola API; cargar ficheiros de /etc/dnsmasq.d/ é unha opción á parte que está desactivada por defecto.

Despois probe desde ambos os lados cun nome que debería ser visible en todas partes:

$ 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

A resposta SOA dille se o resolvedor amarelo cre que é autoritativo, se consulta un secundario ou se só reenvía. Son deseños distintos con modos de fallo distintos, e a resposta adoita identificar cal despregou realmente.

Remate con tres casos de aceptación: un nome de cada sitio, un rexistro cambiado dentro da hora e a ligazón entre sitios non dispoñible. Un deseño que só pasa o primeiro ten un plan de publicación no papel e unha anulación local en produción.