Поддомен для VPN-сервера. A-записи

Доброго времени суток!
Есть такой умопомрачительный вопрос.
Существует VPN сервер с тремя интерфейсами. Соответственно eth0 - основной канал, eth1 - резервный канал, eth2 - локальная сеть. Есть скрипт, который очень замечательно работает включая вовремя резервный канал, или переключая его обратно на основной, когда тот поднимется. Оба канала это разные операторы связи, каждый со статикой. Пользователи по умолчанию подключаются к основному внешнему IP и чудесно работают с 1С сервером, который сидит в локальной сети. Если вдруг планеты выстраиваются в определенную линию и основной канал связи перестает работать, скрипт быстро это дело переиначивает на резервный, VPN подключение у пользователей говорит: "Не хочу работать" и догадливые пользователи идут на второе ВПН подключение, которое ломится на IP адрес резервного канала. А вот не особо догадливые пытаются в течение N-ного времени подрубиться по основному подключению.
Вот и возникла следущая идея. У нас есть домен domen.ru
Почему бы не создать две DNS записи типа A для vpn.domen.ru. Т.е. одна запись с указанием основного IP и вторая запись с указанием резервного IP. К примеру как сделано у yandex.ru
НО на практике оказалось вот что. При создании двух A записей для vpn.domen.ru и при выполнении команды
#dig vpn.domen.ru
;; ANSWER SECTION:
vpn.domen.ru. 594 IN A резервный IP

Потом к примеру дожидаемся 10 минут и опять дигаем, смотрим:
#dig vpn.domen.ru
;; ANSWER SECTION:
vpn.domen.ru. 597 IN A основной IP

Ждем еще некоторое время, дигаем и опять вдием только одну запись основного IP. Т.е. по факту они меняются абсолютно в рандомном порядке, а вот одновременно не работают....
Люди добрые, подскажите, КАК сделать так, чтобы отображались две A записи постоянно??

McPetrovich написал:

КАК сделать так, чтобы отображались две A записи постоянно??

что значит постоянно? они и будут работать постоянно, только обращение будет рандомным.
если вам нужно чётко знать куда обращаться, необходимо создать две записи, скажем main и reserve.domen.ru и уже по обстоятельствам отправлять туда куда нужно клиентский запрос.

#dig ya.ru
;; ANSWER SECTION:
ya.ru. 6111 IN A 93.158.134.3
ya.ru. 6111 IN A 213.180.204.3
ya.ru. 6111 IN A 77.88.21.3
ya.ru. 6111 IN A 87.250.250.3
ya.ru. 6111 IN A 87.250.251.3

Вот что я имею ввиду. А если сделать main и reserve, то получится таже котовасия, что и с IP адресами. Т.е. те же самые два подключения у пользователей. А надо одно! с указанием только одного адреса vpn.domen.ru в случае, когда основной канал отвалился - у них подключение тоже отвалилось и само переподключилось на себя же, только тут уже будет адрес назначения другой IP - т.е. резервный.

root@msy:/etc/bind# dig domain.ru

; <<>> DiG 9.7.1-P2 <<>> domain.ru
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59631
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;domain.ru. IN A

;; ANSWER SECTION:
domain.ru. 604800 IN A 192.168.0.103
domain.ru. 604800 IN A 192.168.0.102

;; AUTHORITY SECTION:
domain.ru. 604800 IN NS localhost.

;; ADDITIONAL SECTION:
localhost. 604800 IN A 127.0.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Sep 20 18:36:17 2010
;; MSG SIZE rcvd: 98

root@msy:/etc/bind#

вам это надо? ну так как вы будите контролировать к какому ip пошли? они получаются в ответ рандомно ещё раз говорю.
это для снижения нагрузки на сервера придумано. сама технология DNS не позволяет получать в ответ 2 ip, потому, что клиентский софт не должен думать какой из них выбрать.

Все. Теперь все понятно. По факту если мы пингуем наш vpn.domain.ru, то получаем грубо говоря каждый раз ответ от разных узлов.... Нельзя сделать так, чтобы если один из узлов недоступен, то ответ шел только от рабочего, получится, что ответы будут через однин пустые, ну т.е. заданный узел недоступен.... Блин smile Каким бы макаром это все осуществить через домен....

DDNS вам в руки.