Hvorfor en privat Route 53-zone returnerer NXDOMAIN for offentlige navne

Private Route 53-zoner erstatter svaret for et navn i stedet for at flette det sammen med den offentlige post, og det overrasker folk på det værst tænkelige tidspunkt. Tilføj én intern post for api.example.net i en privat zone for example.net, knyt den til en VPC, og alle andre navne under den forælder besvares nu udelukkende fra den private zone. En klient, der i går kunne nå www.example.net får i dag et negativt svar. Gennemgangen nedenfor starter ved den mislykkede forespørgsel og arbejder udad til den zone, der svarede på den.

Start ved forespørgslen, ikke ved konsollen

Genskab fejlen på den klient, der rapporterede den, og noter det præcise navn og posttypen. Et navn, der fejler for A kan stadig slå op for AAAA, og en browser, der prøver et cachelagret navn igen, skjuler hvilket af dem der er brudt. Kør forespørgslen to gange: en gang gennem den resolver, klienten faktisk bruger, og en gang med sporing, der omgår den.

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

Den anden kommando er den vigtige. Dens statuslinje og autoritetssektion angiver den zone, der producerede svaret, så du kan skelne et negativt svar fra den private zone fra en timeout, en blokeret port eller en resolver, der aldrig modtog forespørgslen. resolvectl viser, hvilken upstream der blev spurgt, og det er ofte ikke den resolver, du antog, at VPN'en sendte.

Hvis den sporede forespørgsel returnerer den offentlige adresse, mens den normale ikke gør, er den offentlige post intakt, og den private visning svarer. Den ene sammenligning afgør, hvilken halvdel af resten af denne side der gælder for dig.

Læs hvilken zone der svarede

Et svar, der bærer NXDOMAIN med den private zones SOA i autoritetssektionen, er et definitivt svar fra den zone, ikke et mislykket opslag. Route 53 Resolver valgte den private hostede zone, fordi navnet matchede, fandt derefter ingen post af den ønskede type, og den dokumenterede adfærd er at returnere det negative svar i stedet for at videresende spørgsmålet til offentlig DNS.

Valget følger specificitet. Med flere overlappende private navnerum vinder den mest specifikke matchende zone, og en bredere privat forælder får ikke en ny chance for et navn, som den valgte underzone ikke har. Videresendelsesregler lægger endnu et lag ovenpå, fordi en domænespecifik Resolver-regel kan vinde over den private hostede zones tilknytning. Opregn tilknytningerne og reglerne, før du konkluderer, at en zone 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 kommandoer kræver legitimationsoplysninger til den konto, der ejer zonen, og den anden kræver zone-id'et fra den første. Erstat det med dit eget id; pladsholderen ovenfor er med vilje ikke en rigtig en.

Hvorfor den private zone vinder

Det er tilknytningen, der gør zonen synlig for en VPC, og resolveren i den VPC anvender den. En privat zone, der ikke er knyttet til den VPC, som klientens trafik kommer fra, har slet ingen effekt, mens en tilknytning til den forkerte VPC giver et privat svar til den forkerte population. Kontroller tilknytningslisten, før du redigerer poster, fordi en zone kan være korrekt og stadig usynlig.

Overlappende navnerum er den anden kilde til forvirring. En privat zone for example.net og en privat zone for api.example.net matcher begge en API-forespørgsel, og den mest specifikke svarer. Det er nyttigt, når du vil have et snævert internt navnerum, og farligt, når den snævre zone mangler en post, som den bredere har. Overvejelserne om private hostede zoner i Route 53-dokumentationen beskriver både gennemfaldsadfærden og regelfortrinnet, og de er værd at læse, før du tilføjer en anden overlappende zone.

Intet af dette ændrer den offentlige zone. Offentlige resolvere svarer stadig korrekt på de offentlige poster, og derfor ser fejlen ud som et klientproblem for alle uden for VPC'en.

Vælg navnerummet, før du tilføjer poster

Hvis kun en ny familie af interne tjenester har brug for private navne, giv den et dedikeret privat underdomæne og lad den offentlige forælder være. Et navn som internal.example.net kan ikke skygge for www.example.net, og slagradiusen for en manglende post er begrænset til de navne, du opfandt til formålet. Prisen er, at eksisterende URL'er og certifikater muligvis ikke matcher det nye navn.

Når offentlige og private brugere skal beholde det samme værtsnavn, er DNS med delt visning det understøttede design, og det kræver, at du vedligeholder posterne i hver visning eksplicit. En bred privat zone med én post i sig bevarer ikke de offentlige afhængigheder under zonen; den erstatter dem med en zone, der har én post.

Kortlæg de navne, en applikation faktisk kalder, før du peger en klientpopulation mod den private visning. Login-værter, værter for statiske aktiver, omdirigeringsmål og API-endepunkter er dem, der først brækker, og de er normalt spredt over flere holds poster.

Følg resolverstien, derefter ruten

En laptop ser kun den private visning, hvis dens forespørgsler når den resolver, der har tilknytningen. Redigering af en hosts-fil på VPN-serveren offentliggør intet til tilsluttede klienter, og en klient konfigureret med en offentlig resolver vil fortsat få offentlige svar, mens tunnelen er oppe. Bekræft den resolveradresse, klienten modtog, og gentag derefter forespørgslen fra klienten i stedet for fra serveren.

Når navnet er slået op, skal du teste ruten til den returnerede adresse som et separat trin, for eksempel med ip route get mod den adresse, forespørgslen returnerede. Et korrekt privat svar uden en rute til adressen er et routingproblem, og et svar om en manglende post er et DNS-visningsproblem; at behandle dem som ét problem giver rettelser, der ikke holder. Lad tjenestens TLS-værtsnavn og certifikatkontroller være uændrede, fordi en privat adresse ændrer, hvor forbindelsen går hen, og intet om hvilket certifikat der er gyldigt.

Slut af med at notere zonen, tilknytningen, resolveren og de navne, du har verificeret, i ændringsnotatet. Så ved den næste person, der tilføjer en post, hvilket navnerum der er autoritativt for den klientpopulation.