Hoekom 'n private Route 53-sone NXDOMAIN vir openbare name terugstuur

Private Route 53-sones vervang die antwoord vir 'n naam in plaas daarvan om by die openbare rekord in te voeg, en dit verras mense op die slegste oomblik. Voeg een interne rekord by vir api.example.net in 'n private sone vir example.net, koppel dit aan 'n VPC, en elke ander naam onder daardie ouer word nou alleen uit die private sone beantwoord. 'n Kliënt wat www.example.net gister kon bereik, kry vandag 'n negatiewe antwoord. Die uiteensetting hieronder begin by daardie mislukte navraag en werk uitwaarts na die sone wat dit beantwoord het.

Begin by die navraag, nie by die konsole nie

Reproduseer die fout op die kliënt wat dit gerapporteer het, en teken die presiese naam en rekordtipe aan. 'n Naam wat vir A misluk, kan steeds vir AAAA oplos, en 'n blaaier wat 'n gekaste naam herprobeer, verberg watter een gebreek het. Voer die navraag twee keer uit: een keer deur die oplosser wat die kliënt werklik gebruik, en een keer met naspeuring wat dit omseil.

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

Die tweede opdrag is die belangrike een. Sy statuslyn en authority-afdeling noem die sone wat die antwoord gelewer het, sodat jy 'n negatiewe antwoord uit die private sone kan onderskei van 'n time-out, 'n geblokkeerde poort of 'n oplosser wat die navraag nooit ontvang het nie. resolvectl wys watter opstroom die gasheer gevra het, wat dikwels nie die oplosser is wat jy aangeneem het die VPN gestuur het nie.

As die nagespoorde navraag die openbare adres teruggee terwyl die normale navraag dit nie doen nie, is die openbare rekord ongeskonde en antwoord die private aansig. Daardie enkele vergelyking bepaal watter helfte van die res van hierdie bladsy van toepassing is.

Lees watter sone geantwoord het

'n Antwoord met NXDOMAIN met die private sone se SOA in die authority-afdeling is 'n definitiewe antwoord van daardie sone, nie 'n mislukte opsoeking nie. Route 53 Resolver het die private hosted sone gekies omdat sy naam gepas het, toe geen rekord van die versoekte tipe gevind nie, en die gedokumenteerde gedrag is om die negatiewe antwoord terug te gee in plaas daarvan om die vraag aan openbare DNS deur te stuur.

Seleksie volg spesifisiteit. Met verskeie oorvleuelende private naamruimtes wen die mees spesifieke passende sone, en 'n breër private ouer kry nie 'n tweede kans by 'n naam wat die gekose kindersone nie het nie. Deurstuur-reels voeg nog 'n laag bo-op, want 'n domeinspesifieke Resolver-reel kan die assosiasie met die private hosted sone oorwin. Lys die assosiasies en reels voordat jy aflei dat 'n sone 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 opdragte benodig geloofsbriewe vir die rekening wat die sone besit, en die tweede het die sone-ID van die eerste nodig. Vervang dit met jou eie ID; die plekhouer hierbo is doelbewus nie 'n regte een nie.

Hoekom die private sone wen

Die assosiasie is wat die sone sigbaar maak vir 'n VPC, en die Resolver in daardie VPC is wat dit toepas. 'n Private sone wat nie aan die VPC geassosieer is waarvan die kliënt se verkeer kom nie, het hoegenaamd geen effek nie, terwyl 'n assosiasie met die verkeerde VPC 'n private antwoord vir die verkeerde populasie lewer. Kontroleer die assosiasialys voordat jy rekords wysig, want 'n sone kan korrek wees en steeds onsigbaar wees.

Oorvleuelende naamruimtes is die tweede bron van verwarring. 'n Private sone vir example.net en 'n private sone vir api.example.net pas albei 'n API-navraag, en die spesifiekere een antwoord. Dit is nuttig wanneer jy 'n nou interne naamruimte wil hê, en gevaarlik wanneer die nou sone 'n rekord mis wat die breër een het. Die private hosted sone-oorwegings in die Route 53-dokumentasie beskryf beide die deurvalgedrag en die reëlpresedensie, en dit is die moeite werd om te lees voordat jy 'n tweede oorvleuelende sone byvoeg.

Niks hiervan verander die openbare sone nie. Openbare oplossers antwoord steeds die openbare rekords korrek, en daarom lyk die fout vir almal buite die VPC soos 'n kliëntprobleem.

Kies die naamruimte voordat jy rekords byvoeg

As slegs 'n nuwe familie interne dienste private name nodig het, gee dit 'n toegewyde private subdomein en los die openbare ouer alleen. 'n Naam soos internal.example.net kan nie www.example.net oorskadu nie, en die impak van 'n ontbrekende rekord is beperk tot name wat jy vir die doel uitgedink het. Die koste is dat bestaande URL's en sertifikate dalk nie by die nuwe naam pas nie.

Wanneer openbare en private gebruikers dieselfde gasheernaam moet behou, is split-view DNS die ondersteunde ontwerp, en dit vereis dat jy die rekords in elke aansig eksplisiet onderhou. 'n Breë private sone met een rekord daarin bewaar nie die openbare afhanklikhede onder daardie sone nie; dit vervang hulle met 'n sone wat een rekord het.

Inventariseer die name wat 'n toepassing werklik aanroep voordat jy 'n kliëntpopulasie na die private aansig rig. Aanmeld-gashere, statiese bate-gashere, herleidingsteikens en API-eindpunte is die een wat eerste breek, en hulle is gewoonlik oor verskeie spanne se rekords versprei.

Volg die oplosserpad, dan die roete

'n Skootrekenaar sien die private aansig net as sy navrae die oplosser bereik wat die assosiasie het. Om 'n hosts-lêer op die VPN-bediener te wysig, publiseer niks aan gekoppelde kliënte nie, en 'n kliënt wat met 'n openbare oplosser opgestel is, sal aanhou openbare antwoorde kry terwyl die tonnel op is. Bevestig die oplosseradres wat die kliënt ontvang het, en herhaal dan die navraag vanaf die kliënt eerder as vanaf die bediener.

Sodra die naam oplos, toets die pad na die teruggegewe adres as 'n aparte stap, byvoorbeeld met ip route get teen die adres wat die navraag teruggegee het. 'n Korrekte private antwoord sonder 'n roete na die adres is 'n roeteprobleem, en 'n antwoord oor 'n ontbrekende rekord is 'n DNS-aansig-probleem; om hulle as een kwessie te behandel, lewer regstellings wat nie hou nie. Hou die diens se TLS-gasheernaam en sertifikaatkontroles onveranderd, want 'n private adres verander waar die verbinding heen gaan en niks oor watter sertifikaat geldig is nie.

Sluit af deur die sone, die assosiasie, die oplosser en die name wat jy geverifieer het in die veranderingsnota aan te teken. Die volgende persoon wat 'n rekord byvoeg, sal dan weet watter naamruimte gesaghebbend is vir daardie kliëntpopulasie.