Miért ad vissza NXDOMAIN-t egy privát Route 53 zóna nyilvános nevekre

A privát Route 53 zónák lecserélik egy név válaszát ahelyett, hogy összeolvadnának a nyilvános rekorddal, és ez a legrosszabb pillanatban lepi meg az embereket. Adjon hozzá egy belső rekordot erre: api.example.net egy privát zónában erre: example.net, társítsa egy VPC-hez, és a szülő alatti minden más név mostantól csak a privát zónából válaszol. Egy kliens, amely tegnap elérte a www.example.net címet, ma negatív választ kap. Az alábbi végigvezetés ebből a sikertelen lekérdezésből indul, és kifelé halad ahhoz a zónához, amely válaszolt rá.

A lekérdezéssel kezdje, ne a konzollal

Reprodukálja a hibát azon a kliensen, amely jelentette, és jegyezze fel a pontos nevet és rekordtípust. Egy név, amely erre nem működik: A még feloldódhat erre: AAAA, és a gyorsítótárazott nevet újrapróbáló böngésző elrejti, melyikük tört el. Futtassa a lekérdezést kétszer: egyszer azon a feloldón keresztül, amelyet a kliens valóban használ, egyszer pedig egy azt megkerülő nyomkövetéssel.

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

A második parancs a fontos. A státuszsora és az authority szakasza megnevezi a zónát, amely a választ előállította, így meg tudja különböztetni a privát zónából jövő negatív választ egy időtúllépéstől, egy blokkolt porttól vagy egy olyan feloldótól, amely soha nem kapta meg a lekérdezést. resolvectl megmutatja, melyik felső szervert kérdezték, és ez gyakran nem az a feloldó, amelyről feltételezte, hogy a VPN elküldte.

Ha a nyomkövetett lekérdezés visszaadja a nyilvános címet, a normál pedig nem, a nyilvános rekord sértetlen, és a privát nézet válaszol. Ez az egyetlen összehasonlítás dönti el, hogy ennek az oldalnak melyik fele vonatkozik Önre.

Olvassa el, melyik zóna válaszolt

Az a válasz, amely NXDOMAIN hordoz, és az authority szakaszban a privát zóna SOA-ja szerepel, az adott zóna végleges válasza, nem sikertelen keresés. A Route 53 Resolver azért választotta a privát hosztolt zónát, mert a név egyezett, majd nem talált a kért típusú rekordot, és a dokumentált viselkedés a negatív válasz visszaadása ahelyett, hogy a kérdést továbbítaná a nyilvános DNS-nek.

A választás a specificitást követi. Ha több privát névtér fedi egymást, a leginkább specifikus egyező zóna nyer, és egy szélesebb privát szülő nem kap második esélyt olyan névre, amellyel a kiválasztott gyermekzóna nem rendelkezik. A továbbítási szabályok még egy réteget adnak hozzá, mert egy domainspecifikus Resolver-szabály felülírhatja a privát hosztolt zóna társítását. Sorolja fel a társításokat és a szabályokat, mielőtt arra jutna, hogy egy zóna üres.

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

Mindkét parancshoz a zónát birtokló fiók hitelesítő adatai kellenek, a másodikhoz pedig az elsőből származó zóna-azonosító. Helyettesítse a sajátjával; a fenti helyőrző szándékosan nem valódi.

Miért nyer a privát zóna

A társítás teszi a zónát láthatóvá egy VPC számára, és az abban a VPC-ben lévő feloldó alkalmazza. Egy privát zónának, amely nincs társítva ahhoz a VPC-hez, ahonnan a kliens forgalma érkezik, egyáltalán nincs hatása, míg a rossz VPC-hez való társítás a rossz populációnak ad privát választ. Ellenőrizze a társítások listáját a rekordok szerkesztése előtt, mert egy zóna lehet helyes és mégis láthatatlan.

Az átfedő névterek a második zavarforrás. Egy privát zóna erre: example.net és egy privát zóna erre: api.example.net mindkettő egyezik egy API-lekérdezéssel, és a specifikusabb válaszol. Ez hasznos, ha szűk belső névteret akar, és veszélyes, ha a szűk zónából hiányzik egy rekord, amely a szélesebben megvan. A privát hosztolt zónákra vonatkozó megfontolások a Route 53 dokumentációjában leírják a továbbesési viselkedést és a szabályok elsőbbségét is, és érdemes elolvasni őket, mielőtt második átfedő zónát ad hozzá.

Ezek egyike sem változtatja meg a nyilvános zónát. A nyilvános feloldók továbbra is helyesen válaszolnak a nyilvános rekordokra, és ezért tűnik a hiba a VPC-n kívüliek számára kliensproblémának.

A rekordok hozzáadása előtt válassza ki a névteret

Ha csak a belső szolgáltatások egy új családjának kellenek privát nevek, adjon neki dedikált privát aldomeint, és hagyja békén a nyilvános szülőt. Egy ilyen név: internal.example.net nem tudja árnyékolni ezt: www.example.net, és a hiányzó rekord hatósugara azokra a nevekre korlátozódik, amelyeket erre a célra kitalált. Az ára az, hogy a meglévő URL-ek és tanúsítványok esetleg nem egyeznek az új névvel.

Amikor a nyilvános és privát felhasználóknak ugyanazt a gazdanevet kell megtartaniuk, az osztott nézetű DNS a támogatott megoldás, és megköveteli, hogy a rekordokat minden nézetben kifejezetten fenntartsa. Egy széles privát zóna egyetlen rekorddal nem őrzi meg a zóna alatti nyilvános függőségeket; lecseréli őket egy olyan zónára, amelynek egy rekordja van.

Azelőtt, hogy egy ügyfélpopulációt a privát nézetre irányítana, vegye számba azokat a neveket, amelyeket egy alkalmazás valóban hív. A bejelentkezési gazdák, a statikus erőforrás-gazdák, az átirányítási célok és az API-végpontok törnek el először, és általában több csapat rekordjai között oszlanak meg.

Kövesse a feloldó útvonalát, majd az útvonalat

Egy laptop csak akkor látja a privát nézetet, ha a lekérdezései eljutnak ahhoz a feloldóhoz, amelyen a társítás van. A hosts fájl szerkesztése a VPN-kiszolgálón semmit nem tesz közzé a csatlakozott klienseknek, és egy nyilvános feloldóval beállított kliens továbbra is nyilvános válaszokat kap, amíg az alagút áll. Erősítse meg a kliens által kapott feloldócímet, majd ismételje meg a lekérdezést a kliensről, ne a kiszolgálóról.

Amint a név feloldódik, tesztelje a visszaadott címhez vezető útvonalat külön lépésként, például ezzel: ip route get a lekérdezés által visszaadott címmel szemben. A helyes privát válasz a címhez vezető útvonal nélkül útvonalválasztási probléma, a hiányzó rekordról szóló válasz pedig DNS-nézeti probléma; ha egyetlen problémaként kezeli őket, olyan javítások születnek, amelyek nem tartanak. Hagyja változatlanul a szolgáltatás TLS-gazdanevének és tanúsítványának ellenőrzését, mert a privát cím megváltoztatja, hová megy a kapcsolat, és semmit nem változtat azon, melyik tanúsítvány érvényes.

Fejezze be azzal, hogy a változásjegyzetbe felírja a zónát, a társítást, a feloldót és az ellenőrzött neveket. Így a következő ember, aki rekordot ad hozzá, tudni fogja, melyik névtér mérvadó az adott ügyfélpopuláció számára.