Почему приватная зона 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

Вторая команда — важная. Её строка состояния и раздел authority называют зону, создавшую ответ, поэтому вы можете отличить отрицательный ответ из приватной зоны от тайм-аута, заблокированного порта или резолвера, который так и не получил запрос. resolvectl показывает, какой вышестоящий сервер был опрошен, и часто это не тот резолвер, который, как вы предполагали, передал VPN.

Если трассируемый запрос возвращает публичный адрес, а обычный нет, публичная запись цела и отвечает приватное представление. Именно это единственное сравнение решает, какая половина остальной части этой страницы относится к вам.

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

Ответ, несущий NXDOMAIN с SOA приватной зоны в разделе authority, — это окончательный ответ этой зоны, а не неудачный поиск. Route 53 Resolver выбрал приватную размещённую зону, потому что имя совпало, затем не нашёл записи запрошенного типа, и документированное поведение состоит в том, чтобы вернуть отрицательный ответ, а не передавать вопрос в публичный 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]"

Обеим командам нужны учётные данные аккаунта, которому принадлежит зона, а второй нужен ID зоны из первой. Подставьте свой собственный; заполнитель выше намеренно не настоящий.

Почему побеждает приватная зона

Именно связь делает зону видимой для 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-имени хоста и сертификата сервиса без изменений, потому что приватный адрес меняет, куда идёт соединение, и ничего в том, какой сертификат действителен.

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