Уровень DNS с обнаружением службы в качестве преобразователя, а не SRV
Мне нужно знать, есть ли какое-нибудь решение моей проблемы. У меня есть DNS-сервер BIND и консул в качестве исследователя услуг. Вот что я хочу в виде простой диаграммы:
Как я могу настроить этот пример настройки и позволить BIND просто преобразовать запись A в IP-адрес исправного сервера балансировки нагрузки?
Если клиент запрашивает у DNS-сервера запись A для domain.example, он должен получить IP-адрес Здоровый (192.168.1.100) сервер
Пример конфигурации consul для DNS показывает, как настраивать записи SRV, а не записи A. Как я могу заставить его работать с записями A для исправного сервера.
Мне нужно указать запись запроса от консула, но как? Мой пример файла зоны:
$TTL 300 ;
$ORIGIN example.com.
@ 1D IN SOA ns1.example.com. hostmaster.example.com. (
2002022401 ; serial
3H ; refresh
15 ; retry
1w ; expire
3h ; nxdomain ttl
)
www IN A 192.168.0.2 ; how can i tell bind using consul as IP resolver on this record
consul использует порт для разрешения, и как я могу указать bind использовать consul вместо него.
Я считаю, что все слишком сильно сосредотачиваются на сервере BIND. Согласно документации Consul, вам нужен только BIND для пересылать DNS-запросы с порта 53 на порт 8600, который использует Consul. Consul - это DNS-сервер в этой настройке.
Консул использует чеки чтобы определить, какой из двух (или более) серверов является «исправным».
Затем он может ответить обе записи A и SRV как видно в документации.
Поэтому вместо того, чтобы просить нас прочитать всю документацию Consul и придумать для вас рабочую конфигурацию, почему бы вам не предоставить нам свои файлы конфигурации и не сообщить нам, что работает не так, как ожидалось. Так нам будет проще решить возникшую проблему.
Мне нужно указать запись запроса от консула, но как?
Ответ на этот точный вопрос дается в документация! ПОЖАЛУЙСТА, прочтите документацию!
Что ж ... к сожалению, вам будет нелегко сделать это на производстве.
50% проблемы заключается в обновлении «исправных» записей, чтобы они указывали на исправный сервер. Есть способы делать динамические обновления с помощью bind, но, к сожалению, нет способа убедить bind выполнить какие-то проверки, чтобы увидеть, исправен ли сервер. Вам нужно будет найти способ инициировать динамическое обновление при достижении состояния работоспособности / неработоспособности.
50% проблемы тоже кеширование. На самом деле DNS предназначен для кэширования. В записях DNS есть определенное поле "TTL", которое, по сути, является определенным временем для кэширования записи. Когда вы обновляете «работоспособные» записи, клиенты будут вынуждены ждать, пока не будет достигнут TTL, и записи будут запрошены повторно. В некоторых приложениях есть встроенный метод, который будет пытаться повторно запросить запись, если соединение разорвано или не может быть установлено, но нет гарантии, что это будет сделано.
Было бы лучше использовать правила брандмауэра, чтобы отклонять соединения на неработоспособном сервере, и просто полагаться на DNS-сервер для объявления обоих серверов и позволять приложению пробовать один, затем другой (циклический).