balamutang, как минимум убрать поиск на сайте и ассоциации оформления контента, навевающие стойкое ощущение, что это один из из сервисов.
Да, и ещё. Это письмо Вами по каким каналам получено?
Не к серверу, а к AS.
Моей проблемой это и не является, с чего Вы так вообще подумали? Мы здесь обсуждаем вполне себе техническую проблему и каждый васказывает свою точку зрения.
Кеширующий ресолвер провайдера - это клиентское ПО? ☝ Оригинально.
Многие провайдеры просто боятся давать клиентам доступ к подобным настройкам, т.к. клиенты в массе своей действительно не в курсе, зачем это всё. И подобными клиентами такие провайдеры оправдывают фактическую ущербность своих панелей управления тем же DNS. Но они забывают, что многие клиенты периодически или на постоянной основе нанимают специалистов со стороны, которые в итоге и вынуждены мучаться, изобретая костыли.
Хорошим [DNS-]хостером можно назвать того, кто в своей панели предоставляет как минимум два уровня доступа: простой и продвинутый. В простом можно выполнять минимально деструктивный набор действий, а в полном - все традиционно доступные профи. Если такого полного доступа нет, то проще взять и унести зону к себе.
Jet D., он самый. Также сталкивался с неадекватом с его стороны.
Во всей этой связи будет очень интересно узнать, что станется с сонмом доменов известного господина Анатолия Богданова (он же "Интернет-агентство Replay").
Это Ваше право.
Кхм. Вообще-то Дмитров это никакая не провинция, это город в Московской области и столица одноимённого её района. Не надо делить людей на замкадышей и остальных, это плохо сказывается на карме. Кстати, таких вот "dmitrov.ru" с кривыми кэширующими ресолверами для клиентов по России - уйма. И часть из них есть даже в Москве (sic!). Бороться со всей этой криворукостью можно только тремя путями:
1. Пинать провайдера - и чем сильнее, тем лучше;
2. Уйти к другому провайдеру (проголосовать "ногами");
3. Обеспечить себе собственный нормально настроенный ресолвер.
Hint: я сам живу не в Дмитрове, а в столице.
Не надо объяснять азы. По опыту некорректно настроенные кэширующие ресолверы почти на 100% наблюдаются именно у провайдеров или в отдельно взятых конторах. Есть и конкретные приложения, использующие какие-то свои библиотеки, но вот браузеры в виновниках оказывались последний раз лет так 6-7 назад - если их конечно не "твикали" кривыми руками.
Но я всё равно так и не понял, к чему относилось Ваше вот это:
При чём тут клиенты и их ПО, если криво настроенный кэширующий ресолвер находится у провайдера? :)
Вообще в профессиональной среде термин "DNS-парковщик" не используют, вместо этого говорят "разместить зону". И это не придирка к словам, т.к. "паркинг" в значении, применимом к Internet-индустрии, скорее указывает на [временное] использование некоей [рекламной] заглушки на [ненужном пока] домене. Подобные сервисы не предоставляют пользователю никаких возможностей по управлению зоной.
И если Ваш конкретный DNS-хостер не предоставляет Вам полноценных возможностей управления содержимым зоны, к примеру почему-то не даёт изменять TTL для определённых типов RR или прописывать те же SRV или даже удалять какие-то записи - то это плохой, негодный хостер.
Означает именно "караул", если точка входа - это именно availability monitor+redirector:
Если же это просто availability monitor, то время реакции на падение одного из мониторящихся серверов увеличивается и в течение этого времени [часть] пользователей будет видеть connection refused/timed out.
ППКС.
Я Вам привёл практический пример и подтвердил его несколькими тезисами. Если не верите - это Ваше право.
Верно. Только вот при повальном распространении dynamic IP на клиентах и VDS/VPS как хостинговых решений о безопасности DNS-серверов (сервисов) не всегда думают или считают это менее важной задачей.
dmitrov.ru
Не очень понял, что Вы этим хотели сказать. Против какого именно клиентского ПО нужно действовать таким замысловатым образом?
Вы уже несколько раз употребляете термин "DNS-парковщики". Кто это?
kassern, Вы TOS для Google Apps для начала почитайте. Это будет первым обоснованием.
Есть конечно. С чем Вы спорите? Что слишком малый TTL может быть источником повышенной нагрузки на сервер? Или с тем, что некоторые хостинги просто не возьмут зону, если на master малые TTL?
Если один и тот же сервис используется и как Auth NS и как ресолвер для каких-то внутренних нужд. Это тоже часто бывает. Понятно, что это плохо со многих позиций, но многие так делают, поскольку считают, что "ну а вот же DNS-сервер под рукой".
Когда я вижу слово "должны" применительно к сфере IT, я ему не верю. Крайне рекомендую проверять и проверять, т.к. примеров некорректной работы кэширующих ресолверов, причём у довольно крупных провайдеров, масса.
Грамотным планированием и проведением процедуры переезда в первую очередь. Если переезд запланированный, то весьма поможет предварительное уменьшение до разумной величины TTL SOA и NS RR.
MBDesign, можно источник информации о Германии? Если это какие-то IP, то лучше в ЛС. Спасибо.
