Защо частна зона на Route 53 връща NXDOMAIN за публични имена

Частните зони на Route 53 заменят отговора за дадено име, вместо да се сливат с публичния запис, и това изненадва хората в най-неподходящия момент. Добавете един вътрешен запис за api.example.net в частна зона за example.net, свържете я с VPC и всяко друго име под този родител вече се отговаря само от частната зона. Клиент, който можеше да достигне www.example.net вчера, днес получава отрицателен отговор. Разборът по-долу започва от тази неуспешна заявка и върви навън към зоната, която ѝ е отговорила.

Започнете от заявката, не от конзолата

Възпроизведете проблема на клиента, който го е докладвал, и запишете точното име и типа запис. Име, което се проваля за A може все още да се решава за AAAA, а браузър, който повтаря кеширано име, скрива кое от двете е счупено. Изпълнете заявката два пъти: веднъж през resolver-а, който клиентът наистина използва, и веднъж с проследяване, което го заобикаля.

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

Втората команда е важната. Нейният ред за състояние и секцията за авторитет посочват зоната, която е дала отговора, така че можете да различите отрицателен отговор от частната зона от таймаут, блокиран порт или resolver, който никога не е получил заявката. resolvectl показва кой upstream е бил попитан, а това често не е resolver-ът, който сте предполагали, че VPN-ът е изпратил.

Ако проследената заявка връща публичния адрес, а нормалната не го връща, публичният запис е непокътнат и отговаря частният изглед. Това единствено сравнение решава коя половина от останалата част на тази страница се отнася за вас.

Прочетете коя зона е отговорила

Отговор, който носи NXDOMAIN със SOA на частната зона в секцията за авторитет, е категоричен отговор от тази зона, а не неуспешно търсене. Route 53 Resolver избра частната хоствана зона, защото името съвпадна, после не намери запис от поискания тип, а документираното поведение е да върне отрицателния отговор, вместо да препрати въпроса към публичния DNS.

Изборът следва специфичността. При няколко припокриващи се частни пространства от имена печели най-специфичната съвпадаща зона и по-широкият частен родител не получава втори шанс за име, което избраната дъщерна зона няма. Правилата за препращане добавят още един слой, тъй като правило на Resolver за конкретен домейн може да надделее над свързването с частната хоствана зона. Избройте свързванията и правилата, преди да заключите, че дадена зона е празна.

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

И двете команди изискват идентификационни данни за акаунта, който притежава зоната, а втората се нуждае от идентификатора на зоната от първата. Заменете го със своя идентификатор; заместителят по-горе умишлено не е истински.

Защо частната зона печели

Свързването е това, което прави зоната видима за VPC, а Resolver-ът в тази VPC го прилага. Частна зона, която не е свързана с VPC-то, от което идва трафикът на клиента, няма никакъв ефект, докато свързване с грешното VPC дава частен отговор на грешната популация. Проверете списъка със свързвания, преди да редактирате записи, защото една зона може да е правилна и все пак невидима.

Припокриващите се пространства от имена са вторият източник на объркване. Частна зона за example.net и частна зона за api.example.net и двете съвпадат със заявка към API и отговаря по-специфичната. Това е полезно, когато искате тясно вътрешно пространство от имена, и опасно, когато в тясната зона липсва запис, който по-широката има. Съображенията за частни хоствани зони в документацията на Route 53 описват както поведението при преминаване надолу, така и приоритета на правилата, и си струва да ги прочетете, преди да добавите втора припокриваща се зона.

Нищо от това не променя публичната зона. Публичните resolver-и все още отговарят правилно на публичните записи и точно затова за всички извън VPC-то проблемът изглежда като проблем на клиента.

Изберете пространството от имена, преди да добавяте записи

Ако само нова група вътрешни услуги се нуждае от частни имена, дайте ѝ отделен частен поддомейн и оставете публичния родител непокътнат. Име като internal.example.net не може да засенчи www.example.net, а радиусът на поражение от липсващ запис е ограничен до имената, които сте измислили за целта. Цената е, че съществуващите URL адреси и сертификати може да не съвпадат с новото име.

Когато публичните и частните потребители трябва да запазят едно и също име на хост, DNS с разделен изглед е поддържаният дизайн и изисква да поддържате записите във всеки изглед изрично. Широка частна зона с един запис в нея не запазва публичните зависимости под тази зона; тя ги заменя със зона, която има един запис.

Направете опис на имената, които приложението наистина извиква, преди да насочите популация от клиенти към частния изглед. Хостовете за вход, хостовете за статични ресурси, целите за пренасочване и крайните точки на API се чупят първи и обикновено са разпръснати из записите на няколко екипа.

Проследете пътя на resolver-а, после маршрута

Лаптоп вижда частния изглед само ако заявките му достигат до resolver-а със свързването. Редактирането на файл hosts на VPN сървъра не публикува нищо към свързаните клиенти, а клиент, конфигуриран с публичен resolver, ще продължава да получава публични отговори, докато тунелът е вдигнат. Потвърдете адреса на resolver-а, който клиентът е получил, после повторете заявката от клиента, а не от сървъра.

След като името се реши, проверете пътя до върнатия адрес като отделна стъпка, например с ip route get срещу адреса, който заявката е върнала. Правилен частен отговор без маршрут до адреса е проблем с маршрутизацията, а отговорът за липсващ запис е проблем с изгледа на DNS; ако ги третирате като един проблем, поправките не издържат. Оставете проверките на TLS името на хоста и сертификата непроменени, защото частният адрес променя накъде отива връзката и нищо относно това кой сертификат е валиден.

Завършете, като запишете в бележката за промяната зоната, свързването, resolver-а и имената, които сте проверили. Тогава следващият човек, който добави запис, ще знае кое пространство от имена е меродавно за тази популация от клиенти.