Prečo privátna zóna Route 53 vracia NXDOMAIN pre verejné názvy

Privátne zóny Route 53 nahrádzajú odpoveď pre názov namiesto toho, aby sa zlúčili s verejným záznamom, a to ľudí prekvapí v najhoršej chvíli. Pridajte jeden interný záznam pre api.example.net v privátnej zóne pre example.net, prepojte ju s VPC a každé ďalšie meno pod týmto nadradeným prvkom sa teraz odpovedá iba z privátnej zóny. Klient, ktorý sa včera dostal na www.example.net dnes dostane negatívnu odpoveď. Nasledujúci postup začína pri tomto neúspešnom dopyte a ide von k zóne, ktorá naň odpovedala.

Začnite dopytom, nie konzolou

Zreprodukujte zlyhanie na klientovi, ktorý ho nahlásil, a poznamenajte presný názov a typ záznamu. Názov, ktorý zlyháva pre A sa však môže stále prekladať pre AAAA, a prehliadač, ktorý znova skúša uložený názov, skrýva, ktorý z nich sa pokazil. Spustite dopyt dvakrát: raz cez resolver, ktorý klient skutočne používa, a raz s trasovaním, ktoré ho obchádza.

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

Druhý príkaz je ten dôležitý. Jeho stavový riadok a sekcia autority pomenúvajú zónu, ktorá odpoveď vytvorila, takže negatívnu odpoveď z privátnej zóny odlíšite od vypršania časového limitu, blokovaného portu alebo resolveru, ktorý dopyt nikdy nedostal. resolvectl ukazuje, ktorý nadradený server bol opýtaný, a to často nie je resolver, o ktorom ste predpokladali, že ho VPN poslala.

Ak trasovaný dopyt vracia verejnú adresu a bežný nie, verejný záznam je v poriadku a odpovedá privátne zobrazenie. Práve toto jediné porovnanie rozhoduje, ktorá polovica zvyšku tejto stránky sa na vás vzťahuje.

Prečítajte si, ktorá zóna odpovedala

Odpoveď nesúca NXDOMAIN so SOA privátnej zóny v sekcii autority je definitívna odpoveď tejto zóny, nie neúspešné hľadanie. Route 53 Resolver vybral privátnu hostovanú zónu, pretože názov sa zhodoval, potom nenašiel záznam požadovaného typu a dokumentované správanie je vrátiť negatívnu odpoveď namiesto odoslania otázky do verejného DNS.

Výber sleduje špecifickosť. Pri viacerých prekrývajúcich sa privátnych priestoroch názvov vyhráva najkonkrétnejšia zodpovedajúca zóna a širší privátny nadradený prvok nedostane druhú šancu pre názov, ktorý vybraná podriadená zóna nemá. Pravidlá presmerovania pridávajú ďalšiu vrstvu, pretože pravidlo resolvera pre konkrétnu doménu môže prebiť prepojenie privátnej hostovanej zóny. Vymenujte prepojenia a pravidlá, než usúdite, že zóna je prázdna.

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

Oba príkazy potrebujú prihlasovacie údaje k účtu, ktorý zónu vlastní, a druhý potrebuje ID zóny z prvého. Nahraďte ho svojím ID; zástupný údaj vyššie zámerne nie je skutočný.

Prečo vyhráva privátna zóna

Prepojenie je to, čo robí zónu viditeľnou pre VPC, a resolver v tejto VPC ho uplatňuje. Privátna zóna, ktorá nie je prepojená s VPC, odkiaľ prichádza prevádzka klienta, nemá vôbec žiadny účinok, kým prepojenie s nesprávnou VPC dáva privátnu odpoveď nesprávnej populácii. Skontrolujte zoznam prepojení pred úpravou záznamov, pretože zóna môže byť správna a napriek tomu neviditeľná.

Prekrývajúce sa priestory názvov sú druhým zdrojom zmätku. Privátna zóna pre example.net a privátna zóna pre api.example.net obe zodpovedajú dopytu API a odpovedá tá konkrétnejšia. To je užitočné, keď chcete úzky interný priestor názvov, a nebezpečné, keď úzkej zóne chýba záznam, ktorý má širšia. Úvahy o privátnych hostovaných zónach v dokumentácii Route 53 opisujú aj správanie pri prepade, aj prioritu pravidiel, a stojí za to ich prečítať pred pridaním druhej prekrývajúcej sa zóny.

Nič z toho nemení verejnú zónu. Verejné resolvery stále správne odpovedajú na verejné záznamy, a preto všetkým mimo VPC zlyhanie pripadá ako problém klienta.

Vyberte priestor názvov, než pridáte záznamy

Ak privátne názvy potrebuje len nová rodina interných služieb, dajte jej vyhradenú privátnu subdoménu a verejného nadradeného prvku nechajte na pokoji. Názov ako internal.example.net nemôže zatieniť www.example.net, a dosah chýbajúceho záznamu je obmedzený na názvy, ktoré ste na tento účel vymysleli. Cenou je, že existujúce URL a certifikáty nemusia novému názvu zodpovedať.

Keď verejní aj privátni používatelia musia zachovať rovnaký názov hostiteľa, DNS s rozdeleným zobrazením je podporovaný návrh a vyžaduje, aby ste záznamy v každom zobrazení udržiavali explicitne. Široká privátna zóna s jediným záznamom nezachováva verejné závislosti pod touto zónou; nahrádza ich zónou, ktorá má jeden záznam.

Než nasmerujete populáciu klientov na privátne zobrazenie, zinventarizujte názvy, ktoré aplikácia skutočne volá. Prihlasovací hostitelia, hostitelia statických prostriedkov, ciele presmerovania a koncové body API sa lámu prvé a zvyčajne sú roztrúsené medzi záznamami viacerých tímov.

Sledujte cestu resolvera, potom trasu

Notebook vidí privátne zobrazenie len vtedy, keď sa jeho dopyty dostanú k resolveru, ktorý má prepojenie. Úprava súboru hosts na serveri VPN nič nezverejní pripojeným klientom a klient nastavený na verejný resolver bude dostávať verejné odpovede, kým je tunel hore. Potvrďte adresu resolvera, ktorú klient dostal, a potom dopyt zopakujte z klienta, nie zo servera.

Keď sa názov preloží, otestujte cestu k vrátenej adrese ako samostatný krok, napríklad pomocou ip route get proti adrese, ktorú dopyt vrátil. Správna privátna odpoveď bez trasy k adrese je problém smerovania a odpoveď o chýbajúcom zázname je problém zobrazenia DNS; ak ich beriete ako jeden problém, opravy nevydržia. Ponechajte kontroly názvu hostiteľa TLS a certifikátu služby bez zmeny, pretože privátna adresa mení, kam spojenie ide, a nič o tom, ktorý certifikát je platný.

Skončite zapísaním zóny, prepojenia, resolvera a názvov, ktoré ste overili, do poznámky o zmene. Potom ďalší človek, ktorý pridá záznam, bude vedieť, ktorý priestor názvov je pre túto populáciu klientov smerodajný.