Помогите настроить отказоусточивость

И который провайдеры закешируют на два часа

Andreyka, ну когда вы эту ерунду прекратите распространять?

Cлучай с кешированием довольно редкий. Я вообще не встречал лично подобного.

Вы же переносите свои или чужие сайты? Вот и сделайте эксперимент : заранее измените TTL на не самом маленьком сайте, потом быстро и без ошибок измените записи в DNS и смотрите в логи на старом сервере - вы удивитесь. Реально все клиенты следуют TTL. Под настройкой без ошибок я понимаю действительно вообще без ошибок, а не как обычно. Включая даже случаи, когда вы переносите домен от провайдера и хостинга и доступа в интернет, и забыли его об этом уведомить Если кто-то не следует, то по IP и user-agent попытайтесь понять кто это. Если там кто-то и будет долбить, это спамеры и проч. Всякие там клиентские оптимизаторы интернета идут лесом тоже.

Редкий, но меткий.

В далеком 2006 пользовался услугами неадекватного спутникового провайдера (за неимением альтернатив), так вот, у него резолверы кешировали ответы фиксированно на 4 суток.

Но это исключительный случай неадекватности, там и по 25-30k абонентов вешали на один транспондер в 80 Мбит, при том предоставляя тарифы вплоть до 5 Мбит на аккаунт, хотя по факту на них 20 Кбит увидеть было за счастье = )

esetnod, не факт что так и было. Не исключены ошибки при переносе. Потому что честный TTL в зоне .RU в данный момент как раз четверо суток.

Если сервер провайдера запомнил где находятся старые сервера, он так и будет опрашивать старые. Этот TTL владелец домена сменить не может. Но может действовать зная об этой особенности.

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

Я давно пользуюсь ttl для отказоустойчивости и встречаюсь с такой проблемой.

Андрейка всецело прав в одном: DNS RR - это поулмера. Это ни что иное как "полуотказоустойчивость". Какой в этом смысл? Хороших показателей в работе RR можно достигнуть лишь на доволньо большом числе айпи в "карусели", например 5-10, тогда даже в случае кэша вероятность, что пострадает довольно серьезное число клиентов - минимальна. Защита должна быть многоступенчатой. Иным исловами, RR подходит лишь как первая линия обороны, например, на время, пока иными протоколами другая машина займет IP отказавшей.

netwind, нет, там был именно неадекватный резолвер, который кешировал всё на 4 суток, невзирая на ttl.

Насчет браузеров, firefox, например, умеет даже в рамках одной одной сессии делать резолв несколько раз.

Пример: сайт и 4 узла, соответственно ссылается на 4 IP, спрашиваем какую-нибудь страничку, как видно, все элементы подсасывает почти равномерно.

У нас ттл проставлен в 300 секунд

Однако слушают его 0 днс серверов (хорошо проверяется хосттрекером).

Через час меняют, от 1 часа до 12 часов, а где-нибудь в куала-лумпуре до двух суток.

Самый простой вариант - бгп фейловер и два дц соединенные. Правда менеджить сплитбрейн придется если вдруг внезапно связность между дц пропадет

При этом все равно пользуетесь? Так стоит ли пользоваться или нет? Почему так противоречиво ?

---------- Добавлено 14.03.2012 в 17:56 ----------

Это при том, что bind НЕТ настройки для игнорирования TTL ? Скорее всего дело в другом. С чего вы вообще взяли, что хосттрекер такой же как нормальные клиенты.

---------- Добавлено 14.03.2012 в 18:00 ----------

по картинке ничего не видно. Если там уже несколько IP для одной записи, то запрос к разным серверам может происходит и в рамках одного единственного резолва.

Резолвов несколько, используется первый ip из каждого.