Waarom een privé Route 53-zone NXDOMAIN geeft voor openbare namen

Privé Route 53-zones vervangen het antwoord voor een naam in plaats van het samen te voegen met het openbare record, en dat verrast mensen op het slechtste moment. Voeg één intern record toe voor api.example.net in een privézone voor example.net, koppel die aan een VPC, en elke andere naam onder dat bovenliggende domein wordt nu alleen nog vanuit de privézone beantwoord. Een client die gisteren www.example.net kon bereiken, krijgt vandaag een negatief antwoord. De uitleg hieronder begint bij die mislukte query en werkt naar buiten toe naar de zone die erop antwoordde.

Begin bij de query, niet bij de console

Reproduceer de fout op de client die hem meldde, en noteer de exacte naam en het recordtype. Een naam die faalt voor A kan nog steeds worden opgelost voor AAAA, en een browser die een gecachte naam opnieuw probeert, verbergt welke van de twee stuk is. Voer de query twee keer uit: één keer via de resolver die de client echt gebruikt, en één keer met tracing die hem omzeilt.

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

Het tweede commando is het belangrijke. De statusregel en het authority-gedeelte noemen de zone die het antwoord produceerde, zodat je een negatief antwoord uit de privézone kunt onderscheiden van een time-out, een geblokkeerde poort of een resolver die de query nooit heeft ontvangen. resolvectl laat zien welke upstream is bevraagd, en dat is vaak niet de resolver waarvan je aannam dat de VPN hem had doorgestuurd.

Als de getraceerde query het openbare adres teruggeeft en de normale niet, is het openbare record intact en antwoordt de privéweergave. Die ene vergelijking bepaalt welk deel van de rest van deze pagina op jou van toepassing is.

Lees welke zone heeft geantwoord

Een antwoord dat NXDOMAIN bevat en de SOA van de privézone in het authority-gedeelte heeft, is een definitief antwoord van die zone, geen mislukte opzoeking. Route 53 Resolver koos de privé-gehoste zone omdat de naam overeenkwam, vond daarna geen record van het gevraagde type, en het gedocumenteerde gedrag is het negatieve antwoord terug te geven in plaats van de vraag door te sturen naar openbare DNS.

De selectie volgt de specificiteit. Bij meerdere overlappende privénaamruimtes wint de meest specifieke overeenkomende zone, en een breder privé-bovenliggend domein krijgt geen tweede kans voor een naam die de gekozen subzone niet heeft. Doorstuurregels voegen nog een laag toe, omdat een domeinspecifieke Resolver-regel de koppeling van de privé-gehoste zone kan overtreffen. Noem de koppelingen en regels voordat je concludeert dat een zone leeg is.

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

Beide commando's vereisen inloggegevens voor het account dat de zone bezit, en het tweede heeft de zone-ID uit het eerste nodig. Vervang die door je eigen ID; de plaatshouder hierboven is met opzet niet echt.

Waarom de privézone wint

De koppeling is wat de zone zichtbaar maakt voor een VPC, en de resolver in die VPC past hem toe. Een privézone die niet is gekoppeld aan de VPC waar het verkeer van de client vandaan komt, heeft helemaal geen effect, terwijl een koppeling met de verkeerde VPC een privéantwoord voor de verkeerde populatie oplevert. Controleer de koppelingenlijst voordat je records bewerkt, want een zone kan correct zijn en toch onzichtbaar.

Overlappende naamruimtes zijn de tweede bron van verwarring. Een privézone voor example.net en een privézone voor api.example.net komen beide overeen met een API-query, en de meest specifieke antwoordt. Dat is handig als je een smalle interne naamruimte wilt, en gevaarlijk als de smalle zone een record mist dat de bredere wel heeft. De overwegingen voor privé-gehoste zones in de Route 53-documentatie beschrijven zowel het doorvalgedrag als de voorrang van regels, en ze zijn het lezen waard voordat je een tweede overlappende zone toevoegt.

Niets hiervan verandert de openbare zone. Openbare resolvers antwoorden de openbare records nog steeds correct, en daarom lijkt de fout voor iedereen buiten de VPC op een clientprobleem.

Kies de naamruimte voordat je records toevoegt

Als alleen een nieuwe familie interne services privénamen nodig heeft, geef die dan een eigen privésubdomein en laat het openbare bovenliggende domein met rust. Een naam als internal.example.net kan www.example.net niet overschaduwen, en de impactradius van een ontbrekend record blijft beperkt tot de namen die je voor dat doel hebt bedacht. De prijs is dat bestaande URL's en certificaten mogelijk niet bij de nieuwe naam passen.

Wanneer openbare en privégebruikers dezelfde hostnaam moeten behouden, is DNS met gesplitste weergave het ondersteunde ontwerp en het vereist dat je de records in elke weergave expliciet onderhoudt. Een brede privézone met één record erin behoudt de openbare afhankelijkheden onder die zone niet; hij vervangt ze door een zone met één record.

Inventariseer de namen die een applicatie echt aanroept voordat je een clientpopulatie op de privéweergave richt. Loginhosts, hosts voor statische assets, omleidingsdoelen en API-eindpunten breken het eerst, en ze zijn meestal verspreid over de records van meerdere teams.

Volg het pad van de resolver en dan de route

Een laptop ziet de privéweergave alleen als zijn queries de resolver bereiken die de koppeling heeft. Het bewerken van een hosts-bestand op de VPN-server publiceert niets naar verbonden clients, en een client met een openbare resolver blijft openbare antwoorden krijgen zolang de tunnel actief is. Bevestig het resolveradres dat de client heeft ontvangen en herhaal de query daarna vanaf de client in plaats van vanaf de server.

Zodra de naam is opgelost, test je het pad naar het teruggegeven adres als aparte stap, bijvoorbeeld met ip route get tegen het adres dat de query teruggaf. Een correct privéantwoord zonder route naar het adres is een routingprobleem, en een antwoord over een ontbrekend record is een DNS-weergaveprobleem; ze als één probleem behandelen levert oplossingen op die niet standhouden. Laat de TLS-hostnaam en certificaatcontroles van de dienst ongewijzigd, want een privéadres verandert waar de verbinding heen gaat en niets aan welk certificaat geldig is.

Sluit af met het vastleggen van de zone, de koppeling, de resolver en de namen die je hebt geverifieerd in de wijzigingsnotitie. Dan weet de volgende persoon die een record toevoegt welke naamruimte gezaghebbend is voor die clientpopulatie.