Miksi yksityinen Route 53 -vyöhyke palauttaa NXDOMAIN julkisille nimille

Yksityiset Route 53 -vyöhykkeet korvaavat nimen vastauksen sen sijaan, että ne yhdistyisivät julkiseen tietueeseen, ja se yllättää ihmiset pahimmalla hetkellä. Lisää yksi sisäinen tietue nimelle api.example.net yksityisellä vyöhykkeellä nimelle example.net, liitä se VPC:hen, ja kaikki muut nimet kyseisen ylätason alla vastataan nyt vain yksityiseltä vyöhykkeeltä. Asiakas, joka eilen pääsi osoitteeseen www.example.net, saa tänään kielteisen vastauksen. Alla oleva läpikäynti alkaa tuosta epäonnistuneesta kyselystä ja etenee ulospäin vyöhykkeeseen, joka siihen vastasi.

Aloita kyselystä, älä konsolista

Toista vika asiakkaalla, joka sen raportoi, ja kirjaa tarkka nimi ja tietuetyyppi. Nimi, joka epäonnistuu tyypille A voi silti ratketa tyypille AAAA, ja välimuistiin tallennetun nimen uudelleen yrittävä selain piilottaa kumpi hajosi. Suorita kysely kahdesti: kerran sen resolverin kautta, jota asiakas todella käyttää, ja kerran sen ohittavalla jäljityksellä.

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

Toinen komento on tärkeä. Sen tilannerivi ja authority-osio nimeävät vyöhykkeen, joka tuotti vastauksen, joten voit erottaa yksityiseltä vyöhykkeeltä tulevan kielteisen vastauksen aikakatkaisusta, estetystä portista tai resolverista, joka ei koskaan saanut kyselyä. resolvectl näyttää, miltä ylemmältä palvelimelta kysyttiin, ja usein se ei ole se resolver, jonka oletit VPN:n lähettäneen.

Jos jäljitetty kysely palauttaa julkisen osoitteen mutta tavallinen ei, julkinen tietue on ehjä ja yksityinen näkymä vastaa. Juuri tämä yksi vertailu ratkaisee, kumpi puoli tämän sivun loppuosasta koskee sinua.

Lue, mikä vyöhyke vastasi

Vastaus, joka kantaa NXDOMAIN ja jonka authority-osiossa on yksityisen vyöhykkeen SOA, on kyseisen vyöhykkeen lopullinen vastaus, ei epäonnistunut haku. Route 53 Resolver valitsi yksityisen isännöidyn vyöhykkeen, koska nimi täsmäsi, ei sitten löytänyt pyydetyn tyyppistä tietuetta, ja dokumentoitu käyttäytyminen on palauttaa kielteinen vastaus sen sijaan, että kysymys välitettäisiin julkiseen DNS:ään.

Valinta noudattaa spesifisyyttä. Kun useita yksityisiä nimiavaruuksia menee päällekkäin, täsmäävistä vyöhykkeistä tarkin voittaa, eikä laajempi yksityinen ylätaso saa toista mahdollisuutta nimelle, jota valittu alivyöhyke ei sisällä. Edelleenohjaussäännöt lisäävät yhden kerroksen, sillä verkkotunnuskohtainen Resolver-sääntö voi voittaa yksityisen isännöidyn vyöhykkeen liitoksen. Listaa liitokset ja säännöt ennen kuin päättelet vyöhykkeen olevan tyhjä.

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

Molemmat komennot tarvitsevat vyöhykkeen omistavan tilin tunnukset, ja toinen tarvitsee vyöhyketunnuksen ensimmäisestä. Korvaa se omallasi; yllä oleva paikkamerkki ei ole tahallaan oikea.

Miksi yksityinen vyöhyke voittaa

Liitos tekee vyöhykkeestä näkyvän VPC:lle, ja kyseisen VPC:n resolver soveltaa sitä. Yksityisellä vyöhykkeellä, jota ei ole liitetty siihen VPC:hen, josta asiakkaan liikenne tulee, ei ole lainkaan vaikutusta, kun taas liitos väärään VPC:hen tuottaa yksityisen vastauksen väärälle joukolle. Tarkista liitosluettelo ennen tietueiden muokkaamista, sillä vyöhyke voi olla oikein ja silti näkymätön.

Päällekkäiset nimiavaruudet ovat toinen hämmennyslähde. Yksityinen vyöhyke nimelle example.net ja yksityinen vyöhyke nimelle api.example.net täsmäävät molemmat API-kyselyyn, ja tarkempi vastaa. Tämä on hyödyllistä, kun haluat kapean sisäisen nimiavaruuden, ja vaarallista, kun kapealta vyöhykkeeltä puuttuu tietue, joka laajemmalla on. Yksityisten isännöityjen vyöhykkeiden näkökohdat Route 53 -dokumentaatiossa kuvaavat sekä läpimenokäyttäytymisen että sääntöjen etusijan, ja ne kannattaa lukea ennen toisen päällekkäisen vyöhykkeen lisäämistä.

Mikään tästä ei muuta julkista vyöhykettä. Julkiset resolverit vastaavat edelleen oikein julkisiin tietueisiin, ja siksi vika näyttää VPC:n ulkopuolisista kaikista asiakasongelmalta.

Valitse nimiavaruus ennen kuin lisäät tietueita

Jos vain uusi sisäisten palvelujen perhe tarvitsee yksityisiä nimiä, anna sille oma yksityinen aliverkkotunnus ja jätä julkinen ylätaso rauhaan. Nimi kuten internal.example.net ei voi varjostaa nimeä www.example.net, ja puuttuvan tietueen vaikutusalue rajoittuu nimiin, jotka keksit tarkoitusta varten. Hinta on se, että olemassa olevat URL-osoitteet ja varmenteet eivät ehkä vastaa uutta nimeä.

Kun julkisten ja yksityisten käyttäjien on säilytettävä sama isäntänimi, jaetun näkymän DNS on tuettu suunnittelu, ja se edellyttää, että ylläpidät tietueet kussakin näkymässä nimenomaisesti. Laaja yksityinen vyöhyke, jossa on yksi tietue, ei säilytä kyseisen vyöhykkeen alla olevia julkisia riippuvuuksia; se korvaa ne vyöhykkeellä, jossa on yksi tietue.

Luettele nimet, joita sovellus todella kutsuu, ennen kuin ohjaat asiakasjoukon yksityiseen näkymään. Kirjautumisisännät, staattisten resurssien isännät, uudelleenohjauskohteet ja API-päätepisteet hajoavat ensimmäisinä, ja ne ovat yleensä hajallaan useiden tiimien tietueissa.

Jäljitä resolverin polku ja sitten reitti

Kannettava tietokone näkee yksityisen näkymän vain, jos sen kyselyt päätyvät resolveriin, jolla on liitos. VPN-palvelimen hosts-tiedoston muokkaaminen ei julkaise mitään yhdistetyille asiakkaille, ja julkisella resolverilla määritetty asiakas saa jatkossakin julkisia vastauksia niin kauan kuin tunneli on pystyssä. Vahvista asiakkaan saama resolveriosoite ja toista sitten kysely asiakkaalta eikä palvelimelta.

Kun nimi on ratkennut, testaa reitti palautettuun osoitteeseen erillisenä vaiheena, esimerkiksi komennolla ip route get sitä osoitetta vasten, jonka kysely palautti. Oikea yksityinen vastaus ilman reittiä osoitteeseen on reititysongelma, ja puuttuvaa tietuetta koskeva vastaus on DNS-näkymäongelma; niiden käsitteleminen yhtenä ongelmana tuottaa korjauksia, jotka eivät pidä. Jätä palvelun TLS-isäntänimen ja varmenteen tarkistukset ennalleen, koska yksityinen osoite muuttaa sitä, minne yhteys menee, eikä mitään siitä, mikä varmenne on kelvollinen.

Lopeta kirjaamalla muutosmerkintään vyöhyke, liitos, resolver ja tarkistamasi nimet. Silloin seuraava tietueen lisääjä tietää, mikä nimiavaruus on määräävä kyseiselle asiakasjoukolle.