Чому приватна зона 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-імені хоста та сертифіката сервісу без змін, бо приватна адреса змінює, куди йде з’єднання, і нічого в тому, який сертифікат дійсний.

Завершіть, записавши в нотатці про зміну зону, зв’язок, резолвер і перевірені імена. Тоді наступна людина, яка додає запис, знатиме, який простір імен є авторитетним для цієї аудиторії клієнтів.