Не забывайте про кеширующие DNS провайдера. Где и как перемешаются
эти записи никто не знает. Если в стандарте не оговорено, никто
выполнять и гарантировать ничего не будет.
_interceptor_ добавил 17.03.2009 в 12:59
Даже больше скаже ip адрес выбирает не DNS клиент, а само приложение :)
http://www.rfc-editor.org/rfc/rfc1034.txt
DNS клиент просто отдает все что нашел.
Несколько A записей не гарантирует вам порядок обращения к хостерам,
т.е.
test.ru. A 1.1.1.1
test.ru. A 2.2.2.2
не означает, что сначала пробуется на 1.1.1.1, а потом 2.2.2.2
_interceptor_ добавил 17.03.2009 в 12:38
Вообще-то помимо отношения bind к таким конструкциям, есть
еще поведение клиента :)
Если вы мне в rfc найдете, где регламентируется порядок
обращения по ip адресам в таких конструкциях, буду благодарен.
Andris, Fast Flux самое модное применение, это точно :)
Кстати, прикольные демонстрации Fast Flux в yandex находил в виде
флешек, сейчас к сожалению не нашел :(
Но во в старые добрые врмена так делали балансировку.
Т.е. у вас два хостинга с одинаковым контентом и вы хотите
чтобы test.ru смотрел одновременно на два хостинга?:)
Не понял цель...
Нет, так делают в целях балансировки нагрузки, только вам надо
будет поставить
TTL в 1 секунду и постоянно менять
ip адреса у A записи,
тогда клиент будет работать с разными хостерами попеременно,
понятно, что возникнут проблемы с куками.
Можно TTL сделать больше, а частоту смены ip оставить 1 секунду,
тогда с куками будет проще, но все равно будут проблемы.
Но все это извращения, зачем вам это?
У вас два хостинга, у первого адрес 1.1.1.1 и имя test.ru , алиас www.test.ru,
у второго адрес 2.2.2.2 и имя test.test.ru, алиас www.test.test.ru.
Если вы можете редактировать самостоятельно зону вашего
домена test.ru, то в этой зоне вы должны сделать 4 записи:
...
www.test.ru. A 1.1.1.1
test.test.ru. A 2.2.2.2
www.test.test.ru. A 2.2.2.2
Я думал, что у вас будет ошибка два ns в одной подсети...
Где там могут быть не найдены ip адреса не понимаю,
т.к. ip адреса этих серверов вы должны указать еще при заказе
изменений:
ns2.мой_домен ip_адрес_ns2_провайдера
ns1.мой_домен ip_адрес_ns1_провайдера
Если ns-ы находятся внутри зоны самого домена, то указание ip адресов обязательно
Кого интересует наличие контента на освобождаемом
или освобожденном домене RU/SU могут посмотреть
тут http://dnhunter.ru/, колонка 'конент' нажав на эту ссылку можно
посмотреть первую станицу сайта без мультимедиа. (пример http://dnhunter.ru/cgi-bin/get_hist.pl?domain=DIVN.RU) Если
зайти в детали домена иногда доступен скриншот первой страницы от
Thumbshots previews
пример
http://dnhunter.ru/cgi-bin/domain_info?domain=DIVN.RU
Тут же чекается наличие контента в вебархиве и в кэше google.
Так что возможностей восстановить контент масса.
Смотрите, выбирайте домен, заказывайте у ТС восстановление.
Собственно, как всегда ру-центер делает предварительные заказы:
"
С 16 марта 2009 года RU-CENTER начнет принимать предварительные заказы на регистрацию доменных имен в домене TEL. Оформив предварительный заказ, Вы можете повысить свои шансы на регистрацию интересующего Вас домена.
Если Ваша заявка окажется единственной, то 24 марта (дата начала открытой регистрации) домен будет зарегистрирован на Ваше имя.
Если на один и тот же домен поступит несколько заказов, то он будет выставлен на аукцион, и все заявители смогут принять участие в закрытых торгах за право администрирования доменного имени.
:D
http://www.nic.ru/news/2009/pre_order-TEL.html
Кому как, я смогу это сделать, вы тоже, по всей видимости, а другие
талантливы в другой области. :)
Ваш вариант хорош, но что нужно Оксигену, знает только он.
Я кстати хотел пойти по вашему варианту чтобы провести некоторый эксперимент с DNS и осв. доменами... но нету времени(! и это при условии, что я знаю что делать).
Такие варианты я, конечно, не рассматривал, но не спорю, возможно. :)
Но согласитесь, это достаточно уникальное событие ... из разряда а сколько еще не предусмотрено.
В конце концов можно и primary тогда у ru-центер заказать и отказаться
от брендованых ns-ов.
