☰

DNS-клиент для автоматического поиска записей CNAME

tag-icon • tag-icon domain-name-system internal-dns google-cloud-dns getaddrinfo
DNS-клиент для автоматического поиска записей CNAME

Мы только что перешли на новый внутренний DNS-резолвер и обнаружили ограничение, которое влияет на нашу возможность поиска определенных записей.

Наш внутренний (частный) авторитетный домен — example.net.. У нас есть запись CNAME, service.example.net.которая разрешается вname-1234567890.region.elb.amazonaws.com.

name-1234567890.region.elb.amazonaws.com.разрешается в различные записи A, значения которых управляются AWS. Мы не управляем публичной зоной amazonaws.com, ни записями в этой зоне.

Наш предыдущий DNS-резолвер «гонялся» за записями CNAME, поэтому поиск service.example.net.может вернуть следующее:

$ dig service.example.net
...
;; ANSWER SECTION:
service.example.net.    300 IN  CNAME   name-1234567890.region.elb.amazonaws.com.
name-1234567890.region.elb.amazonaws.com. 26 IN A 10.1.2.3
name-1234567890.region.elb.amazonaws.com. 26 IN A 10.1.2.4

Ответ включает IP-адреса записей A, на которые указывает CNAME. Все хорошо.

Наш новый DNS-резолвер не «гоняется» за записями CNAME. Тот же поиск с новым резолвером выглядит так:

$ dig service.example.net
...
;; ANSWER SECTION:
service.example.net.    300 IN  CNAME   name-1234567890.region.elb.amazonaws.com.

... обратите внимание на отсутствующие записи A. Попытки связаться service.example.netс помощью ping, curl, запросов python и т. д. приводят к сбоям «Неизвестный хост».

Мы не можем изменить поведение нашего нового DNS-резолвера. Есть ли какая-то опция в ядре Linux или локальном DNS-резолвере, чтобы "преследовать" записи CNAME у клиента, так же, как это делал наш старый DNS-резолвер на стороне сервера?

Для контекста, наш новый DNS-резолвер — это GCP cloud-dns, которыйдокументытакое поведение.

Некоторые дополнительные ответы на вопросы контекста/комментарии:

  • example.net. — это частная, внутренняя управляемая зона в облачном DNS, принадлежащая нам.
  • amazonaws.com. — это публичная зона, управляемая AWS.
  • iirc, политика исходящего сервера с дополнительными серверами имен будет отправлятьвсезапросы к этим серверам имен, переопределяющие cloud-dns
  • iirc, записи ALIAS доступны только в публичных зонах, а не в частных.
  • service.exmaple.net. — это запись CNAME в частной управляемой зоне cloud-dns example.net.
  • у нас нет представительства в AWS, поэтому мы не можем использовать route53.

решение1

Вместо прямого указания внутренних IP-адресов балансировщика нагрузки, вам необходимо указать публичное DNS-имя балансировщика нагрузки.

name-1234567890.region.elb.amazonaws.com

Поэтому удалите записи a и измените значение cname на публичное DNS-имя балансировщика нагрузки.

решение2

Я хотел бы предоставить обновление по этому вопросу. После обнаружения этой проблемы GCP начал развертывание экспериментальной функции для cloud-dns, которая отслеживает публичные записи CNAME. На момент написания статьи (апрель 2024 г.) эту функцию нужно было явно запросить у службы поддержки GCP. Я не уверен, когда она станет общедоступной.

До того, как эта функция стала нам доступна, мы обошли эту проблему, создав частную зону пересылки, например, amazonaws.comв нашем cloud-dns, которая пересылает на публичные DNS-резолверы (мы используем 8.8.8.8, 1.1.1.1 и т. д.). Это работает, поскольку отслеживание CNAME включено в cloud-dns между частными зонами. Поскольку amazonaws.comтеперь cloud-dns считает это частной зоной, запросы на отслеживание CNAME теперь разрешаются нормально.

решение3

Для разрешения записей aws я бы рекомендовал изучить route53 из aws. Вы можете разрешить вашему внутреннему серверу DNS пересылать запросы на route53, например unbound — это DNS-revolver, который может это сделать.

Amazon Route 53 — это масштабируемая и высокодоступная веб-служба Domain Name System (DNS), предоставляемая Amazon Web Services (AWS). Она эффективно преобразует удобные для пользователя доменные имена, такие как example.com, в IP-адреса, которые компьютеры используют для идентификации друг друга в Интернете. Вот обзор некоторых ключевых функций и концепций Route 53:

  • Регистрация домена: Route 53 позволяет вам регистрировать и управлять доменными именами. Вы можете приобрести новые домены или перенести существующие на Route 53.
  • DNS Service: Route 53 выступает в качестве поставщика DNS-услуг, позволяя вам управлять записями DNS для вашего домена. DNS-записи включают в себя такие вещи, как записи A (которые сопоставляют доменные имена с IP-адресами), записи CNAME (которые сопоставляют доменные имена с другими доменными именами), записи MX (которые указывают почтовые серверы) и многое другое. Проверки работоспособности и отказоустойчивость: Route 53 может выполнять проверки работоспособности ваших конечных точек, таких как веб-серверы, и автоматически перенаправлять трафик с неработоспособных конечных точек на работоспособные. Эта функция часто используется для реализации решений по отказоустойчивости и аварийному восстановлению.
  • Управление трафиком: Route 53 предлагает возможности управления трафиком, позволяя вам контролировать маршрутизацию DNS-запросов на основе различных факторов, таких как задержка, геолокация, взвешенная маршрутизация и т. д. Это позволяет оптимизировать производительность и доступность ваших приложений. Интеграция с сервисами AWS: Route 53 легко интегрируется с другими сервисами AWS, такими как Amazon S3, Elastic Load Balancing (ELB) и Amazon CloudFront. Например, вы можете использовать Route 53 для маршрутизации трафика на ваши балансировщики нагрузки ELB или дистрибутивы CloudFront.
  • DNSSEC: Route 53 поддерживает DNS Security Extensions (DNSSEC), что добавляет дополнительный уровень безопасности вашей DNS-инфраструктуре с помощью цифровой подписи записей DNS. В целом, Route 53 — это универсальная и надежная служба DNS, которая обеспечивает основу для маршрутизации трафика к вашим приложениям и службам в Интернете. Она предлагает расширенные функции для управления DNS, повышения производительности и обеспечения высокой доступности.

Связанный контент