Hvorfor en privat Route 53-sone returnerer NXDOMAIN for offentlige navn

Private Route 53-soner erstatter svaret for et navn i stedet for å slå det sammen med den offentlige posten, og det overrasker folk på det verst tenkelige tidspunktet. Legg til én intern post for api.example.net i en privat sone for example.net, knytt den til en VPC, og alle andre navn under den forelderen besvares nå bare fra den private sonen. En klient som i går kunne nå www.example.net får i dag et negativt svar. Gjennomgangen nedenfor starter ved den mislykkede spørringen og arbeider utover til sonen som svarte på den.

Start ved spørringen, ikke ved konsollen

Reproduser feilen på klienten som rapporterte den, og noter det nøyaktige navnet og posttypen. Et navn som feiler for A kan fortsatt slås opp for AAAA, og en nettleser som prøver et bufrede navn på nytt, skjuler hvilken av dem som er ødelagt. Kjør spørringen to ganger: én gang gjennom resolveren klienten faktisk bruker, og én gang med sporing som omgår den.

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

Den andre kommandoen er den viktige. Statuslinjen og autoritetsdelen navngir sonen som produserte svaret, slik at du kan skille et negativt svar fra den private sonen fra en tidsavbrudd, en blokkert port eller en resolver som aldri mottok spørringen. resolvectl viser hvilken oppstrøms server som ble spurt, og det er ofte ikke resolveren du antok at VPN-en sendte.

Hvis den sporede spørringen returnerer den offentlige adressen mens den vanlige ikke gjør det, er den offentlige posten intakt og den private visningen svarer. Den ene sammenligningen avgjør hvilken halvdel av resten av denne siden som gjelder for deg.

Les hvilken sone som svarte

Et svar som bærer NXDOMAIN med SOA-en til den private sonen i autoritetsdelen, er et endelig svar fra den sonen, ikke et mislykket oppslag. Route 53 Resolver valgte den private vertede sonen fordi navnet samsvarte, fant deretter ingen post av den forespurte typen, og den dokumenterte atferden er å returnere det negative svaret i stedet for å videresende spørsmålet til offentlig DNS.

Valget følger spesifisitet. Med flere overlappende private navnerom vinner den mest spesifikke samsvarende sonen, og en bredere privat forelder får ikke en ny sjanse for et navn som den valgte underordnede sonen ikke har. Videresendingsregler legger til et ekstra lag, fordi en domenespesifikk Resolver-regel kan slå tilknytningen til den private vertede sonen. List opp tilknytningene og reglene før du konkluderer med at en sone er tom.

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]"

Begge kommandoene krever legitimasjon for kontoen som eier sonen, og den andre trenger sone-ID-en fra den første. Erstatt den med din egen; plassholderen ovenfor er med vilje ikke ekte.

Hvorfor den private sonen vinner

Det er tilknytningen som gjør sonen synlig for en VPC, og resolveren i den VPC-en er det som anvender den. En privat sone som ikke er knyttet til VPC-en trafikken til klienten kommer fra, har ingen effekt i det hele tatt, mens en tilknytning til feil VPC gir et privat svar til feil populasjon. Kontroller tilknytningslisten før du redigerer poster, fordi en sone kan være riktig og likevel usynlig.

Overlappende navnerom er den andre kilden til forvirring. En privat sone for example.net og en privat sone for api.example.net samsvarer begge med en API-spørring, og den mest spesifikke svarer. Det er nyttig når du vil ha et smalt internt navnerom, og farlig når den smale sonen mangler en post som den bredere har. Vurderingene for private vertede soner i Route 53-dokumentasjonen beskriver både gjennomfallsatferden og regelforrangen, og de er verdt å lese før du legger til en andre overlappende sone.

Ingenting av dette endrer den offentlige sonen. Offentlige resolvere svarer fortsatt korrekt på de offentlige postene, og derfor ser feilen ut som et klientproblem for alle utenfor VPC-en.

Velg navnerommet før du legger til poster

Hvis bare en ny familie av interne tjenester trenger private navn, gi den et eget privat underdomene og la den offentlige forelderen være. Et navn som internal.example.net kan ikke skygge for www.example.net, og slagradiusen for en manglende post er begrenset til navnene du fant opp for formålet. Prisen er at eksisterende URL-er og sertifikater kanskje ikke samsvarer med det nye navnet.

Når offentlige og private brukere må beholde samme vertsnavn, er DNS med delt visning det støttede designet, og det krever at du vedlikeholder postene i hver visning eksplisitt. En bred privat sone med én post i seg bevarer ikke de offentlige avhengighetene under sonen; den erstatter dem med en sone som har én post.

Kartlegg navnene en applikasjon faktisk kaller, før du peker en klientpopulasjon mot den private visningen. Innloggingsverter, verter for statiske ressurser, omdirigeringsmål og API-endepunkter er de som ryker først, og de er vanligvis spredt over postene til flere team.

Følg resolverstien, deretter ruten

En bærbar PC ser bare den private visningen hvis spørringene når resolveren som har tilknytningen. Redigering av en hosts-fil på VPN-serveren publiserer ingenting til tilkoblede klienter, og en klient konfigurert med en offentlig resolver vil fortsatt få offentlige svar mens tunnelen er oppe. Bekreft resolveradressen klienten mottok, og gjenta deretter spørringen fra klienten i stedet for fra serveren.

Når navnet er slått opp, test ruten til den returnerte adressen som et eget trinn, for eksempel med ip route get mot adressen spørringen returnerte. Et korrekt privat svar uten rute til adressen er et ruteproblem, og et svar om en manglende post er et DNS-visningsproblem; å behandle dem som ett problem gir rettelser som ikke holder. La TLS-vertsnavnet og sertifikatkontrollene til tjenesten være uendret, fordi en privat adresse endrer hvor tilkoblingen går og ingenting om hvilket sertifikat som er gyldig.

Avslutt med å notere sonen, tilknytningen, resolveren og navnene du verifiserte i endringsnotatet. Da vet neste person som legger til en post hvilket navnerom som er autoritativt for den klientpopulasjonen.