Зошто приватна зона на 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

Втората команда е важната. Нејзината статусна линија и authority делот ја именуваат зоната што го создала одговорот, така што можете да разликувате негативен одговор од приватната зона од тајмаут, блокиран порт или resolver што никогаш не го добил барањето. resolvectl покажува кој горен сервер бил прашан, и тоа често не е resolver-от што сте претпоставиле дека VPN-от го испратил.

Ако следеното барање го враќа јавниот адрес, а нормалното не, јавниот запис е недопрен и одговара приватниот приказ. Токму таа една споредба одлучува која половина од остатокот на оваа страница се однесува на вас.

Прочитајте која зона одговори

Одговор што носи NXDOMAIN со SOA на приватната зона во authority делот е дефинитивен одговор од таа зона, а не неуспешно пребарување. 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]"

Двете команди бараат акредитиви за сметката што ја поседува зоната, а втората бара ID на зоната од првата. Заменете го со вашиот; заменувачот погоре намерно не е вистински.

Зошто победува приватната зона

Врската е она што ја прави зоната видлива за 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-от и имињата што сте ги потврдиле. Тогаш следната личност што ќе додаде запис ќе знае кој имени простор е меродавен за таа популација клиенти.