Приватно име се разрешава са EC2 инстанце, али не са лаптопа повезаног преко VPN-а, а зона у конзоли изгледа исправно. Први нагон је да уредите запис, што скоро никада није проблем. Запис одговара некоме; само не одговара вашем лаптопу. Оно што се разликује између два позиваоца јесте који resolver питају и има ли тај resolver подржану путању у DNS приказ унутар VPC-а.

Почињем тако што докажем да запис постоји, а остатак времена проводим на путањи упита. То су одвојени системи и отказују на различите начине.

Прочитајте облик квара пре него што било шта промените

Три исхода значе три различите ствари, а један упит их разликује: покрените dig за име према resolver-у који клијент заиста користи.

What you seeWhat it usually meansFirst thing to check
SERVFAIL, or a timeout after several secondsNo path to the resolver, or the resolver cannot reach AWSRoute to the endpoint and the security policy on port 53
NXDOMAIN from a resolver that did answerThe resolver replied, but the zone is not in its viewZone association or the forwarding rule for that namespace
A public address for an internal nameSplit DNS is not in effect for this clientWhich resolver the client is configured to use

Временско ограничење је изјава о мрежи. NXDOMAIN је изјава о DNS приказу. Јавни одговор је изјава о политици. Уређивање записа зоне док траје временско ограничење одбацује једини користан доказ у случају.

Зашто адреса плус два у VPC-у није удаљени resolver

Адреса CIDR плус два је локална услуга за ресурсе унутар VPC-а. AWS документује да прослеђивање упита из локалних мрежа, или са DNS сервера другог VPC-а, директно на ту адресу није подржано и може давати нестабилне резултате.

То не значи да експеримент никада не изгледа да ради. Значи да понашање није уговор који можете ставити у скрипту подршке. Подржани смер је долазни Resolver endpoint: пар адреса унутар вашег VPC-а, доступан из мреже коју контролишете, који прихвата упите који долазе изван AWS-а.

Изградите путању редоследом у којем чисто отказује

Морају постојати три скока, а сваки има свој начин отказивања.

VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addresses

Прослеђивач треба руту до адреса endpoint-а кроз VPN, а повратна путања такође мора да ради. За класични DNS на порту 53 endpoint одговара преко UDP-а и TCP-а, па оба протокола морају бити дозвољена и оба морају преживети сваки надзор стања на путу.

Затим проверите DNS приказ одвојено. Приватна хостована зона видљива је само VPC-овима са којима је повезана, или кроз намерни договор о дељењу. Доступан endpoint сам по себи не чини сваку приватну зону разрешивом у њеном контексту разрешавања.

Одлазни endpoint служи супротном смеру и неће одговорити на упит који долази са вашег лаптопа.

Проверите са оба краја

Питајте са клијента према прослеђивачу, затим са прослеђивача према endpoint-у. Ако клијент откаже док прослеђивач успе, размак је између та два.

Ако оба откажу, погледајте безбедносну политику на endpoint-у и изворну адресу коју заиста види. Прослеђивач иза NAT-а представља NAT адресу уместо VPN адресе лаптопа, а сама та разлика довољна је да упит пропадне. Ако оба успеју, али апликација и даље отказује, могуће је да апликација користи други resolver од онога који сте тестирали.

Држите јавне и приватне просторе имена намерно одвојене. Split DNS је политика коју конфигуришете, а не нуспојава тога да један упит случајно врати податке.

Шта не бих урадио

Не бих додао NAT правило које је оспособило један упит и то назвао дизајном.

Не бих све удаљене клијенте усмерио на адресу плус два само зато што је један тест једном вратио запис. И не бих проширио безбедносну политику endpoint-а на цео VPN базен кад приступ треба један прослеђивач. Ако организација већ води одобрени прослеђивач унутар VPC-а, прво прочитајте тај дизајн, јер је друга endpoint адреса коју додате она коју нико не документује.

Повезани чланци