Per què una zona privada de Route 53 retorna NXDOMAIN per a noms públics

Les zones privades de Route 53 substitueixen la resposta d’un nom en lloc de fusionar-se amb el registre públic, i això sorprèn la gent en el pitjor moment. Afegiu un registre intern per a api.example.net en una zona privada per a example.net, associeu-la a una VPC i tots els altres noms sota aquest pare ara responen només des de la zona privada. Un client que ahir podia arribar a www.example.net avui rep una resposta negativa. El recorregut següent comença en aquesta consulta fallida i va cap a fora fins a la zona que la va respondre.

Comenceu per la consulta, no per la consola

Reproduïu la fallada al client que la va reportar i anoteu el nom exacte i el tipus de registre. Un nom que falla per a A encara es pot resoldre per a AAAA, i un navegador que reintenta un nom en memòria cau amaga quin dels dos s’ha trencat. Executeu la consulta dues vegades: una a través del resolutor que el client fa servir realment i una amb traçat que el salti.

dig +short api.example.net
dig www.example.net +noall +comments +authority
resolvectl query www.example.net

La segona ordre és la important. La seva línia d’estat i la secció d’autoritat anomenen la zona que va produir la resposta, de manera que podeu distingir una resposta negativa de la zona privada d’un temps d’espera, un port bloquejat o un resolutor que mai va rebre la consulta. resolvectl mostra quin servidor superior s’ha preguntat, que sovint no és el resolutor que vau suposar que la VPN havia enviat.

Si la consulta traçada retorna l’adreça pública i la normal no, el registre públic està intacte i respon la vista privada. Aquesta única comparació decideix quina meitat de la resta d’aquesta pàgina us és aplicable.

Mireu quina zona ha respost

Una resposta que porta NXDOMAIN amb el SOA de la zona privada a la secció d’autoritat és una resposta definitiva d’aquesta zona, no un error de cerca. Route 53 Resolver va triar la zona allotjada privada perquè el nom coincidia, després no va trobar cap registre del tipus sol·licitat, i el comportament documentat és retornar la resposta negativa en lloc de reenviar la pregunta al DNS públic.

La selecció segueix l’especificitat. Amb diversos espais de noms privats superposats, guanya la zona coincident més específica, i un pare privat més ampli no té una segona oportunitat per a un nom que la zona filla seleccionada no té. Les regles de reenviament hi afegeixen una altra capa, ja que una regla de resolutor específica d’un domini pot guanyar l’associació de la zona allotjada privada. Enumerau les associacions i les regles abans de concloure que una zona és buida.

aws route53 list-hosted-zones-by-name --dns-name example.net.
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLEID --query "ResourceRecordSets[?Type=='A'].[Name,ResourceRecords[0].Value]"

Totes dues ordres necessiten credencials del compte que posseeix la zona, i la segona necessita l’identificador de zona de la primera. Substituïu-lo pel vostre; l’espai reservat de dalt no és real a posta.

Per què guanya la zona privada

L’associació és el que fa visible la zona per a una VPC, i el resolutor dins d’aquesta VPC és el que l’aplica. Una zona privada que no està associada a la VPC d’on arriba el trànsit del client no té cap efecte, mentre que una associació amb la VPC equivocada produeix una resposta privada per a la població equivocada. Reviseu la llista d’associacions abans d’editar registres, perquè una zona pot ser correcta i tot i així invisible.

Els espais de noms superposats són la segona font de confusió. Una zona privada per a example.net i una zona privada per a api.example.net coincideixen totes dues amb una consulta d’API, i respon la més específica. Això és útil quan voleu un espai de noms intern estret i perillós quan a la zona estreta li falta un registre que la més àmplia té. Les consideracions sobre zones allotjades privades a la documentació de Route 53 descriuen tant el comportament de caiguda com la precedència de les regles, i val la pena llegir-les abans d’afegir una segona zona superposada.

Res d’això no canvia la zona pública. Els resolutors públics continuen responent correctament els registres públics, i per això la fallada sembla un problema del client per a tothom fora de la VPC.

Trieu l’espai de noms abans d’afegir registres

Si només una família nova de serveis interns necessita noms privats, doneu-li un subdomini privat dedicat i deixeu el pare públic tranquil. Un nom com internal.example.net no pot ocultar www.example.net, i el radi d’impacte d’un registre que falta es limita als noms que vau inventar per a aquest propòsit. El cost és que els URL i els certificats existents poden no coincidir amb el nom nou.

Quan els usuaris públics i privats han de mantenir el mateix nom d’amfitrió, el DNS de vista dividida és el disseny admès i requereix que manteniu els registres en cada vista explícitament. Una zona privada àmplia amb un sol registre no conserva les dependències públiques sota aquesta zona; les substitueix per una zona que té un registre.

Feu un inventari dels noms que una aplicació crida realment abans de dirigir una població de clients a la vista privada. Els amfitrions d’inici de sessió, els d’actius estàtics, les destinacions de redirecció i els punts finals d’API són els primers a trencar-se, i normalment estan repartits entre els registres de diversos equips.

Seguiu el camí del resolutor i després la ruta

Un portàtil només veu la vista privada si les seves consultes arriben al resolutor que té l’associació. Editar un fitxer hosts al servidor VPN no publica res als clients connectats, i un client configurat amb un resolutor públic continuarà rebent respostes públiques mentre el túnel estigui aixecat. Confirmeu l’adreça del resolutor que ha rebut el client i repetiu la consulta des del client, no des del servidor.

Un cop el nom es resol, proveu el camí fins a l’adreça retornada com a pas a part, per exemple amb ip route get contra l’adreça que la consulta va retornar. Una resposta privada correcta sense ruta fins a l’adreça és un problema d’encaminament, i una resposta de registre absent és un problema de vista de DNS; tractar-les com un sol tema produeix correccions que no es mantenen. Deixeu les comprovacions del nom d’amfitrió TLS i del certificat sense canvis, perquè una adreça privada canvia on va la connexió i res sobre quin certificat és vàlid.

Acabeu anotant a la nota de canvi la zona, l’associació, el resolutor i els noms que heu verificat. Així la propera persona que afegeixi un registre sabrà quin espai de noms és autoritatiu per a aquesta població de clients.