自宅に個人用のメール/カレンダー サーバーを構築しようとしています (確かに難しい、面倒なことなどいろいろあると聞いていますが、それでも試してみたいと思っています)。私が利用している ISP は静的 IP アドレスを提供していないので、何らかの動的ドメイン ネーム サービス (DDNS) が解決策になるようです。
しかし、私は調査を続けていて、少なくともいくつかのオンライン リソースで、自分で DDNS を実行できることが説明されているのを見つけました。IP アドレスを定期的に監視するスクリプト/プログラムが必要で、アドレスが変更された場合は、スクリプト/アプリでホーム サーバーに使用しているドメイン名を更新する必要があります (私はたまたま、このような事態に備えてホスティング プロバイダーにドメインをパークしており、私の理解では、必要なドメイン/IP レコードをプログラムで調整するには、ホスティング会社の API キーだけが必要です...私が間違っていて、もっと簡単な方法がある場合は、誰か教えてください)。
問題は、上で説明した方法でドメイン名レコードを更新すると、システム/世界中に反映されるまでに数時間かかる可能性があるということです (すべての DNS サーバーに更新されたアドレスを再設定する必要があります)。ただし、私が調べた有料の DDNS プロバイダーのいくつかは、変更をほぼ瞬時に (または少なくとも私の DIY 方法よりも速く) 有効にできると宣伝しているようです。これは本当ですか? 何か見落としている点がありますか?
また、もう 1 つ懸念があります。DDNS プロバイダーを利用すると、セキュリティ上の問題を見落としてしまう可能性があるでしょうか。プロバイダーは、提供しているドメイン名を通過するすべてのトラフィックを監視できないのでしょうか。どちらの方法 (有料 vs. DIY) がより良いかについて、情報に詳しい意見をお持ちの方はいらっしゃいますか。
お時間をいただきありがとうございます。
答え1
自宅に個人用のメール/カレンダー サーバーを構築しようとしています (確かに難しい、面倒などいろいろあると聞いていますが、それでも試してみたいと思っています)。
メールの部分ではおそらくあまりうまくいかないでしょう。@Alex の回答を参照してください。
IPアドレスを定期的に監視するスクリプト/プログラムが必要であり、アドレスが変更された場合は、スクリプト/アプリがホームサーバーに使用しているドメイン名を更新する必要があります。
ほぼその通りです。
必要なドメイン/IPレコードをプログラムで調整するには、ホスティング会社のAPIキーが必要です。
はい、ただし、会社が一般的な「すべてをホストする」サービスを提供している場合、DNS 管理 API がまったくない可能性があり (代わりに Web とメールに重点を置いている)、ドメインを別の場所に移動する必要があるかもしれません。
問題は、上で説明した方法でドメイン名レコードを更新すると、システム/世界中に伝播するのに数時間かかる可能性があるということです (すべての DNS サーバーに更新されたアドレスを再入力する必要があります)。
いいえ。DNS ホスティング プロバイダー自身のシステムのみを更新する必要があります。その他のシステムでは、永続的な記録は保持されません。各 (サブ) ドメインの「TTL」(Time To Live) フィールドに示された期間、個々の検索の結果をキャッシュするだけです。
しかし、私が調べたいくつかの有料 DDNS プロバイダーは、変更をほぼ瞬時に (または少なくとも私の DIY 方法よりも速く) 有効にできると宣伝しているようです。それは本当ですか? 何か見落としている点がありますか?
動的ドメインの TTL を非常に低く設定できる (数秒まで) と推測しますが、これはキャッシュからすぐに削除されることを意味しますが、その代償として DDNS プロバイダー自体がさらに多くのリクエストを受信することになります (DNS サーバーとデータベースの負荷が高まり、料金を高く請求する口実になります)。それ自体は特別なことではなく、任意の DIY 方法で実装できます。
提供したドメイン名を通過するすべてのトラフィックを監視できるのではないでしょうか?
いいえ。DNS サーバーはアドレス (電話帳のようなもの) のみを提供し、それ以上の通信には関与しません。
（プロバイダーが実際に誤ったデータを返すこれにより、ニュースサイトがこれを知った瞬間に、同社のTTLが大幅に短縮されることになる。
そうは言っても、API がどのように動作するかには注意してください。もちろん、サービスに脆弱性がないとは言い切れませんが、(たとえば) API が暗号化されていない HTTP 経由で実行され、API キーがそのまま送信される場合、それは信頼できるものではありません。
答え2
静的IPを持っていない場合、DDNSソリューションを使用する場合はメールサーバーを忘れてください。ほとんどのメールサーバーは、すべての動的IPがＰＢＬリスト。(住宅用 IP にメール サーバーを置くのがなぜ良い考えではないのかについては、PS セクションで詳しく説明していますが、中間の安価な VPS (仮想プライベート サーバー) を使用する回避策はまだあります。）
「自分で DDNS する」という点については、API 経由で無料の IP 更新を提供する優れたドメイン レジストラの場合、プログラムで実行する必要があるのは、パブリック IP を定期的に確認し、変更があった場合は新しい IP をレジストラに送信して、A(AAAA) レコードを更新することだけです。ちなみに、最近のルーターのほとんどには、すでにこのような機能が備わっています (IP を監視して DDNS プロバイダーに報告する)。
システム/世界全体に広がるには数時間かかるかもしれないと読んだことがある
これは DNS プロバイダーによって異なりますが、信頼できるレジストラは TTL (IP が変更される頻度を他のユーザーに通知する時間) を 5 分に設定することを許可しています。すべての転送中間 DNS サーバーが高負荷を回避するためにこれに従うわけではありませんが、通常はドメイン所有者の TTL に従わない場合でも、数時間を超えることはほとんどありません。ほとんどのフォワーダーは、ドメイン TTL で設定した場合と同じようにキャッシュを更新します。
DDNS プロバイダーを利用する際に見落としがちなセキュリティ上の問題はありますか?
オンラインにすると、セキュリティ上の問題が発生する可能性があります。 迷惑なゲストを避けるために、サーバーをローカル ネットワークから分離してください。
どちらの方法（有料 vs. DIY）がより良いかについて、情報に詳しい意見をお持ちの方はいらっしゃいますか?
DDNS を使用すると、時間とお金を無駄にすることになります。最近では、月額 3 ～ 4 ドルでまともな VPS (仮想プライベート サーバー) を入手できます。Web サイト (作成する予定がある場合) は通常、多くのスペースを取らないため VPS で直接ホストできますが、メール サーバーは、サーバーを長期間実行したり、大量のメールが予想される場合は問題になる可能性があります。通常、古いメールを削除しなくても、中小企業では 3 ～ 5 年は 20 GB のスペースで十分です。大量のメールが予想される場合でも、nginxメール トラフィックを自宅にプロキシする機能を使用できます。そのため、プライマリ メール サーバーを動的 IP で自宅にホストし、VPS (静的 IP を持つ) が受信/送信トラフィックを自宅にプロキシします。DNS 伝播を心配する必要がなく、ドメインが常に VPS の静的 IP を指すため、このような構成で独自の VPS を苦労せずに使用できます。 VPS がトラフィックをプロキシする場所を認識できるように、自宅の IP アドレスの変更を VPS に報告する必要がありますが、これははるかに簡単で、VPS 上のいくつかの URL をクエリし、受信 IP のログを解析して nginx を調整し、常に現在地がわかるようにするだけです。
追伸
このトピックはスーパーユーザーにとって興味深いものであることがわかったので、もう少し詳細を追加したいと思います。
ＰＢＬリストには、一般的に動的IPであるIPのデータベースが保持されるため、ＰＢＬ メールサーバーの運営者にとって非常に役立ちます。動的IPでメールサーバーを許可しないのは技術的な問題でもISPが悪いわけでもありません。問題は、動的IPからのメールトラフィックのほとんどが、スパムやマルウェアを大量に送信している感染したコンピューターから来ていることです。DDoS受信サーバーが標的である場合は、ポート25への送信接続をブロックするISPもあります。DDoS、しかしそうではないものもあります。実質的にすべての企業のメールサーバーは、ＰＢＬスパムを大幅に削減するリスト。
2 つ目の効果的なスパム対策ソリューションは、DNS に逆 PTR レコードがなく、ドメインの DNS レコードと一致しない IP からの接続をドロップすることです。PTR レコードのない静的 IP からの接続であっても、通常は設定が誤っているか、スパム集団が実行しているサーバーからの接続がほとんどです (一部の大規模 (ただし不注意な) プロバイダーは除外される可能性がありますが、ホワイトリストに手動で追加できます)。VPS で逆 PTR レコードを設定するのは数分で済みますが、ISP から取得した静的 IP の場合はそうではなく、PTR を設定するプロセスは通常面倒です (ISP に電話して、IP の元の所有者であることを確認した後にチケットを送信し、逆 PTR レコードを設定する必要があるシステム管理者の慈悲を待つ必要があります。数時間、場合によっては数日かかります)。
また、重要ではありませんが...メールの偽造を防ぐために、ほとんどのメールサーバーの所有者は、いわゆるSPF（送信者ポリシーフレームワーク）は、ドメインに代わってメールを送信することを許可されたDNS承認済みIPアドレスを設定することで、最も高速なポリシー処理方法を指定できます。（承認済みサーバーは、完全修飾ドメイン名MX レコードへの参照として使用できますが、サーバーに接続するために DNS を経由する余分なラウンドトリップが発生します) そのため、DNS でフローティング IP を管理するのは楽しいことではありません。
答え3
私の ISP は静的 IP アドレスを提供していないので、何らかの動的ドメイン名サービス (DDNS) が解決策になるようです。
これは 1 つのソリューションです。別のソリューションの例として、HurricaneElectric.net の IPv6 トンネルは、移動可能なトンネル エンドポイントを持つ静的 (IPv6) アドレスを提供します。確かに、現時点では、一般の人々にとってこのような機能をサポートするには IPv4 のほうが望ましいですが、協力的なコンピュータが見つかれば、技術的には IPv4 でも同様のことを行うことができます。
IPアドレスを定期的に監視するスクリプト/プログラムが必要であり、アドレスが変更された場合は、スクリプト/アプリが使用しているドメイン名を更新する必要があります。
これは技術的にしっかりした計画のように思えます。
必要なドメイン/IP レコードをプログラムで調整するには、ホスティング会社の API キーが必要です...私が間違っていて、もっと簡単な方法がある場合は、誰か教えてください。
正確な詳細は、ドメイン名登録業者がこの機能をどのように実装するかによって異なります。何らかの API キーを使用する業者もあれば、自動更新のために Web インターフェイスを使用する業者もあります。昔は、一部の ISP がこのようなサービスを提供していましたが、リクエストに応じて手動で変更する必要がありました。したがって、完全にサービスを提供する業者次第です。
問題は、上で説明した方法でドメイン名レコードを更新すると、システム/世界中に伝播するのに数時間かかる可能性があるということです (すべての DNS サーバーに更新されたアドレスを再入力する必要があります)。
なんてこった。DNS の伝播には数分、数時間、あるいは数日 (たとえば 72 時間) かかることが知られています。しかし、人々が徹底的に分析した結果、その漠然とした「伝播」時間の多くは、単に DNS ホスティング プロバイダーの更新が遅いことが原因であることがわかりました。
理論的には、TTL 値を待つだけでよいはずです。ただし、この理論には問題があります...
しかし、私が調べたいくつかの有料 DDNS プロバイダーは、変更をほぼ瞬時に (または少なくとも私の DIY 方法よりも速く) 有効にできると宣伝しているようです。それは本当ですか? 何か見落としている点がありますか?
さて、現実はこうです。更新を完全に有効にするには、インターネットの古い情報のアクティブ キャッシュを消去する必要があります。
標準によれば、キャッシュ DNS サーバーは、設定可能な TTL 値で指定された期間、キャッシュに依存する場合があります。
しかし、現実には、少なくとも一部 (おそらくほとんど?) の非常に大規模な ISP は、TTL 値を完全に無視する独自のキャッシュ DNS サーバーを運用していることが知られています。DNS キャッシュの更新頻度を低くすると、全体的な影響として帯域幅が減り (場合によっては計算時間も短くなる) ると考えているため、このようなことが行われています。
したがって、このような DNS サーバーに依存する電子メール サーバーは影響を受け、DNS サーバーが更新されるまで更新を認識できない可能性があります。場合によっては、1 日か 2 日 (または 3 日?) かかることがあります。
しかし、そのような影響はますます稀になってきています。実際には、ほとんどの DNS サーバーのキャッシュは 1 ～ 2 時間以内にフラッシュされます。
一部のキャッシュは他のキャッシュほど速く更新されないため、インターネット上の一部の場所では新しいアドレスが機能し、他の場所では古いアドレスの使用が継続されることになります。数時間以内に、ほとんどのコンピューターが新しい情報で正常に機能するようになります。(数分以内には、多くのコンピューターが機能するかもしれません。)
電子メール ソフトウェアの一般的な動作は、電子メールの送信を試行することです。それが失敗した場合は、後で再試行します。電子メール サーバーは通常、数日間再試行 (おそらく 1 時間に 1 回程度) を続けます。そのため、電子メールが失われることはありませんが、多少の遅延が生じる可能性があります。
Alex の「すべての動的 IP は PBL リストにある」というコメントは明らかに間違っています。この情報は分散化されているため (したがって、「すべて」という語は不正確です)、多くの動的 IP がそのようなリストにあるのは事実であり、したがって、電子メールに関連する一部のコンピューター/デバイスが、あなたと協力しないことに決める可能性があることを意味します。
また、もう 1 つ懸念があります。DDNS プロバイダーを利用する際に見落としているセキュリティ上の問題があるでしょうか?
最大の懸念は、更新が安全な方法で処理されるかどうかです。
提供したドメイン名を通過するすべてのトラフィックを監視できるのではないでしょうか?
いいえ。DNS サーバーの役割は、ドメイン名の要求を受信し、応答を返すことです。従来の典型的な応答は、1 つ以上の IP アドレスを提供することです。別の DNS サーバーまたはドメイン名 (CNAME など) を参照したり、他のデータ (新しい DNSSec 標準によるセキュリティの提供など) を参照するなど、他の応答も可能です。
情報に詳しい意見をお持ちの方はいらっしゃいますか...
本格的な電子メール サーバーを運用したいのであれば、最新の電子メール標準に準拠することを検討したほうがよいことを指摘しておきます。これには、SMTP および DNS の技術仕様に準拠する以上のことが含まれます。多くの人が大手プロバイダーを使用しており、それらの大手プロバイダーは独自の期待を実装している可能性があります。
たとえば、私は数年前に Debian と Postgrey を使用してセットアップされた電子メール サーバーを知っています。Postgrey は、"グレーリスト" によるスパム対策処理を提供するソフトウェアです。ただし、使用されている Postgrey のバージョンでは、電子メール サーバーが電子メールを再試行する場合、送信側の電子メール サーバーは同じ IP アドレスを使用することを前提としています。Office 365 の電子メール サーバーは、IPv6 /64 サブネット内にある別の IP アドレスから電子メールの送信を再試行することが知られています。Postgrey はこれを好みません。
Office 365 に切り替える組織が増えるにつれて、古い電子メール サーバーを使用しているユーザーにとって、この問題はますます深刻になってきています。Postgrey ソフトウェアの新しいバージョンがリリースされましたが、そのようなソフトウェアをインストールする簡単な方法は、そのオペレーティング システムの公式ソフトウェア リポジトリを使用することです。したがって、実際には、そのソフトウェアを更新する賢い方法は、オペレーティング システムをアップグレードすることです。
DNS 名が「mail.」で始まるなどの他の規則もあり、これにより、セットアップの信頼性が増減する可能性があります。これは、デバイスがあなたを非準拠のスパマーとして扱うか、通信する価値のあるデバイスとして扱うかに影響する可能性があります。
確かに、公式の技術仕様について非常に厳密に言えば、巨大組織は、使用されているプロトコルの技術仕様を含む RFC ドキュメントで要求されている最小要件とは異なるアクションを実行している可能性があります。しかし、より大規模なインターネット コミュニティと通信したい場合は、一部の重要な/大規模なプレーヤーによって課される追加の標準があります。これらの標準を十分に満たす準備をしてください。そうしないと、何らかの問題に遭遇する準備をしてください。
これらすべての基準が正確に何であるかについては、時間の経過とともに変化する可能性があるため、少し曖昧になっています。
古い Debian オペレーティング システムをアップグレードする必要がある古い電子メール サーバーについては、おそらくユーザーはオペレーティング システムをもっと頻繁にアップグレードする必要があるでしょう。ただし、私が言いたいのは、多くの電子メール アドレスで一般的に使用されている新しい動作のせいで、何年も問題なく動作していたソフトウェア セットアップが壊れてしまったということです。遅いインターネット プロバイダーでダイナミック DNS を使用するなど、通常とは異なることをしようとすると、途中で追加の問題に遭遇する可能性が高くなります。あなたは意欲的なようですので、その努力に投資してもよいかもしれません。私は、その必要があることを覚悟しておくように警告しているだけです。
...どちらの方法（有料 vs. DIY）がより良いのでしょうか？
他の人が指摘しているように、有料のほうがはるかに簡単で、ほとんどの人にとってはかなり経済的です。大手プロバイダーは、MX レコードをポイントできる安定した IP アドレス (電子メールがそこに送信されるため) を提供し、大幅に優れた帯域幅を提供する可能性があります。
DIY は、経験を積み、仕組みを学び、大手企業の実装だけに頼らないことを選択するのに適しています。実装をより細かく制御できるため、大幅なカスタム変更をより迅速に行うこともできます。
どちらが「良い」かは個人の目標によって異なるため、結論はあなたにお任せします。
答え4
DDNS の部分については他の回答ですでに説明されています。
説明しようと思いますなぜ電子メールを送信するには別のサーバーを使用する必要があります(@Alex からの簡単な説明が不完全であるため)。
最も重要なのは、電子メールを送信するには有効な逆 PTR レコードが必要であることです。多くの電子メール サーバーはこれをチェックし、IP アドレスの逆 DNS レコードが送信者のドメインと一致しない場合、メールを返送します。このレコードは、IP アドレスの所有者 (たとえば、ISP) によって提供されます。
さて、有効で動的に更新される逆 DNS を何とか入手したと想像してみましょう (笑)。それでも、ドメインが正当であり、送信メールがスパムではないことを全員に納得させる必要があります。
@Alex が説明したように、小規模なメールホスティング業者は spamhaus やその他のオンライン ブラックリストを好んで使用します。しかし、私はそれらの企業管理者が他の多くの愚かな行為 (Gmail/Hotmail 以外からのメールをすべてブロックするなど) を行っているのを見てきました。実際、一部の「企業管理者」だけがそうしているわけではありません。ソースフォージ正当な企業メールドメインからの登録をブロックします。「理由はわかりませんが、当社のスパムフィルターがあなたを悪質と判断したためです」。無視してください。空の下ではすべての人と互換性を保つことはできません。
最近の大手メールホスティング業者は、spamhaus やその他の PBL には頼っていません。彼らは独自にあなたの信頼性を追跡しています。送信者の評判 (少なくともその大部分) は IP に結び付けられています。これは、スパマーがホスティング業者から頻繁に追い出されるため、IP を変更せざるを得ないからです。Gmail の観点からは、最近作成したドメイン/IP は一般的なスパマーと何ら変わりありません。メールの送信を開始したとき、あなたの評判は低いです (デフォルトでスパマーとして扱われます)。送信メールのほとんどはスパムとしてマークされます。誰かがあなたのメールに返信するか、特に正当なメールとしてマークすると (メール プロバイダーの Web インターフェースで対応するボタンを押すことによって)、あなたに対する信頼がわずかに高まります。おわかりのように、送信者の評判を高めるには、何年も同じ IP で同じドメインを使用する必要があります。これは、動的 IP では確実に実行できません。
ホスティング会社から VPS をリースすると、ホーム サーバーを動的 IP で維持することがずっと簡単になります。その VPS を、非常に低い TTL を持つ独自の DDNS サーバーとして使用できます。DNS を使わずに、他の手段 (HTTP リダイレクトなど) を使用して、ホーム ボックスの IP の変更を処理することもできます。ホーム ボックスで直接メールを受信することはできますが、ホーム IP がダウンしたり最近変更されたりした場合は、オプションで VPS にフォールバックすることもできます。