DDNS: Чи можливе самостійне рішення? Краще?

Я намагаюся встановити сервер особистої пошти / календаря у себе вдома (так, я чув, що це важко, це багато клопоту і т. Д., Але я все одно хотів би спробувати). У мене є провайдер, який не пропонує статичних IP-адрес, тому схоже на те, що якесь динамічне обслуговування доменних імен (DDNS) є рішенням.

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

Ось що: коли ви оновлюєте свої записи доменних імен таким чином, як я описав вище, я прочитав, що для розповсюдження по всій системі / світі може знадобитися кілька годин (усі DNS-сервери повинні бути переповнені вашою оновленою адресою ). Однак декілька платних DDNS-провайдерів, на які я дивився, здається, просувають свою здатність зміни вступити в дію майже миттєво (або, принаймні, швидше, ніж мій саморобний метод). Це правда? Чи щось я пропустив?

Крім того, у мене є ще одна стурбованість: чи є якісь проблеми із безпекою, які я можу не помітити, якщо є постачальник DDNS? Чи не зможуть вони відстежувати весь трафік, який проходить через ім’я домену, яке вони надають? Хтось має поінформовану думку стосовно того, який спосіб (який заплатив проти DIY) може бути кращим?

Я ціную ваш час ... дякую!

Я намагаюся встановити сервер особистої пошти / календаря у себе вдома (так, я чув, що це важко, це багато клопоту і т. Д., Але я все одно хотів би спробувати).

Вам, мабуть, не пощастить з частиною пошти. Дивіться відповідь @ Алекса.

вам потрібно мати сценарій / програму, яка періодично відстежує вашу IP-адресу, і якщо адреса змінюється, сценарій / додаток потрібно оновлювати те доменне ім’я, яке ви використовуєте для своїх домашніх серверів

Досить, що.

Мені просто потрібен ключ API хостингової компанії для того, щоб програмно налаштувати необхідні записи домену / IP

Так, хоча якщо компанія просто надає загальну послугу «все, що приймає», у неї може взагалі не існувати API управління DNS (орієнтований замість цього на веб-пошту та пошту), і вам може знадобитися перемістити домен в інше місце.

Ось що: коли ви оновлюєте свої записи доменних імен таким чином, як я описав вище, я прочитав, що для розповсюдження по всій системі / світі може знадобитися кілька годин (усі DNS-сервери повинні бути переповнені вашою оновленою адресою ).

Ні. Необхідно оновлювати лише власні системи вашого постачальника послуг DNS. Решта світу не веде постійного запису - він просто кешує результати окремих пошукових запитів, протягом тривалості, зазначеної в полі "TTL" (Time To Live) кожного (під) домену.

Однак декілька платних DDNS-провайдерів, на які я дивився, здається, просувають свою здатність зміни вступити в дію майже миттєво (або, принаймні, швидше, ніж мій саморобний метод). Це правда? Чи щось я пропустив?

Я б припустив, що вони дозволяють налаштувати дуже низький TTL для динамічних доменів (до декількох секунд), а це означає, що він дуже швидко випаде з будь-яких кешів за рахунок самого постачальника DDNS, який отримає набагато більше запитів (вище завантаження на їх DNS-сервери та бази даних, і привід стягувати з вас більше). Це одне не є чимось особливим, і його можна реалізувати будь-яким методом саморобки.

Чи не зможуть вони відстежувати весь трафік, який проходить через ім’я домену, яке вони надають?

Ні. DNS-сервер надає лише адресу (подібно до телефонної книги) і не бере участі в подальшому спілкуванні.

(Якщо провайдер насправді не намагається повернути недостовірні дані , що значно скоротить TTL компанії в той момент, коли новини про це дізнаються.)

При цьому зверніть увагу на те, як працює API; звичайно, ви не можете бути впевнені, що сервіс не має вразливих місць, але якщо (наприклад, API працює над незашифрованим HTTP та передає ключ API на виду, то на це не потрібно покладатися.

Якщо у вас немає статичного IP-адреси, вам слід забути про поштовий сервер, якщо ви збираєтеся з рішенням DDNS, більшість серверів електронної пошти або відхилять електронні листи від вас, або будуть позначати електронну пошту з найвищим рівнем спаму, оскільки всі динамічні IP-адреси містяться в списках PBL . ( У розділі PS ви можете ознайомитись із тим, чому недобре мати сервер електронної пошти на житловому IP-адресі, але все-таки існує спосіб вирішення за допомогою проміжних дешевих VPS (віртуального приватного сервера) )

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

Я читав, що проходження по всій системі / світі може зайняти кілька годин

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

Чи є якісь проблеми із безпекою, які я можу не помітити, якщо у вас є постачальник DDNS?

Вийти в Інтернет - це вже можливе питання безпеки. Ізолюйте свій сервер від локальної мережі, щоб уникнути непроханих гостей.

Хтось має поінформовану думку стосовно того, який спосіб (який заплатив проти DIY) може бути кращим?

Ви кинете свій час і гроші в ефір, якщо ви поїдете з DDNS. Сьогодні ви можете отримати гідну VPS (віртуальний приватний сервер) за 3-4 долара на місяць. Хоча веб-сайт (якщо ви плануєте його мати) можна розміщувати безпосередньо на VPS, оскільки зазвичай це не займає багато місця, сервер електронної пошти може бути проблематичним, якщо ви плануєте довго запускати ваш сервер або очікуєте великого обсягу електронні листи. Зазвичай 20 Гб місця достатньо для малого бізнесу до 3-5 років, навіть не видаляючи старі електронні листи. Навіть якщо ви очікуєте величезної кількості електронних листів, ви можете використовуватиnginxфункція проксі-трафіку до вашого будинку. Таким чином, ви можете розмістити основний сервер електронної пошти вдома на динамічному IP-адресі, а VPS (у якого є статичний IP) буде проксі-сервером вхідного / вихідного трафіку до вашого будинку. Ви можете використовувати свій власний VPS в такій конфігурації без болю, оскільки не потрібно турбуватися про поширення DNS, домен завжди вказуватиме на статичний IP-код VPS. Вам все-таки потрібно керувати звітом про домашні зміни IP-адреси на VPS, щоб VPS знав, куди проксі-трафік, але це набагато простіше, просто запитайте якусь URL-адресу на своєму VPS та проаналізуйте в журналах вхідного IP-адреси та відрегулюйте nginx, щоб це завжди було відомо де ти.

PS

Я можу бачити, що ця тема цікава для суперпользователей, тому я додам трохи більше деталей.

У списках PBL зберігається база даних IP-адрес, які, як правило, є динамічними IP-адресами, тому PBL дуже допомагає операторам серверів електронної пошти. Це не технічна проблема або провайдер - це погані хлопці, які не дозволяють серверу електронної пошти на динамічних IP-адресах, проблема полягає в тому, що більшість трафіку електронної пошти від динамічних IP-адрес надходять із заражених комп'ютерів, які надсилають спам чи зловмисне програмне забезпечення у величезному обсязі, який може легко отримувати DDoS сервер, якщо один - ціль. Деякий провайдер блокує вихідні з'єднання до порту 25, щоб запобігти поширенню зловмисного програмного забезпечення та DDoS , але деякі - ні. Практично всі сервери корпоративного електронної пошти просто скидають з'єднання, що надходять із списку PBL, що значно зменшує спам.

Другим ефективним антиспам-рішенням є скасування з'єднань з IP-адрес, які не мають зворотного запису PTR в DNS і не відповідають запису DNS домену. Навіть якщо з'єднання надходять із статичного IP, що не має запису PTR, це зазвичай або неправильно налаштована установка, або в основному відбувається з серверів, що працюють за допомогою банди спаму (можуть бути виключення для деяких великих (але недбалих) провайдерів, але їх можна додавати вручну у білому списку). Хоча для встановлення зворотного запису PTR на VPS потрібно лише кілька хвилин, але це не так, якщо статичні IP-адреси, отримані від ISP і обробляють для встановлення PTR, зазвичай є PITA (потрібно викликати їх, подати квиток після перевірки що ви початковий власник IP-адреси і чекаєте милості свого sysadmin, якому потрібно встановити зворотний запис PTR, іноді за кілька годин, а іноді до днів)

Крім того, це не критично, але ... щоб уникнути підробки електронної пошти, більшість власників серверів електронної пошти використовують так званий SPF (фреймворк політики відправника), який дозволяє вказати найшвидший метод обробки політики, якщо один набір у DNS-авторизованих IP-адресах, які дозволяли надсилати електронні листи від імені домену. (можна вказати авторизовані сервери FQDN як посилання на запис MX, але це додаткові зворотні поїздки через DNS для підключення серверів) Отже, керувати плаваючим IP в DNS не було б цікаво.

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

Це одне рішення. Як приклад іншого рішення, тунель HurricaneElectric.net IPv6 пропонує статичну адресу (IPv6) з рухомою кінцевою точкою тунелю. Зрозуміло, що в цей час IPv4 було б приємніше підтримувати таку функціональність для широкої громадськості, але якщо ви зможете знайти охочий спільний комп’ютер, ви можете технічно зробити таку справу і з IPv4.

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

Це звучить як технічно міцний план.

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

Точні деталі залежатимуть від вибору реєстратора доменних імен, яким чином вони реалізують цю функцію. Деякі можуть використовувати якийсь API API, а інші можуть покладатися на веб-інтерфейс для автоматичного оновлення. За старих часів деякі провайдери надавали таку послугу, але покладалися на ручні зміни у відповідь на запити. Тому повністю залежить від того, хто надасть вам послугу.

Ось що: коли ви оновлюєте свої записи доменних імен таким чином, як я описав вище, я прочитав, що для розповсюдження по всій системі / світі може знадобитися кілька годин (усі DNS-сервери повинні бути переповнені вашою оновленою адресою ).

Бах хамбу. Відомо, що поширення DNS займає хвилини або години або дні (наприклад, 72 години). Однак, коли люди ретельно проаналізували речі, вони виявили, що значна частина цього розпливчастого часу на "розповсюдження" відбувається просто від постачальника хостингових послуг DNS, який повільно оновлюється.

У кращій теорії, вам слід просто почекати значення TTL. Хоча, існує проблема з цією теорією ...

Однак декілька платних DDNS-провайдерів, на які я дивився, здається, просувають свою здатність зміни вступити в дію майже миттєво (або, принаймні, швидше, ніж мій саморобний метод). Це правда? Чи щось я пропустив?

Гаразд, ось реальність: для того, щоб ваше оновлення набуло повного ефекту, вам потрібно буде в Інтернеті очистити його активний кеш старої інформації.

Відповідно до стандартів, кешування 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. Постгрей це не любить.

Оскільки все більше організацій переходять на Office 365, це стає все більшою проблемою для людей, які використовують цей старий сервер електронної пошти. Випущена нова версія програмного забезпечення Postgrey, але найпростішим способом встановлення такого програмного забезпечення є використання офіційного сховища програмного забезпечення для цієї операційної системи. Тож на практиці розумним способом оновити це програмне забезпечення буде оновлення операційної системи.

Є й інші умови, наприклад, імена DNS, які починаються з "пошти". що може спричинити оцінку вашої установки як більш-менш достовірної. Це може вплинути на те, чи пристрої поводяться з вами як із невідповідним спамером або з пристроєм, з яким варто спілкуватися.

Безумовно, можливо, говорячи дуже суворо про офіційні технічні умови, гігантські організації виконують деякі дії, що відрізняються від мінімальних вимог, що вимагаються документами RFC, що містять технічні характеристики використовуваних протоколів. Але якщо ви хочете спілкуватися з більшою Інтернет-спільнотою, існують деякі додаткові стандарти, які накладають деякі значні / великі гравці. Будьте готові добре відповідати цим стандартам або будьте готові зіткнутися з деякими неприємностями.

Я трохи розпливаюсь у тому, які саме всі ці стандарти є, тому що вони можуть змінюватися з часом.

Що стосується того старого сервера електронної пошти, який потребуватиме оновлення своєї старої операційної системи Debian, можливо, людям слід все одно частіше оновлювати свою операційну систему. Я хотів би сказати, що налаштування програмного забезпечення, яке працювало ідеально роками, тепер порушено через нову поведінку, яку зазвичай використовують багато адрес електронної пошти. Якщо ви намагаєтеся робити незвичайні речі, як-от використання динамічного DNS на повільному інтернет-провайдері, ви, швидше за все, зіткнетеся з деякими додатковими проблемами. Як ви звучаєте амбітно, можливо, ви можете вкласти свої зусилля в це. Я просто попереджую вас підготуватися до цього.

... що стосується того, який метод (платний проти самостійного) може бути кращим?

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

Зроби самостійно краще для набуття досвіду та вивчення того, як все працює, і вибирати не покладатися лише на впровадження від великих корпорацій. Маючи більший контроль над своєю реалізацією, ви також можете значно швидше вносити значні зміни в користування.

Що "краще", залежатиме від ваших індивідуальних цілей, тому такі висновки я залишаю вам.

Так, можливо розмістити сервер DDNS самостійно (насправді я написав одну сумісну реалізацію DynDNS для DJBs tinydns деякий час тому). Ви можете використовувати звичайний клієнт DynDNS на динамічному IP для оновлення свого імені DNS, але код сервера все одно запускатиметься десь зі статичним IP (оскільки сервери GTLD все ще повинні вказувати записи NS для вашого домену до деякого статичного IP).

Крім того, якщо ви самі не приймаєте DNS, але завантажуєте його стороннім постачальником DNS, вони можуть надавати вам API для зміни IP, як ви говорите. Це, ймовірно, поширюватиметься повільніше, ніж належне рішення DDNS, і ви, очевидно, не будете повністю розміщені самостійно, але залежатимете від цієї сторони для DNS-послуг. Зазвичай вони не є шкідливими (і в Інтернеті є так багато інших проблем безпеки, які варто хвилювати більше), але я все одно віддаю перевагу під моєму контролю (якщо нічого іншого, оскільки це дає мені свободу вибирати свого постачальника DNS замість замикаючись).

Я також запускаю власні екземпляри сервера календаря / контактів / зображень замість того, щоб передавати дані в google чи комусь іншому (використовуючи відкриті джерела Nextcloud та екземпляри Mediagoblin ). Хоча я запускаю їх на "моїх" VPS зі статичними IP-адресами (оскільки це і простіше, і забезпечує більшу пропускну здатність), і те й інше можна запустити на динамічному IP-адресі, який у вас є вдома.

Крім того, як згадували інші, для надсилання пошти ви не зможете надійно надсилати пошту безпосередньо з цього сервера через чорні списки PBL (вона буде працювати іноді, втрачатися або відскакуватися в інший час або позначатися як СПАМ), але якщо ви ' знову добре, пересилаючи його через якийсь інший SMTP-сервер (наприклад, з gmail або вашого провайдера), він буде працювати чудово.

Однак, сервер вхідної пошти (MX) на динамічному IP - це досить проблематично. Наприклад, якщо пошта приходить, коли ви змінюєте IP-адреси, можливо, він спробує доставити IP-адресу, яке ви мали деякі моменти тому, але тепер у іншого клієнта. У більшості випадків це просто призведе до невдалого підключення і, таким чином, затримки пошти, але якщо інший клієнт також запустить SMTP-сервер, пошта буде доставлена ​​йому / їй або відмовиться з фатальною помилкою "отримувач не існує" (що зазвичай автоматично скасувати підписку на свої списки розсилки тощо). Крім того, якщо ваш IP-адреса не має зворотного DNS (або іноді навіть є, але якщо це виглядає динамічно!), Деякі поштові сервери відмовляться доставляти вам пошту.

Але якщо якийсь відсоток втраченої або неправильно спрямованої пошти для вас не є проблемою, то будь-ласка сміливо спробуйте.

Зауважте, що можливо також, що ваш Інтернет-провайдер має проти вас правила, які надають послуги у вашому низькому ціні "споживчий Інтернет", і може закрити вас, якщо вони виявлять, що ви порушуєте договір. Або вони можуть навіть активно блокувати будь-які вхідні з'єднання з вашим домом у популярних портах, таких як tcp / 25, 80, 443, тощо., Які можуть зруйнувати всю вашу ідею самостійного розміщення хостингу (якщо ви не поміняєте провайдера або не переходите в більш дорогий "бізнес-клас" "який також має статичні IP-адреси).

І останнє, що слід зазначити, у багатьох типових підключеннях до Інтернету для споживачів (наприклад, ADSL, кабель тощо) швидкість асиметрична, тобто завантаження відбувається набагато швидше, ніж швидкість завантаження. Що погано, якщо ви хочете подавати якийсь більший публічний контент, наприклад фотографії (замість того, щоб покладатися на facebook чи google для цього та відмовлятися від своїх прав) з дому, оскільки це буде повільно (не стосується також хлопця, який завантажує з вас фотографії, але також і для всього інтернет-з'єднання).

Інші відповіді вже пояснили частину DDNS.

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

Найголовніше, що вам потрібна дійсна зворотна запис PTR для надсилання електронної пошти - багато серверів електронної пошти перевірять її та відскакують вашу пошту, якщо зворотний запис DNS для IP-адреси не відповідає домену відправника. Цей запис надається власником IP-адреси - наприклад, вашим Інтернет-провайдером.

Тепер давайте уявимо, що ви якось стали дійсними, динамічно оновлюючи зворотний DNS (ха-ха). Ви все ще повинні переконати всіх у тому, що ваш домен законний, а ваш вихідний лист не є спамом.

Як пояснив @Alex, хостери поштового зв’язку люблять використовувати спамхаус та інші чорні списки в Інтернеті. Але я бачив, як ці корпоративні адміністратори роблять багато інших тупих речей (наприклад, блокування всієї електронної пошти, яка не надходить з Gmail / Hotmail). Власне, це не просто деякі "корпоративні адміністратори" - я бачив Sourceforge блокує реєстрацію з законного домену корпоративного електронної пошти, тому що "ми не знаємо чому, але наш фільтр спаму вважає, що ви погані". Просто ігноруйте їх - ви не можете залишатися сумісними з усіма, хто знаходиться під небом.

Величезні хостери для пошти в ці дні не покладаються на спамхаус або інший PBL. Вони самі відстежують вашу надійність. Репутація відправника (принаймні більша частина) додається до IP. Це відбувається тому, що спамери часто отримують завантаження від хостерів, тому вони змушені стрибати IP-адреси. З точки зору Gmail, нещодавно створений домен / IP не відрізняється від звичайного спамера. Коли ви починаєте надсилати електронну пошту, ваша репутація низька (вас вважають спамером за замовчуванням!). Більшість ваших вихідних електронних листів буде позначено як спам. Коли хтось відповість на вашу електронну пошту або особливо відзначить її легітимною (натиснувши відповідну кнопку в веб-інтерфейсі свого постачальника електронної пошти), довіра до вас дещо зросте. Як бачите, щоб підвищити репутацію відправника, вам доведеться використовувати той самий домен протягом одного і того ж IP протягом багатьох років. Це може "

Як тільки ви орендуєте VPS у хостера, зберігати домашній сервер на динамічному IP стане набагато простіше. Ви зможете використовувати цей VPS як власний сервер DDNS з надзвичайно низьким TTL. Можливо, ви навіть зможете відмовитися від DNS і використовувати інші засоби (наприклад, перенаправлення HTTP) для обробки IP-адреси домашнього поля. Ви все одно зможете отримувати електронну пошту безпосередньо у свій домашній ящик - необов’язково із резервним до VPS, коли ваш домашній IP знижений або нещодавно змінений.

Це можна зробити на CPanel за допомогою сценарію PHP - просто переконайтеся, що ви правильно встановили свою безпеку (HTTPS тощо) та прочитали ToS від свого хостинг-провайдера.

https://www.shadowsplace.net/1231/internet/use-whm-cpanel-as-dynamic-dns-service/

Якщо ви імітуєте популярну схему URL-адрес динамічних постачальників DNS, ви можете використовувати вбудовані функції динамічного DNS в обладнанні "чорної скриньки" (наприклад, NAS, IP Cam тощо) та отримати маршрутизатор для переадресації запиту на ваш хост. .

Мій скромний додаток до служби dyndns, який є безкоштовним та працює у багатьох системах (також на маршрутизаторах) - freedns.alash.org

Я використовую його, щоб моя домашня IP-адреса вказувала на якесь вибране доменне ім’я, список якого пропонується безкоштовно. Мій rPi виконує сценарій "curl", і він добре працює для мене (ну, оскільки я не запускаю поштовий сервер, це не проблема, якщо 10 хвилин недоступно).

У мене була така ж ідея запуску поштового сервера і вдома, але ISP заблокував трафік, тому мені довелося відмовитися від нього :-(

З повагою.