Proč privátní zóna Route 53 vrací NXDOMAIN pro veřejná jména

Privátní zóny Route 53 nahrazují odpověď pro jméno místo toho, aby se sloučily s veřejným záznamem, a to lidi překvapí v nejhorší chvíli. Přidejte jeden interní záznam pro api.example.net v privátní zóně pro example.net, přidružte ji k VPC a každé další jméno pod tímto rodičem nyní odpovídá pouze z privátní zóny. Klient, který se včera dostal na www.example.net dnes dostane negativní odpověď. Následující postup začíná u tohoto neúspěšného dotazu a jde ven k zóně, která na něj odpověděla.

Začněte dotazem, ne konzolí

Reprodukujte selhání na klientovi, který ho nahlásil, a poznamenejte přesné jméno a typ záznamu. Jméno, které selhává pro A se přesto může přeložit pro AAAA, a prohlížeč, který znovu zkouší uložené jméno, skrývá, které z nich se rozbilo. Spusťte dotaz dvakrát: jednou přes resolver, který klient skutečně používá, a jednou s trasováním, které ho obejde.

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

Druhý příkaz je ten důležitý. Jeho stavový řádek a sekce autority pojmenovávají zónu, která odpověď vytvořila, takže negativní odpověď z privátní zóny odlišíte od vypršení časového limitu, blokovaného portu nebo resolveru, který dotaz nikdy nedostal. resolvectl ukazuje, kterého nadřazeného serveru se host ptal, a to často není resolver, o kterém jste předpokládali, že ho VPN poslala.

Pokud trasovaný dotaz vrací veřejnou adresu a běžný dotaz ne, veřejný záznam je v pořádku a odpovídá privátní pohled. Toto jediné srovnání rozhoduje, která polovina zbytku této stránky se na vás vztahuje.

Přečtěte si, která zóna odpověděla

Odpověď nesoucí NXDOMAIN se SOA privátní zóny v sekci autority je definitivní odpověď této zóny, ne neúspěšné hledání. Route 53 Resolver vybral privátní hostovanou zónu, protože se jméno shodovalo, pak nenašel záznam požadovaného typu a dokumentované chování je vrátit negativní odpověď místo předání dotazu veřejnému DNS.

Výběr sleduje specificitu. Při několika překrývajících se privátních prostorech jmen vyhrává nejkonkrétnější odpovídající zóna a širší privátní rodič nedostane druhou šanci pro jméno, které vybraná podřízená zóna nemá. Pravidla přesměrování přidávají další vrstvu, protože pravidlo resolveru pro konkrétní doménu může porazit přidružení privátní hostované zóny. Vyjmenujte přidružení a pravidla, než usoudíte, že je zóna prázdná.

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 příkazy potřebují přihlašovací údaje k účtu, který zónu vlastní, a druhý potřebuje ID zóny z prvního. Nahraďte ho svým ID; zástupný údaj výše záměrně není skutečný.

Proč privátní zóna vyhrává

Přidružení je to, co dělá zónu viditelnou pro VPC, a resolver v této VPC ho uplatňuje. Privátní zóna, která není přidružená k VPC, odkud přichází provoz klienta, nemá vůbec žádný účinek, zatímco přidružení ke špatné VPC dává privátní odpověď špatné populaci. Zkontrolujte seznam přidružení před úpravou záznamů, protože zóna může být správná a přesto neviditelná.

Překrývající se prostory jmen jsou druhým zdrojem zmatku. Privátní zóna pro example.net a privátní zóna pro api.example.net obě odpovídají dotazu na API a odpovídá ta konkrétnější. To je užitečné, když chcete úzký interní prostor jmen, a nebezpečné, když úzké zóně chybí záznam, který širší má. Úvahy o privátních hostovaných zónách v dokumentaci Route 53 popisují jak chování při propadu, tak prioritu pravidel, a stojí za přečtení, než přidáte druhou překrývající se zónu.

Nic z toho nemění veřejnou zónu. Veřejné resolvery stále správně odpovídají na veřejné záznamy, a proto všem mimo VPC selhání připadá jako problém klienta.

Zvolte prostor jmen, než přidáte záznamy

Pokud privátní jména potřebuje jen nová rodina interních služeb, dejte jí vyhrazenou privátní subdoménu a veřejného rodiče nechte být. Jméno jako internal.example.net nemůže zastínit www.example.net, a dopad chybějícího záznamu je omezen na jména, která jste pro tento účel vymysleli. Cenou je, že stávající URL a certifikáty nemusí novému jménu odpovídat.

Když veřejní i privátní uživatelé musí zachovat stejné jméno hostitele, DNS s rozděleným pohledem je podporovaný návrh a vyžaduje, abyste záznamy v každém pohledu udržovali explicitně. Široká privátní zóna s jediným záznamem nezachovává veřejné závislosti pod touto zónou; nahrazuje je zónou, která má jeden záznam.

Než nasměrujete populaci klientů na privátní pohled, inventarizujte jména, která aplikace skutečně volá. Přihlašovací hostitelé, hostitelé statických prostředků, cíle přesměrování a koncové body API se lámou první a obvykle jsou rozeseté mezi záznamy několika týmů.

Sledujte cestu resolveru, pak trasu

Notebook vidí privátní pohled jen tehdy, když se jeho dotazy dostanou k resolveru, který má přidružení. Úprava souboru hosts na serveru VPN nic nepublikuje připojeným klientům a klient nastavený na veřejný resolver bude dostávat veřejné odpovědi, dokud je tunel nahoře. Potvrďte adresu resolveru, kterou klient dostal, a pak dotaz zopakujte z klienta, ne ze serveru.

Jakmile se jméno přeloží, otestujte cestu k vrácené adrese jako samostatný krok, například s ip route get proti adrese, kterou dotaz vrátil. Správná privátní odpověď bez trasy k adrese je problém směrování a odpověď o chybějícím záznamu je problém pohledu DNS; pokud je berete jako jeden problém, opravy nevydrží. Ponechte kontroly názvu hostitele TLS a certifikátu beze změny, protože privátní adresa mění, kam spojení jde, a nic o tom, který certifikát je platný.

Skončete tím, že do poznámky ke změně zapíšete zónu, přidružení, resolver a jména, která jste ověřili. Příští člověk, který přidá záznam, pak bude vědět, který prostor jmen je pro tuto populaci klientů směrodatný.