Уровень DNS с сервисом обнаруживается как решатель, а не SRV

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

Как я могу настроить этот пример настройки и позволить BIND просто разрешить запись A в IP-адрес исправного сервера балансировки нагрузки?

Если клиент запрашивает у DNS-сервера запись A domain.example, он должен получить IP-адрес здорового (192.168.1.100) сервер

Пример конфигурации файла cons для DNS показывает, как настраивать записи SRV, а не записи A. Как я могу заставить его работать с записями A для здорового сервера.

Мне нужно сказать bind ask record от консула, но как? Мой пример файла зоны:

$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

консул использует порт для разрешения и как я могу сказать связать использовать консул вместо этого.

Источник

2 ответа

Я считаю, что все слишком сосредоточены на сервере BIND. Согласно документации Consul, вам нужно только BIND для пересылки DNS-запросов с порта 53 на порт 8600, который использует Consul. Консул является DNS-сервером в этой настройке.

Консул использует проверки, чтобы определить, какой из двух (или более) серверов является (является) "здоровым".

Затем он может отвечать записями A и SRV, как видно из документации.

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

Мне нужно сказать bind ask record от консула, но как?

Ответ на этот точный вопрос приведен в документации! ПОЖАЛУЙСТА, прочтите документацию!

Источник

Ну... грустно сказать, вам будет тяжело делать это на съемках.

50% проблемы заключается в обновлении "исправных" записей, чтобы они указывали на исправный сервер. Существуют способы выполнения динамических обновлений с помощью bind, но, к сожалению, нет способа убедить bind в необходимости каких-либо проверок, чтобы проверить работоспособность сервера. Вам нужно будет найти способ вызвать динамическое обновление при достижении здорового / нездорового статуса.

50% проблемы тоже кеширование. Реальность такова, что DNS предназначен для кэширования. В DNS-записях есть определенное поле "TTL", которое, по сути, является определенным временем для кэширования записи. Когда вы обновляете "здоровые" записи, клиенты будут вынуждены ждать, пока не будет достигнут TTL, и записи будут запрошены. Некоторые приложения имеют встроенный метод, который будет пытаться повторно запросить запись, если соединение разорвано или не может быть установлено, но нет гарантии, что это будет сделано.

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

Источник
Другие вопросы по тегам