Зашто приватна зона 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 и имена која сте проверили. Тада ће следећа особа која дода запис знати који је именски простор меродаван за ту популацију клијената.