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