Jump to content
Калькуляторы

Как заставить DNS на все запросы отвечать одним адресом ?

Хочется минимизировать количество звонков поступающих на саппорт во время возникновения проблем на внешнем канале.

Для этого на бордерном роутере все запросы на 80-й порт редиректятся на локальный сервер который выводит уведомление

о проблеме и сроках ее решения. Неприятность только в одном, когда ложится внешний канал то и ложится ДНС, и клиентский

веб браузер пишет Host not found.

 

Подскажите, можно ли настроить DNS (bind) чтоб он на все запросы отвечал одним адресом ?

Share this post


Link to post
Share on other sites

а что еще делать когда до обоих провайдеров оптика в одной канализации и ее одновременно рубанули ?

Share this post


Link to post
Share on other sites

Хочется минимизировать количество звонков поступающих на саппорт во время возникновения проблем на внешнем канале.

Для этого на бордерном роутере все запросы на 80-й порт редиректятся на локальный сервер который выводит уведомление

о проблеме и сроках ее решения. Неприятность только в одном, когда ложится внешний канал то и ложится ДНС, и клиентский

веб браузер пишет Host not found.

 

Подскажите, можно ли настроить DNS (bind) чтоб он на все запросы отвечал одним адресом ?

zone "." {

type master;

file "zdravstvuy.zhopa";

};

?

Share this post


Link to post
Share on other sites

а в zdravstvuy.zhopa запись вида

 

* A 1.2.3.4

 

?

В zdravstvuy.zhopa - стандартное содержимое файла зоны для bind (ессно, с поправками на то, что домен зовется "."), а уже в нем - да, вышепроцитированное.

Share this post


Link to post
Share on other sites

А зачем танцы с DNS, когда можно прекрасно переложить информирование на Asterisk.... база абонентов есть, адреса аварий есть, предполагаемое время устранения известно. Определили, выдали нужную инфу. Если клиенту мало после информирования и 20 секунд дополнительного ожидания выплюнули в общую очередь звонков

Share this post


Link to post
Share on other sites

Это плохая идея.......

Дело в том, что многие ОС имеют кеш ДНС сутки и более, и в итоге получим ситуацию, когда после починки внешки ВСЕ клиенты так и продолжат ходить на 1.2.3.4

Share this post


Link to post
Share on other sites

Это плохая идея.......

Дело в том, что многие ОС имеют кеш ДНС сутки и более, и в итоге получим ситуацию, когда после починки внешки ВСЕ клиенты так и продолжат ходить на 1.2.3.4

Ну перегибать палку-то не нужно, практически в любой более-менее актуальной OS resolver кеширует записи исходя из TTL (который в этой "аварийной" зоне, по понятным причинам, должен быть выставлен на минимум). На память из неадекватов разве что могу припомнить ISA Server 2000, в котором, если не изменяет склероз, в dns-кеш на сутки попадали любые записи несмотря на TTL. И то этот "беспредел" поправлялся через реестр обычно первым же.

Так что workaround вполне жизнеспособный, хотя и не идеальный, безусловно.

Share this post


Link to post
Share on other sites

Ну вот, предположим, такое угребище как макстрон - кеширует вообще на неделю....

Причем flushdns на него не действует.....

Share this post


Link to post
Share on other sites

На кешированные записи клиенты будут ходить не только после починки, но и первое время после поломки.

Поэтому, нет смысла. К тому же, это подмена содержимого.

Share this post


Link to post
Share on other sites

Ну вот, предположим, такое угребище как макстрон - кеширует вообще на неделю....

Причем flushdns на него не действует.....

Ну по таким "приложеньицам" пользователь ССЗБ, как говорится, "сдуру можно и ... сломать". С maxthon дела не имел, но не исключаю что кнопка "очистить кеш" у него все же имеется.

Share this post


Link to post
Share on other sites

На кешированные записи клиенты будут ходить не только после починки, но и первое время после поломки.

Поэтому, нет смысла. К тому же, это подмена содержимого.

"будут ходить на уже кешированные" - не критично, топик стартер и так делает "на бордерном роутере все запросы на 80-й порт редиректятся на локальный сервер который выводит уведомление о проблеме и сроках ее решения". Сложности скорее будут (в случае наличия) у корпоратов и "особо продвинутых", которые используют собственный dns-сервер без рекурсии на dns isp. Но тут уж только 53 на свой dns на пару с 80 заворачивать.

Что касается "подмены" - тут уже вопрос юристам, в принципе сложности возможны. Ну и для "смягчений" эффекта, естественно, имеет смысл на "целевом" веб-сервере сначала сделать 302 редирект на свой сайт, дабы не возбуждать особо нервных :)

Share this post


Link to post
Share on other sites

сначала сделать 302 редирект на свой сайт, дабы не возбуждать особо нервных :)

Вот за 302 меня студенты и хотели убить. Сделал такое при открытытии странички в инете, когда абоненту досту закрыт.

 

проблема в том, что сайт, на который ты полз забывается. Только что открытая опера теряет все вкладки, кнопка назад не работает.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

А что делать абоненту, единожды отрезолвившему mail.ru в адрес 1.2.3.4 и НЕДЕЛЮ помнящему его?

Share this post


Link to post
Share on other sites

ТТL в аварийной зоне выставлять по минимуму.

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

Share this post


Link to post
Share on other sites

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

Cуть 404 страницы состоит как-раз в том, что ее вроде-бы не надо помнить :)

А вообще, IMHO, процитированный случай это проблема некорректно настроенного кеширования - и пользователю просто надо подсказать где поставить правильную галочку.

 

Share this post


Link to post
Share on other sites

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

Cуть 404 страницы состоит как-раз в том, что ее вроде-бы не надо помнить :)

А вообще, IMHO, процитированный случай это проблема некорректно настроенного кеширования - и пользователю просто надо подсказать где поставить правильную галочку.

давайте предположим, что пользователей 80 тыс.

Всего у 3% стоят невероятного происхождения приблуды, кеширующие DNS :)

Вам сапорт в борщ срет ежедневно, Вы за это хотите его живьем растворить в соляной кислоте (слюнях абонентов) ? :)

 

Вы скорее всего не поняли смысла топика.

Кешируется не страница, а резолв имени в адрес 1.2.3.4

Share this post


Link to post
Share on other sites

Вы скорее всего не поняли смысла топика.

Кешируется не страница, а резолв имени в адрес 1.2.3.4

Ну не знаю... У нас давно работает нечто подобное и никаких проблем ни разу не возникало. Максимум - требуется перезапустить браузер.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.