DDNS: Возможно ли решение своими руками? Лучше?

DDNS: Возможно ли решение своими руками? Лучше?

Я пытаюсь установить личный почтовый/календарный сервер у себя дома (да, я слышал, что это сложно, что это хлопотно и т. д., но я все равно хотел бы попробовать). У меня есть интернет-провайдер, который не предлагает статические IP-адреса, так что, похоже, решением будет некая динамическая служба доменных имен (DDNS).

Однако я провел исследование и нашел как минимум пару онлайн-ресурсов, которые объясняют, что вы можете сделать DDNS самостоятельно: вам нужен скрипт/программа, которая периодически отслеживает ваш IP-адрес, и если адрес меняется, то скрипт/приложение должны обновить любое доменное имя, которое вы используете для своих домашних серверов (у меня как раз на этот случай есть домен, припаркованный у хостинг-провайдера, и, насколько я понимаю, мне нужен только ключ API хостинг-компании, чтобы программно настроить необходимые записи домена/IP... кто-нибудь дайте мне знать, если я ошибаюсь, и есть более простой способ).

Вот в чем дело: когда вы обновляете записи доменного имени описанным выше способом, я читал, что это может занять несколько часов, чтобы распространиться по всей системе/миру (все DNS-серверы должны быть заново заполнены вашим обновленным адресом). Однако несколько платных провайдеров DDNS, которых я рассматривал, похоже, продвигают свою способность вносить изменения практически мгновенно (или, по крайней мере, быстрее, чем мой DIY-метод). Это правда? Есть ли что-то, что я упустил?

Кроме того, у меня есть еще одно опасение: есть ли какие-то проблемы безопасности, которые я мог упустить из виду, имея провайдера DDNS? Разве они не смогут контролировать весь трафик, проходящий через доменное имя, которое они предоставляют? Есть ли у кого-нибудь обоснованное мнение относительно того, какой метод (платный или самодельный) может быть лучше?

Я ценю ваше время...спасибо!

решение1

Я пытаюсь создать у себя дома персональный почтовый/календарный сервер (да, я слышал, что это сложно, хлопотно и т. д., но я все равно хотел бы попробовать).

С почтой вам, скорее всего, не повезет. Смотрите ответ @Alex.

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

Примерно так.

Мне просто нужен ключ API хостинговой компании, чтобы программно настроить необходимые записи домена/IP.

Да, хотя если компания предоставляет только общую услугу «хостинга всего», у нее может вообще не быть API для управления DNS (вместо этого она будет заниматься вебом и почтой), и вам, возможно, придется перенести домен в другое место.

Вот в чем дело: когда вы обновляете записи доменного имени описанным выше способом, я читал, что для распространения изменений по всей системе/миру может потребоваться несколько часов (все DNS-серверы должны быть заново заполнены вашим обновленным адресом).

Нет. Только собственные системы вашего провайдера хостинга DNS должны быть обновлены. Остальной мир не хранит постоянную запись – он просто кэширует результаты отдельных поисков на время, указанное в поле «TTL» (время жизни) каждого (под)домена.

Однако несколько платных провайдеров DDNS, на которых я смотрел, похоже, продвигают свою способность вносить изменения практически мгновенно (или, по крайней мере, быстрее, чем мой метод DIY). Это правда? Есть что-то, что я упустил?

Я предполагаю, что они позволяют настраивать очень низкий TTL на динамических доменах (до нескольких секунд), что означает, что он будет очень быстро выпадать из любых кэшей, за счет того, что сам провайдер DDNS будет получать гораздо больше запросов (более высокая нагрузка на их DNS-серверы и базы данных, и повод взимать с вас больше). Это само по себе не является чем-то особенным и может быть реализовано любым методом DIY.

Разве они не смогут отслеживать весь трафик, проходящий через предоставленное ими доменное имя?

Нет. DNS-сервер только предоставляет вам адрес (как в телефонной книге) и не участвует в дальнейшем взаимодействии.

(Если только поставщик фактически не попытаетсявернуть ложные данные(Что значительно сократит TTL компании в тот момент, когда новостные сайты узнают о ней.)

Тем не менее, обратите внимание на то, как работает API; конечно, вы не можете быть уверены, что у сервиса нет никаких уязвимостей, но если (например) API работает по незашифрованному HTTP и передает ключ API на виду, то на это не стоит полагаться.

решение2

Если у вас нет статического IP-адреса, то вам следует забыть о почтовом сервере, если вы используете решение DDNS. Большинство почтовых серверов либо отклонят ваши письма, либо пометят их как спам с наивысшим уровнем детализации, поскольку все динамические IP-адреса находятся вПБЛсписки. (Более подробную информацию о том, почему не стоит размещать сервер электронной почты на домашнем IP-адресе, можно найти в разделе PS, но есть и обходной путь — использование промежуточного дешевого VPS (виртуального частного сервера).)

Что касается "DDNS самостоятельно" - хороший регистратор доменов, предоставляющий бесплатное обновление IP через свой API, все, что нужно сделать вашей программе, это периодически проверять публичный IP и, если он изменился, отправлять новый IP регистратору, который обновит запись A(AAAA). Кстати, большинство современных маршрутизаторов уже имеют такую ​​функцию (следите за IP и сообщайте поставщику DDNS)

Я читал, что распространение по всей системе/миру может занять несколько часов.

Это зависит от поставщика DNS, уважаемые регистраторы позволяют устанавливать TTL (время, которое сообщает другим, как часто может меняться IP) равным 5 минутам. Не все пересылающие промежуточные DNS-серверы следуют этому, чтобы избежать высокой нагрузки, но обычно, даже если они не следуют TTL владельца домена, это редко длится дольше нескольких часов. Большинство пересылающих серверов обновляют свои кэши, как вы бы установили в доменном TTL.

Есть ли какие-то проблемы безопасности, которые я мог упустить из виду, имея поставщика DDNS?

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

Есть ли у кого-нибудь обоснованное мнение относительно того, какой метод (платный или самодельный) может быть лучше?

Вы выбросите свое время и деньги на ветер, если выберете DDNS. В настоящее время вы можете получить приличный VPS (виртуальный частный сервер) за 3-4 доллара в месяц. В то время как веб-сайт (если вы планируете его иметь) можно разместить непосредственно на VPS, так как обычно он не занимает много места, почтовый сервер может быть проблематичным, если вы планируете использовать свой сервер в течение длительного времени или ожидаете большой объем писем. Обычно 20 ГБ места достаточно для малого бизнеса до 3-5 лет, даже без удаления старых писем. Даже если вы ожидаете огромное количество писем, вы можете использовать nginxфункцию проксирования почтового трафика на свой дом. Таким образом, вы можете разместить основной почтовый сервер дома на динамическом IP, а VPS (со статическим IP) будет проксировать входящий/исходящий трафик на ваш дом. Вы можете использовать свой собственный VPS в такой конфигурации без проблем, так как нет необходимости беспокоиться о распространении DNS, домен всегда будет указывать на статический IP VPS. Вам по-прежнему нужно будет сообщать об изменениях вашего домашнего IP-адреса на VPS, чтобы VPS знал, куда проксировать трафик, но все гораздо проще: просто запросите URL-адрес на вашем VPS, проанализируйте в журналах ваш входящий IP-адрес и настройте nginx, чтобы он всегда знал, где вы находитесь.

ПС


Я вижу, что эта тема интересна суперпользователям, поэтому я бы добавил немного больше подробностей.

ПБЛlists содержит базу данных IP-адресов, которые обычно являются динамическими IP-адресами, поэтомуПБЛ очень помогает операторам серверов электронной почты. Это не техническая проблема или плохие ребята из интернет-провайдеров, которые не разрешают использовать сервер электронной почты на динамических IP-адресах, проблема в том, что большая часть трафика электронной почты с динамических IP-адресов поступает с зараженных компьютеров, которые рассылают спам или вредоносное ПО в огромных объемах, что может легкоDDoSпринимающий сервер, если он является целью. Некоторые провайдеры блокируют исходящие соединения на порт 25, чтобы предотвратить распространение вредоносного ПО иDDoS, но некоторые этого не делают. Практически все серверы корпоративной электронной почты просто сбрасывают соединения, которые приходят отПБЛсписок, который значительно сокращает количество спама.

Второе эффективное решение для борьбы со спамом — сбрасывать соединения с IP-адресов, которые не имеют обратной записи PTR в DNS и не соответствуют записи DNS домена. Даже если соединения поступают со статического IP-адреса, который не имеет записи PTR, это обычно либо плохо настроенная настройка, либо в основном это происходит с серверов, управляемых спам-бандами (могут быть исключения для некоторых крупных (но беспечных) провайдеров, но их можно вручную добавить в белый список). Хотя установка обратной записи PTR на VPS занимает несколько минут, это не тот случай, если статические IP-адреса получены от интернет-провайдера, а процесс установки PTR обычно является PITA (нужно позвонить им, отправить тикет после проверки того, что вы первоначальный владелец IP-адреса, и ждать милости их системного администратора, которому нужно установить обратную запись PTR, иногда в течение нескольких часов, а иногда и дней).

Также, не критично, но... чтобы избежать подделки электронной почты, большинство владельцев почтовых серверов используют так называемыеСПФ(инфраструктура политики отправителя), которая позволяет указать наиболее быстрый метод обработки политики, если установить в DNS авторизованные IP-адреса, которые разрешают отправлять электронные письма от имени домена. (можно указать авторизованные серверы,Полное доменное имя(как и в случае с записью MX, но это дополнительные циклы передачи данных по DNS для подключения серверов). Поэтому управление плавающим IP-адресом в DNS не было бы забавным.

решение3

Мой интернет-провайдер не предоставляет статические IP-адреса, поэтому, похоже, решением может стать какая-то служба динамических доменных имен (DDNS).

Это одно решение. В качестве примера другого решения, туннель IPv6 HurricaneElectric.net предоставляет статический (IPv6) адрес с подвижной конечной точкой туннеля. Конечно, в настоящее время IPv4 было бы лучше поддерживать для такой функциональности с широкой публикой, но если вы сможете найти готовый к сотрудничеству компьютер, вы могли бы технически сделать то же самое и с IPv4.

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

Это звучит как технически надежный план.

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

Точные детали будут зависеть от выбора регистратора доменных имен относительно того, как они реализуют эту функцию. Некоторые могут использовать какой-либо ключ API, в то время как другие могут полагаться на веб-интерфейс для автоматических обновлений. В старые времена некоторые интернет-провайдеры предоставляли такую ​​услугу, но полагались на ручные изменения в ответ на запросы. Так что это полностью зависит от того, кто предоставляет вам эту услугу.

Вот в чем дело: когда вы обновляете записи доменного имени описанным выше способом, я читал, что для распространения изменений по всей системе/миру может потребоваться несколько часов (все DNS-серверы должны быть заново заполнены вашим обновленным адресом).

Ба, чушь. Известно, что распространение DNS занимает минуты, часы или дни (например, 72 часа). Однако, когда люди тщательно проанализировали ситуацию, они обнаружили, что большая часть этого неопределенного времени «распространения» была просто из-за того, что провайдер хостинга DNS медленно обновлялся.

В лучшей теории вам просто нужно дождаться значения TTL. Хотя, есть проблема с этой теорией...

Однако несколько платных провайдеров DDNS, на которых я смотрел, похоже, продвигают свою способность вносить изменения практически мгновенно (или, по крайней мере, быстрее, чем мой метод DIY). Это правда? Есть что-то, что я упустил?

Хорошо, вот реальность: чтобы обновление вступило в силу, вам нужно будет очистить активный кэш Интернета от старой информации.

Согласно стандартам, кэширующие DNS-серверы могут полагаться на свой кэш в течение периода времени, определяемого значением TTL, которое вы можете настроить.

Однако реальность такова, что, по крайней мере, некоторые (а может быть, даже большинство?) очень крупных интернет-провайдеров, как известно, используют свои собственные кэширующие DNS-серверы, которые, как известно, просто полностью игнорируют значения TTL. Они делают это, потому что считают, что если они будут обновлять свои DNS-кеши реже, то общий эффект будет заключаться в меньшей пропускной способности (и, возможно, в некотором меньшем времени вычислений).

Таким образом, любой сервер электронной почты, который полагается на такой DNS-сервер, может быть затронут и не сможет заметить ваши обновления, пока DNS-сервер не обновится. В некоторых случаях это может занять день или два (или три?).

Однако такие эффекты стали все более редкими. На практике большинство DNS-серверов будут очищать свои кэши в течение часа или двух.

Поскольку некоторые кэши не будут обновляться так быстро, как некоторые другие, эффект будет заключаться в том, что некоторые места в Интернете будут работать с новым адресом, в то время как другие места будут по-прежнему пытаться использовать старый адрес. В течение пары часов большинство компьютеров будут нормально работать с новой информацией. (Многие, многие из них могут работать в течение нескольких минут.)

Типичное поведение программного обеспечения электронной почты — попытка отправить электронное письмо. Если это не удается, попробуйте еще раз позже. Серверы электронной почты обычно продолжают повторять попытки (возможно, раз в час) в течение нескольких дней, прежде чем сдаться. Так что, скорее всего, вы не потеряете электронное письмо, но оно немного задержится.

Комментарий Алекса «все динамические IP-адреса находятся в списках PBL» явно неверен, поскольку эта информация децентрализована (поэтому слово «все» неточно), но верно то, что многие динамические IP-адреса находятся в таких списках, и это может означать, что некоторые компьютеры/устройства, связанные с электронной почтой, могут решить не сотрудничать с вами.

У меня есть еще один вопрос: есть ли какие-то проблемы безопасности, которые я мог упустить из виду, имея поставщика DDNS?

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

Разве они не смогут отслеживать весь трафик, проходящий через предоставленное ими доменное имя?

Нет. Задача DNS-сервера — получить запрос на доменное имя и предоставить ответ. Традиционный типичный ответ — предоставить один или несколько IP-адресов. Возможны и другие ответы, например, ссылка на другой DNS-сервер или доменное имя (например, с помощью CNAME) или другие данные (например, помощь в обеспечении безопасности с помощью нового стандарта DNSSec).

Есть ли у кого-нибудь обоснованное мнение...

Я хотел бы отметить, что если вы действительно хотите запустить серьезный сервер электронной почты, вы можете рассмотреть возможность соответствия современным стандартам электронной почты. Это подразумевает больше, чем просто соответствие техническим спецификациям SMTP и DNS. Многие пользуются услугами крупных провайдеров, и эти крупные провайдеры могут реализовывать свои собственные ожидания.

Например, я знаю почтовый сервер, который был настроен с Debian и Postgrey много лет назад. Postgrey — это программное обеспечение, которое обеспечивает обработку антиспама «серыми списками». Однако используемая версия Postgrey предполагает, что когда почтовый сервер повторяет отправку электронного письма, отправляющий почтовый сервер будет использовать тот же IP-адрес. Известно, что почтовые серверы Office 365 пытаются повторно отправить электронное письмо с другого IP-адреса, который все еще находится в подсети IPv6 /64. Postgrey это не нравится.

Поскольку все больше организаций переходят на Office 365, это становится все большей проблемой для людей, использующих старый почтовый сервер. Была выпущена более новая версия программного обеспечения Postgrey, но простой способ установки такого программного обеспечения — использовать официальный репозиторий программного обеспечения для этой операционной системы. Поэтому на практике разумным способом обновления этого программного обеспечения будет обновление операционной системы.

Существуют и другие соглашения, например, имена DNS, начинающиеся с «mail.», которые могут привести к тому, что ваша настройка будет оценена как более или менее надежная. Это может повлиять на то, будут ли устройства воспринимать вас как несоответствующего спамера или как устройство, с которым стоит общаться.

Конечно, возможно, если говорить очень строго об официальных технических спецификациях, гигантские организации выполняют некоторые действия, которые отличаются от минимальных требований, требуемых документами RFC, содержащими технические спецификации используемых протоколов. Но если вы хотите общаться с большим интернет-сообществом, есть некоторые дополнительные стандарты, которые навязываются некоторыми значительными/крупными игроками. Будьте готовы хорошо соответствовать этим стандартам или будьте готовы столкнуться с некоторыми проблемами.

Я немного расплывчато объясняю, что именно представляют собой все эти стандарты, поскольку со временем они могут меняться.

Что касается старого сервера электронной почты, которому нужно будет обновить свою старую операционную систему Debian, возможно, людям следует обновлять свою операционную систему чаще в любом случае. Однако я хочу сказать, что программная настройка, которая прекрасно работала годами, теперь сломана из-за нового поведения, которое обычно используется многими адресами электронной почты. Если вы попытаетесь сделать что-то необычное, например, использовать Dynamic DNS на более медленном интернет-провайдере, вы, скорее всего, столкнетесь с некоторыми дополнительными проблемами по пути. Поскольку вы звучите амбициозно, возможно, вы можете вложить усилия в это. Я просто предупреждаю вас, чтобы вы были готовы к необходимости сделать это.

...какой метод (платный или самостоятельный) может быть лучше?

Как уже отмечали другие, платный вариант будет намного проще и довольно экономичен для большинства людей. Крупные поставщики, скорее всего, предоставят стабильный IP-адрес, на который вы можете указать свою запись MX (чтобы E-Mail шел туда), и могут обеспечить заметно лучшую пропускную способность.

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

Что «лучше» — будет зависеть от ваших индивидуальных целей, поэтому я оставляю такие выводы на ваше усмотрение.

решение4

В других ответах уже объяснялась часть DDNS.

Я собираюсь объяснитьпочемувам придется использовать отдельный сервер для отправки электронной почты (поскольку краткое объяснение от @Alex является неполным).

Самое главное, вам нужна действительная обратная запись PTR для отправки электронной почты — многие почтовые серверы проверят ее и отклонят вашу почту, если обратная запись DNS для IP-адреса не соответствует домену отправителя. Эта запись предоставляется владельцем IP-адреса — например, вашим интернет-провайдером.

Now let's imagine, that you have somehow gotten valid, dynamically updating reverse DNS (ha-ha). You still have to convince everyone, that your domain is legit, and your outgoing email isn't spam.

Как объяснил @Alex, мелкие почтовые хостеры любят использовать spamhaus и другие онлайн-черные списки. Но я видел, как эти корпоративные администраторы делают много других глупостей (например, блокируют всю почту, которая не приходит с Gmail/Hotmail). На самом деле, это не просто некоторые "корпоративные администраторы" — я виделSourceforgeзаблокируйте регистрацию с законного корпоративного почтового домена, потому что «мы не знаем почему, но наш спам-фильтр считает, что вы плохие». Просто игнорируйте их — вы не сможете оставаться совместимыми со всеми под небом.

Крупные почтовые хостеры в наши дни не полагаются на spamhaus или другие PBL. Они сами отслеживают вашу надежность. Репутация отправителя (по крайней мере, большая ее часть) привязана к IP. Это происходит потому, что спамеры часто получают пинка от своих хостеров, поэтому они вынуждены менять IP. С точки зрения Gmail ваш недавно созданный домен/IP ничем не отличается от обычного спамера. Когда вы начинаете отправлять электронную почту, ваша репутация низкая (вы по умолчанию рассматриваетсяе как спамер!). Большая часть вашей исходящей электронной почты будет помечена как спам. Когда кто-то отвечает на ваше письмо или особенно помечает его как законное (нажимая соответствующую кнопку в веб-интерфейсе своего почтового провайдера), доверие к вам немного возрастет. Как вы можете видеть, чтобы повысить репутацию отправителя, вам придется использовать один и тот же домен на одном и том же IP в течение многих лет. Это невозможно сделать надежно с динамическим IP.


После того, как вы арендуете VPS у хостера, содержание домашнего сервера на динамическом IP станет намного проще. Вы сможете использовать этот VPS как свой собственный сервер DDNS с чрезвычайно низким TTL. Вы даже можете отказаться от DNS и использовать другие средства (например, перенаправление HTTP) для обработки изменяющегося IP вашего домашнего ящика. Вы по-прежнему сможете получать электронную почту непосредственно на свой домашний ящик — опционально с откатом на VPS, когда ваш домашний IP-адрес не работает или недавно изменился.

Связанный контент