Если посмотреть внимательно, то это только для камер произведенных для этого сервиса. Я за то чтобы в камеры встраивали универсальный механизм, не привязанный к конкретному производителю.
Не очень понятна теория — каждый из корневых серверов содержит полную информацию о всех корневых tld и способен ее ресолвить. NS сервера Dyn распределены по миру по десятку дата-центров. За 15 лет не было ни одного отказа, даже когда некоторые корневые сервера подвергались атаке. Так что свою задачу IMHO Dyn выполняет. К стати, Яндекс тоже имеет существенные мощности DNS, распределенные по стране, поэтому мы его и выбрали как бэкенд для своего DDNS.
Проблемы ресолвинга для tld, о которых вы говорите скорее всего связаны с проблемами общей маршрутизации с каком-то из сегментов сети.
Как говорил мой преподаватель философии — прежде чем спорить или высказываться, определитесь с предметом. Ivan_83 предлагал использовать «бесплатные аналоги», я же как раз за промышленный подход. Так что мы с вами zup на одной волне ;-)
Да, и поставить еще компьютер с сервером Ivedeon который содержит тот же vpn-клиент. Тоже самое, что описано в статье, только компьютер плюсом.
Правильно было бы добавить в DVR OpenVPN клиента и всех этих плясок можно было бы избежать.
Вариант на коленке работает. Сам делаю так когда задача этого требует.
Но есть задачи когда «на коленке» не вариант. Скрипты выдержат 1000 серверов? А 10000? А встраивание в бизнес-приложение? А мониторинг? А 10 географических зон? И как синхронизировать все это будем? Создадим собственный Dyn? Но почему мы все время пытаемся быть кустарями-ремесленниками? Зачем все время повторяем одно и тоже, одни и те же ошибки?
Буду признателен если вы покажете «бесплатный аналог не хуже»?
К сожалению ничего нет и близко. Как все это поверхностные суждения заключающиеся в попытке сравнить только сервис DDNS. Но статья не про это…
Я не фанат Dyn, но для промышленных решений кроме пока них не предлагает никто.
1. Пока не видел ни одной компании предоставляющей услуги видеонаблюдения использующей всегда устройства одного и того же производителя да еще один и тот же тип камеры.
2. Облачный сервис чей? Как вы думаете компания с более менее приличными коммерческими секретами доверит их каким-то китайским или американским сервисам? Не говоря уже, например про тот же Росатом или что-то похожее. А мобильное видеонаблюдение нужно многим. Если нам удастся «допинать» китайских производителей на встройку OpenVPN в их камеры и DVR, то вопросы выбора облачного сервиса будет открытым и каждый сможет выбирать.
3. Данное решение появилось как ответ на множественные запросы наших клиентов DDNS (https://dynru.ru)
Второе замечание не понял. NAT правила задаются для ethernet интерфейсов средствами DD-WRT, но из-за косяка в прошивках (или это фича?) на ppp интерфейсы правила приходится добавлять в виде скрипта.
Проблемы ресолвинга для tld, о которых вы говорите скорее всего связаны с проблемами общей маршрутизации с каком-то из сегментов сети.
Правильно было бы добавить в DVR OpenVPN клиента и всех этих плясок можно было бы избежать.
Но есть задачи когда «на коленке» не вариант. Скрипты выдержат 1000 серверов? А 10000? А встраивание в бизнес-приложение? А мониторинг? А 10 географических зон? И как синхронизировать все это будем? Создадим собственный Dyn? Но почему мы все время пытаемся быть кустарями-ремесленниками? Зачем все время повторяем одно и тоже, одни и те же ошибки?
К сожалению ничего нет и близко. Как все это поверхностные суждения заключающиеся в попытке сравнить только сервис DDNS. Но статья не про это…
Я не фанат Dyn, но для промышленных решений кроме пока них не предлагает никто.
2. Облачный сервис чей? Как вы думаете компания с более менее приличными коммерческими секретами доверит их каким-то китайским или американским сервисам? Не говоря уже, например про тот же Росатом или что-то похожее. А мобильное видеонаблюдение нужно многим. Если нам удастся «допинать» китайских производителей на встройку OpenVPN в их камеры и DVR, то вопросы выбора облачного сервиса будет открытым и каждый сможет выбирать.
3. Данное решение появилось как ответ на множественные запросы наших клиентов DDNS (https://dynru.ru)
Второе замечание не понял. NAT правила задаются для ethernet интерфейсов средствами DD-WRT, но из-за косяка в прошивках (или это фича?) на ppp интерфейсы правила приходится добавлять в виде скрипта.