Saya memiliki ISP yang tidak menawarkan alamat IP statis, jadi sepertinya semacam Dynamic Domain Name Service (DDNS) adalah solusinya.
Itu salah satu solusinya. Sebagai contoh dari solusi lain, sebuah terowongan IPv6 HurricaneElectric.net menyediakan alamat statis (IPv6) dengan titik akhir terowongan yang dapat dipindahkan. Memang, saat ini, IPv4 akan lebih baik untuk mendukung fungsi seperti itu dengan masyarakat umum, tetapi jika Anda dapat menemukan komputer kooperatif yang bersedia, Anda secara teknis dapat melakukan hal seperti itu dengan IPv4 juga.
Anda perlu memiliki skrip / program yang memantau alamat IP Anda secara berkala, dan jika alamatnya berubah, maka skrip / aplikasi perlu memperbarui nama domain apa pun yang Anda gunakan
Ini terdengar seperti rencana yang solid secara teknis.
Saya hanya perlu kunci API dari perusahaan hosting untuk menyesuaikan catatan domain / IP yang diperlukan secara terprogram ... seseorang beri tahu saya jika saya salah dalam hal ini dan ada cara yang lebih sederhana).
Rincian persisnya akan bergantung pada pilihan pendaftar nama domain tentang bagaimana mereka menerapkan fitur ini. Beberapa mungkin menggunakan semacam kunci API, sementara yang lain mungkin bergantung pada antarmuka web untuk pembaruan otomatis. Di masa lalu, beberapa ISP menyediakan layanan seperti itu, tetapi mengandalkan perubahan manual dalam menanggapi permintaan. Jadi sepenuhnya terserah siapa pun yang memberi Anda layanan.
Begini masalahnya: ketika Anda memperbarui catatan nama domain Anda dengan cara yang telah saya jelaskan di atas, saya telah membaca bahwa mungkin perlu beberapa jam untuk menyebar ke seluruh sistem / dunia (semua server DNS harus diisi ulang dengan alamat Anda yang diperbarui ).
Bah humbug. Perambatan DNS telah diketahui memakan waktu beberapa menit atau beberapa jam atau berhari-hari (mis., 72 jam). Namun, ketika orang sangat menganalisis hal-hal, mereka telah menemukan bahwa banyak waktu "propagasi" yang tidak jelas itu hanya dari penyedia hosting DNS yang lambat untuk diperbarui.
Dalam teori yang lebih baik, Anda hanya perlu menunggu nilai TTL. Meskipun, ada masalah dengan teori itu ...
Namun, beberapa penyedia DDNS berbayar yang saya lihat tampaknya mempromosikan kemampuan mereka untuk membuat perubahan berlaku dekat secara instan (atau setidaknya, lebih cepat dari metode DIY saya). Benarkah? Apakah ada sesuatu yang saya lewatkan?
Oke, inilah kenyataannya: Agar pembaruan Anda berfungsi penuh, Anda harus membuat Internet menyiram cache yang aktif dari informasi lama.
Menurut standar, caching server DNS dapat mengandalkan cache mereka untuk jangka waktu yang ditentukan oleh nilai TTL yang dapat Anda konfigurasi.
Namun, kenyataannya adalah bahwa setidaknya beberapa (dan mungkin bahkan sebagian besar?) ISP yang sangat besar telah dikenal untuk menjalankan server DNS caching mereka sendiri yang telah diketahui sepenuhnya mengabaikan nilai-nilai TTL. Mereka melakukan ini karena mereka merasa seperti jika mereka memperbarui cache DNS mereka lebih jarang, efek keseluruhan akan lebih sedikit bandwidth (dan mungkin lebih sedikit waktu komputasi).
Jadi, setiap server E-Mail yang bergantung pada server DNS seperti itu dapat terpengaruh, dan tidak dapat melihat pembaruan Anda hingga server DNS diperbarui. Dalam beberapa kasus, itu mungkin memakan waktu satu atau dua hari (atau tiga?).
Namun, efek seperti itu menjadi semakin langka. Dalam praktik sebenarnya, sebagian besar server DNS akan menyimpan cache dalam satu atau dua jam.
Karena beberapa cache tidak akan diperbarui secepat yang lain, efeknya adalah bahwa beberapa tempat di Internet akan berfungsi dengan alamat baru, sementara tempat lain masih akan mencoba menggunakan alamat lama. Dalam beberapa jam, kebanyakan komputer akan bekerja dengan baik dengan informasi baru. (Banyak, banyak dari mereka dapat bekerja dalam hitungan menit.)
Perilaku khas perangkat lunak E-Mail adalah mencoba mengirim E-Mail. Jika gagal, maka coba lagi nanti. Server E-Mail biasanya akan terus mencoba ulang (mungkin sekitar satu jam sekali) selama berhari-hari sebelum menyerah. Jadi apa yang mungkin terjadi adalah Anda tidak akan kehilangan E-Mail, tetapi akan sedikit tertunda.
Komentar Alex "semua IP dinamis ada dalam daftar PBL" jelas salah, karena informasi ini tidak terpusat (jadi kata "semua" tidak akurat), tetapi memang benar bahwa banyak IP dinamis ada dalam daftar tersebut, sehingga mungkin berarti bahwa beberapa komputer / perangkat yang terkait dengan E-Mail mungkin memutuskan untuk tidak bekerja sama dengan Anda.
Juga, saya memiliki keprihatinan lain: apakah ada masalah keamanan yang mungkin saya abaikan dengan memiliki penyedia DDNS?
Kekhawatiran terbesar adalah apakah pembaruan Anda ditangani dengan cara yang aman.
Apakah mereka tidak dapat memonitor semua lalu lintas yang mengalir melalui nama domain yang mereka berikan?
Tidak. Pekerjaan server DNS adalah menerima permintaan untuk nama domain, dan memberikan tanggapan. Respons khas tradisional adalah menyediakan satu atau lebih alamat IP. Respons lain dimungkinkan, seperti merujuk ke server DNS lain atau nama domain (mis., Dengan CNAME), atau data lain (mis. Membantu memberikan keamanan melalui standar DNSSec yang lebih baru).
Apakah ada yang punya pendapat yang terinformasi ...
Saya ingin menunjukkan bahwa jika Anda benar-benar ingin menjalankan server E-Mail yang serius, Anda mungkin ingin mempertimbangkan untuk mematuhi standar E-Mail modern. Itu melibatkan lebih dari sekadar mematuhi spesifikasi teknis SMTP dan DNS. Banyak orang menggunakan penyedia besar, dan penyedia besar itu dapat menerapkan harapan mereka sendiri.
Sebagai contoh, saya tahu server E-Mail yang dibuat dengan Debian dan Postgrey tahun yang lalu. Postgrey adalah beberapa perangkat lunak yang menyediakan penanganan anti-spam "greylisting". Namun, versi Postgrey yang digunakan mengasumsikan bahwa ketika server E-Mail mencoba ulang E-Mail, server E-Mail pengirim akan menggunakan alamat IP yang sama ketika melakukannya. Server E-Mail Office 365 telah dikenal untuk mencoba kembali mengirim E-Mail dari alamat IP yang berbeda yang masih dalam subnet IPv6 / 64. Postgrey tidak suka itu.
Karena semakin banyak organisasi telah beralih ke Office 365, ini telah menjadi semakin dan semakin menjadi masalah bagi orang-orang yang menggunakan server E-Mail lama itu. Versi terbaru dari perangkat lunak Postgrey telah dirilis, tetapi cara mudah untuk menginstal perangkat lunak tersebut adalah dengan menggunakan repositori perangkat lunak resmi untuk sistem operasi itu. Jadi, dalam praktiknya, cara cerdas untuk memperbarui perangkat lunak itu adalah dengan memutakhirkan sistem operasi.
Ada konvensi lain, seperti memiliki nama DNS yang dimulai dengan "mail." yang dapat menyebabkan pengaturan Anda dinilai lebih atau kurang dapat dipercaya. Ini dapat memengaruhi apakah perangkat memperlakukan Anda seperti spammer yang tidak patuh, atau seperti perangkat yang layak untuk berkomunikasi.
Tentu, mungkin ketika berbicara sangat ketat tentang spesifikasi teknis resmi, organisasi raksasa melakukan beberapa tindakan yang berbeda dari persyaratan minimum yang diminta oleh dokumen RFC yang berisi spesifikasi teknis dari protokol yang digunakan. Tetapi jika Anda ingin berkomunikasi dengan komunitas Internet yang lebih besar, ada beberapa standar tambahan yang diberlakukan oleh beberapa pemain yang signifikan / besar. Bersiaplah untuk memenuhi standar-standar itu dengan baik, atau bersiaplah untuk menghadapi beberapa masalah.
Saya menjadi agak kabur tentang apa sebenarnya semua standar itu, karena mereka dapat berubah seiring waktu.
Mengenai server E-Mail lama yang perlu memutakhirkan sistem operasi Debian yang lama, mungkin orang harus memperbarui sistem operasinya lebih sering. Maksud saya, bagaimanapun, adalah bahwa pengaturan perangkat lunak yang bekerja dengan baik selama bertahun-tahun sekarang rusak, karena perilaku yang lebih baru yang biasanya digunakan oleh banyak alamat E-Mail. Jika Anda mencoba melakukan hal-hal yang tidak biasa, seperti menggunakan Dynamic DNS pada penyedia Internet yang lebih lambat, Anda mungkin akan menghadapi beberapa masalah tambahan di sepanjang jalan. Ketika Anda terdengar ambisius, mungkin Anda dapat menginvestasikan upaya ke dalamnya. Saya hanya memperingatkan Anda untuk bersiap untuk melakukan itu.
... berkenaan dengan metode mana (dibayar vs. DIY) yang mungkin lebih baik?
Seperti yang ditunjukkan orang lain, membayar akan jauh lebih mudah, dan cukup ekonomis bagi kebanyakan orang. Penawaran besar cenderung memberikan alamat IP stabil yang dapat Anda gunakan untuk merekam MX (jadi E-Mail ada di sana), dan mungkin menyediakan bandwidth yang jauh lebih baik.
DIY lebih baik untuk mendapatkan pengalaman dan mempelajari cara kerja, dan memilih untuk tidak hanya mengandalkan implementasi dari perusahaan besar. Memiliki kontrol lebih besar atas implementasi Anda juga dapat memungkinkan Anda untuk membuat perubahan kustom yang signifikan jauh lebih cepat.
Yang "lebih baik" akan tergantung pada tujuan pribadi Anda, jadi saya serahkan kesimpulan tersebut kepada Anda.