Af hverju einkasvæði Route 53 skilar NXDOMAIN fyrir opinber nöfn

Einkasvæði Route 53 koma í stað svars fyrir nafn í stað þess að sameinast opinberu færslunni, og það kemur fólki á óvart á versta mögulega tíma. Bættu við einni innri færslu fyrir api.example.net á einkasvæði fyrir example.net, tengdu það við VPC, og öll önnur nöfn undir því foreldri eru nú svarað eingöngu frá einkasvæðinu. Skjáborð sem gat náð í www.example.net í gær fær í dag neikvætt svar. Yfirferðin hér að neðan byrjar á þeirri misheppnuðu fyrirspurn og vinnur út að svæðinu sem svaraði henni.

Byrjaðu á fyrirspurninni, ekki stjórnborðinu

Endurtaktu bilunina á þeim skjáborði sem tilkynnti hana, og skráðu nákvæma nafnið og færslutegundina. Nafn sem bregst fyrir A getur samt leyst fyrir AAAA, og vafri sem reynir skyggða nafnið aftur felur hvort þeirra er brotið. Keyrðu fyrirspurnina tvisvar: einu sinni í gegnum þann leysi sem skjáborðið notar í raun, og einu sinni með rakningu sem fer fram hjá honum.

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

Seinna skipunin er sú mikilvæga. Stöðulína hennar og heimildarhlutinn nefna svæðið sem bjó til svarið, svo þú getur greint neikvætt svar frá einkasvæðinu frá tímamörkum, lokuðum porti eða leysi sem fékk aldrei fyrirspurnina. resolvectl sýnir hvaða yfirþjóni var spurður, og það er oft ekki sá leysir sem þú gerðir ráð fyrir að VPN hefði sent.

Ef rakin fyrirspurn skilar opinberu vistfanginu en venjulega fyrirspurnin ekki, er opinbera færslan heil og einkasýnin svarar. Þessi eina samanburður ræður því hvorri helmingi af restinni af þessari síðu á við um þig.

Lestu hvaða svæði svaraði

Svar sem ber NXDOMAIN og hefur SOA einkasvæðisins í heimildarhlutanum er endanlegt svar frá því svæði, ekki misheppnuð leit. Route 53 Resolver valdi hýsta einkasvæðinu vegna þess að nafnið passaði, fann svo enga færslu af umbeðinni tegund, og skjalfest hegðun er að skila neikvæða svarinu í stað þess að senda spurninguna áfram til opinbers DNS.

Valið fylgir sértækni. Þegar mörg einkanafnarými skarast vinnur sértækasta samsvarandi svæðið, og breiðara einkaforeldri fær ekki annað tækifæri fyrir nafn sem valið undirsvæði hefur ekki. Áframsendingarreglur bæta við enn einu lagi, því regla um tiltekið lén getur sigrað tengingu hýsta einkasvæðisins. Teldu upp tengingarnar og reglurnar áður en þú ályktar að svæði sé tómt.

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

Báðar skipanirnar þurfa skilríki fyrir reikninginn sem á svæðið, og hin síðari þarf svæðisauðkennið úr þeirri fyrri. Skiptu því út fyrir þitt eigið; staðgengillinn hér að ofan er viljandi ekki raunverulegur.

Af hverju einkasvæðið vinnur

Tengingin er það sem gerir svæðið sýnilegt fyrir VPC, og leysirinn í því VPC beitir henni. Einkasvæði sem er ekki tengt því VPC sem umferð skjáborðsins kemur frá hefur engin áhrif, en tenging við rangt VPC framleiðir einkasvar fyrir rangan hóp. Athugaðu tengingalistann áður en þú breytir færslum, því svæði getur verið rétt og samt ósýnilegt.

Skarandi nafnarými eru annað ruglvaldið. Einkasvæði fyrir example.net og einkasvæði fyrir api.example.net passa bæði við API-fyrirspurn, og hið sértækara svarar. Það er gagnlegt þegar þú vilt þröngt innra nafnarými, og hættulegt þegar þrönga svæðið vantar færslu sem hið breiðara hefur. Athuganir um hýst einkasvæði í Route 53 skjölunum lýsa bæði hegðuninni þegar fallið er niður á breiðara svæði og forgangi reglnanna, og þær eru þess virði að lesa áður en þú bætir við öðru skarandi svæði.

Ekkert af þessu breytir opinbera svæðinu. Opinberir leysar svara enn réttum opinberum færslum, og þess vegna virðist bilunin vera vandamál skjáborðsins fyrir öllum utan VPC.

Veldu nafnarýmið áður en þú bætir við færslum

Ef aðeins nýr flokkur innri þjónustu þarf einkasvæðisnöfn, gefðu honum sérstakt einkasvæðis undirlén og láttu opinbera foreldrið vera. Nafn eins og internal.example.net getur ekki skyggt á www.example.net, og áhrifasvið færslu sem vantar takmarkast við nöfnin sem þú bjóst til í þeim tilgangi. Kostnaðurinn er að fyrirliggjandi URL-slóðir og vottorð passa kannski ekki við nýja nafnið.

Þegar opinberir og einkaaðilar verða að halda sama hýsinu, er DNS með skiptri sýn studda hönnunin og hún krefst þess að þú viðhaldir færslum í hverri sýn með skýrum hætti. Breitt einkasvæði með einni færslu varðveitir ekki opinberu háðina undir því svæði; það kemur í stað þeirra með svæði sem hefur eina færslu.

Gerðu lista yfir nöfnin sem forrit kallar í raun áður en þú beinir hópi skjáborða að einkasýninni. Innskráningarþjónar, þjónar kyrrstæðra auðlinda, áframsendingarmörk og API-endapunktar brotna fyrst, og þau dreifast venjulega um færslur nokkurra teyma.

Rekjaðu slóð leysisins, síðan leiðina

Fartölva sér aðeins einkasýnina ef fyrirspurnir hennar ná til leysisins sem hefur tenginguna. Að breyta hosts-skrá á VPN-þjóninum birtir ekkert fyrir tengdum skjáborðum, og skjáborð stillt með opinberum leysi heldur áfram að fá opinber svör meðan göngin eru uppi. Staðfestu leysiaðsetrið sem skjáborðið fékk, og endurtaktu svo fyrirspurnina frá skjáborðinu frekar en þjóninum.

Þegar nafnið hefur leyst, prófaðu leiðina að skilaða vistfanginu sem sérstakt skref, til dæmis með ip route get á móti vistfanginu sem fyrirspurnin skilaði. Rétt einkasvar án leiðar að vistfanginu er leiðavandamál, og svar um færslu sem vantar er vandamál í DNS-sýn; að meðhöndla þau sem eitt vandamál framleiðir lagfæringar sem standa ekki. Láttu TLS-hýsinafnsskoðun þjónustunnar og vottorðsskoðun óbreytt, því einkavistfang breytir hvert tengingin fer og engu um hvaða vottorð er gilt.

Ljúktu með því að skrá svæðið, tenginguna, leysinn og nöfnin sem þú staðfestir í breytingarathugasemdinni. Þá veit næsta manneskja sem bætir við færslu hvaða nafnarými er ráðandi fyrir þann hóp skjáborða.