Dos llocs, una zona DNS privada: qui posseeix els registres?

Afegiu un amfitrió al lloc verd, es resol per als usuaris verds, i l'oficina groga encara rep NXDOMAIN. No és una fallada de la VPN ni un resolutor espatllat; és un buit de propietat dins de la zona privada. Dues llistes de registres editades independentment no es converteixen en una sola zona només perquè els llocs es poden abastar. La solució és un pla de publicació, no una altra regla de tallafocs.

El símptoma anomena el propietari que falta

Cada lloc probablement té una anul·lació local, una entrada de Pi-hole o una línia de dnsmasq que algú va afegir quan calia un nom. El registre verd només existeix al resolutor verd, així que un client al groc pregunta al seu propi resolutor i rep un "no hi ha aquest nom" verídic. Una resposta obsoleta es veu diferent: l'amfitrió s'ha mogut, un lloc ha actualitzat la seva còpia i l'altre encara retorna l'adreça antiga.

Cap dels dos patrons no es corregeix gaire estona amb un buidatge de memòria cau. La memòria cau d'un resolutor reenviador és una còpia d'una resposta que va rebre una vegada, no una autoritat que publiqui noms nous, així que una memòria cau que funciona avui no diu res sobre l'amfitrió de demà. La documentació de BIND descriu els papers primari, secundari, recursiu i reenviador per separat exactament per aquest motiu.

Així, la pregunta de disseny és estreta i té resposta: qui pot crear un registre i com arriba aquest registre a cada resolutor que hi ha de respondre?

Opció A: una zona autoritativa amb secundaris

Executeu un primari per a internal.example.com i deixeu que els secundaris compatibles obtinguin la zona a cada lloc. El resolutor recursiu de cada lloc consulta el seu secundari local, així que les respostes vénen d'una font autoritativa i no d'una memòria cau, i un canvi fet una vegada es transfereix en lloc de tornar-se a teclejar.

Aquest arranjament necessita decisions explícites que són fàcils d'ajornar i cares d'ometre. Qui pot editar la zona? Quins servidors poden transferir-la i per quines adreces? Què han de veure els clients mentre el túnel entre llocs està caigut? Un secundari continua responent des de la seva última còpia, que normalment és el comportament que voleu, però ha de ser una elecció declarada i no una sorpresa durant una caiguda.

Limiteu les transferències de zona als secundaris coneguts per adreça i utilitzeu signatures de transacció allà on la implementació les admeti. Una transferència oberta és una còpia del vostre espai de noms intern per a qualsevol que pugui arribar al port.

El cost és la coordinació: un sol camí d'edició, una sola revisió de canvis i una comprensió compartida de qui està de guàrdia quan un registre és incorrecte.

Opció B: un subdomini per lloc

Delegueu green.internal.example.com al lloc verd i yellow.internal.example.com al lloc groc. Cada lloc es converteix en autoritatiu per als seus noms, i la zona pare només porta els registres de delegació. La disputa per un sol fitxer desapareix, i un equip local pot afegir un amfitrió sense esperar un canvi central.

La delegació ha d'existir a la zona pare, amb registres NS que apuntin als servidors autoritatius del lloc. Un reenviament condicional per al subdomini és una alternativa vàlida quan una delegació completa no és pràctica, però és una configuració del resolutor i no un fet publicat, així que cada resolutor necessita la mateixa regla.

El cost es mou en lloc de desaparèixer: la zona pare encara necessita un propietari, i crear un lloc nou ara és un canvi en dos llocs en lloc d'un.

Feu que cada resolutor segueixi l'elecció

Doneu als clients el resolutor aprovat i el domini de cerca a través de la seva configuració compatible, i assegureu-vos que el resolutor tingui una ruta VPN permesa cap a qualsevol servidor DNS remot que hagi de consultar. Les aplicacions també necessiten rutes cap a les adreces privades que retornen aquestes respostes, perquè un nom correcte sense camí continua sent una connexió trencada.

Si Pi-hole proporciona resolució local, anoteu quins registres posseeix i quines consultes reenvia. Dues llistes de Pi-hole editades independentment encara no es repliquen. A Pi-hole v6, les línies personalitzades de dnsmasq es defineixen amb opcions del costat de l'amfitrió com TOML, CLI o variables d'entorn i no s'exposen per l'API; carregar fitxers de /etc/dnsmasq.d/ és una opció separada que està desactivada per defecte.

Després proveu des de tots dos costats amb un nom que hauria de ser visible a tot arreu:

$ 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

La resposta SOA us diu si el resolutor groc creu que és autoritatiu, si consulta un secundari o si només reenvia. Són dissenys diferents amb maneres de fallar diferents, i la resposta normalment identifica quin heu desplegat realment.

Acabeu amb tres casos d'acceptació: un nom de cada lloc, un registre canviat dins de l'hora i l'enllaç entre llocs no disponible. Un disseny que només passa el primer té un pla de publicació sobre el paper i una anul·lació local en producció.