Чаму прыватная зона Route 53 вяртае NXDOMAIN для публічных імёнаў

Прыватныя зоны Route 53 замяняюць адказ для імені, а не аб’ядноўваюць яго з публічным запісам, і гэта застае людзей знянацку ў самы неадпаведны момант. Дадайце адзін унутраны запіс для api.example.net у прыватнай зоне для example.net, звяжыце яе з VPC, і ўсе астатнія імёны пад гэтым бацькам цяпер адказваюць толькі з прыватнай зоны. Кліент, які мог дасягнуць www.example.net учора, сёння атрымлівае адмоўны адказ. Ніжэйшы разбор пачынаецца з гэтага няўдалага запыту і ідзе вонкі да зоны, якая на яго адказала.

Пачніце з запыту, а не з кансолі

Узнавіце збой на тым кліенце, які яго паведаміў, і запішыце дакладнае імя і тып запісу. Імя, якое не працуе для A можа ўсё яшчэ вырашацца для AAAA, а браўзер, які паўторна запытвае закэшаванае імя, хавае, што менавіта зламалася. Выканайце запыт двойчы: адзін раз праз рэзалвер, які кліент фактычна выкарыстоўвае, і адзін раз з трасіроўкай, якая яго абыходзіць.

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

Другі загад — галоўны. Яго радок стану і раздзел паўнамоцтваў называюць зону, якая вырабіла адказ, таму вы можаце адрозніць адмоўны адказ з прыватнай зоны ад тайм-аўту, заблакаванага порта або рэзалвера, які так і не атрымаў запыт. resolvectl паказвае, які вышэйшы сервер быў запытаны, і часта гэта не той рэзалвер, які, як вы меркавалі, прадставіў VPN.

Калі трасіраваны запыт вяртае публічны адрас, а звычайны не вяртае, публічны запіс цэлы, і адказвае прыватны прагляд. Гэта адзінае параўнанне вызначае, якая палова астатняй старонкі да вас датычыцца.

Прачытайце, якая зона адказала

Адказ з NXDOMAIN і SOA прыватнай зоны ў раздзеле паўнамоцтваў — гэта пэўны адказ ад гэтай зоны, а не збой пошуку. Рэзалвер Route 53 выбраў прыватную кіруемую зону, бо яе імя супала, затым не знайшоў запісу патрэбнага тыпу, і дакументаваныя паводзіны — вярнуць адмоўны адказ замест перадачы пытання ў публічны DNS.

Выбар ідзе за канкрэтнасцю. Калі некалькі прыватных прастораў імёнаў перакрываюцца, перамагае найбольш канкрэтная зона, якая супала, і шырэйшы прыватны бацька не атрымлівае другога шанцу для імені, якога няма ў абранай даччынай зоне. Правілы перасылкі дадаюць яшчэ адзін узровень, бо правіла рэзалвера для канкрэтнага дамена можа перамагчы прывязку прыватнай кіруемай зоны. Пералічыце прывязкі і правілы, перш чым рабіць выснову, што зона пустая.

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, і рэзалвер у гэтай VPC яе ўжывае. Прыватная зона, не звязаная з VPC, адкуль ідзе трафік кліента, не мае ніякага эфекту, а прывязка да няправільнай VPC дае прыватны адказ няправільнай аўдыторыі. Праверце спіс прывязкаў перад рэдагаваннем запісаў, бо зона можа быць правільнай і ўсё роўна нябачнай.

Перакрыццё прастораў імёнаў — другая крыніца блытаніны. Прыватная зона для example.net і прыватная зона для api.example.net абедзве супадаюць з запытам API, і адказвае больш канкрэтная. Гэта карысна, калі патрэбна вузкая ўнутраная прастора імёнаў, і небяспечна, калі ў вузкай зоне няма запісу, які ёсць у шырэйшай. Разважанні пра прыватныя кіруемыя зоны ў дакументацыі Route 53 апісваюць і паводзіны праходу ўніз, і прыярытэт правілаў, і іх варта прачытаць, перш чым дадаваць другую зону, якая перакрываецца.

Нішто з гэтага не змяняе публічную зону. Публічныя рэзалверы па-ранейшаму правільна адказаваюць на публічныя запісы, і менавіта таму для ўсіх па-за VPC збой выглядае як праблема кліента.

Выберыце прастору імёнаў, перш чым дадаваць запісы

Калі прыватныя імёны патрэбныя толькі новай сям’і ўнутраных сэрвісаў, дайце ёй адмысловы прыватны паддамен і пакіньце публічнага бацьку ў спакоі. Імя накшталт internal.example.net не можа зацямніць www.example.net, і радыус уражання ад адсутнага запісу абмежаваны імёнамі, якія вы прыдумалі для гэтай мэты. Кошт у тым, што існуючыя URL і сертыфікаты могуць не супадаць з новым імем.

Калі публічныя і прыватныя карыстальнікі павінны захаваць аднолькавае імя хоста, DNS з падзеленым праглядам — гэта падтрымліваны дызайн, і ён патрабуе, каб вы явна вялі запісы ў кожным праглядзе. Шырокая прыватная зона з адным запісам не захоўвае публічныя залежнасці пад гэтай зонай; яна замяняе іх зонай, у якой ёсць адзін запіс.

Пералічыце імёны, якія дадатак фактычна выклікае, перш чым накіраваць аўдыторыю кліентаў на прыватны прагляд. Хасты ўваходу, хасты статычных рэсурсаў, мэты перанакіравання і канчатковыя пункты API ламаюцца першымі, і яны звычайна раскіданыя па запісах некалькіх каманд.

Прасочыце шлях рэзалвера, затым маршрут

Ноўтбук бачыць прыватны прагляд толькі тады, калі яго запыты дасягаюць рэзалвера з прывязкай. Рэдагаванне файла hosts на VPN-серверы нічога не публікуе падключаным кліентам, і кліент, наладжаны на публічны рэзалвер, будзе атрымліваць публічныя адказы, пакуль тунэль узняты. Пацвердзіце адрас рэзалвера, які атрымаў кліент, затым паўтарыце запыт з кліента, а не з сервера.

Калі імя вырашана, праверце шлях да вернутага адраса як асобны крок, напрыклад з ip route get супраць адраса, які вярнуў запыт. Правільны прыватны адказ без маршруту да адраса — гэта праблема маршрутызацыі, а адказ пра адсутны запіс — праблема прагляду DNS; калі лічыць іх адной праблемай, выпраўленні не трымаюцца. Пакіньце праверкі імя хоста TLS і сертыфіката без змен, бо прыватны адрас змяняе, куды ідзе злучэнне, і нічога не змяняе ў тым, які сертыфікат сапраўдны.

Завершыце, запісаўшы ў нататку пра змену зону, прывязку, рэзалвер і імёны, якія вы правяралі. Тады наступны чалавек, які дадасць запіс, будзе ведаць, якая прастора імёнаў галоўная для гэтай аўдыторыі кліентаў.