パブリックDNSのプライベートIPアドレス

ファイアウォールの背後に、メールのパブリックAレコードを持つSMTP専用メールサーバーがあります。。 このメールサーバーにアクセスする唯一の方法は、同じファイアウォールの背後にある別のサーバーからです。独自のプライベートDNSサーバーは実行していません。

プライベートDNSアドレスをパブリックDNSサーバーのAレコードとして使用することをお勧めしますか？または、これらのサーバーレコードを各サーバーのローカルホストファイルに保持することをお勧めしますか？

一部の人々は、プライベートDNSアドレスがプライベートIPアドレスを開示するべきではないと言うでしょう。...潜在的な攻撃者にプライベートシステムを悪用するのに必要な情報を提供していると考えて。

個人的には、難読化はセキュリティの貧弱な形態だと思います。特にIPアドレスについて話している場合は、一般に推測が容易であるため、現実的なセキュリティ上の妥協とは見なされません。

ここでのより大きな考慮事項は、パブリックユーザーがホストアプリケーションの通常のパブリックサービスの一部としてこのDNSレコードを取得しないようにすることです。すなわち、外部DNSルックアップは、どういうわけか到達できないアドレスへの解決を開始します。

それ以外にも、プライベートアドレスAレコードをパブリックスペースに置くことが問題になる根本的な理由はありません。特に、ホストする代替DNSサーバーがない場合はそうです。

このレコードをパブリックDNSスペースに配置することにした場合、すべての「プライベート」レコードを保持するために、同じサーバー上に別のゾーンを作成することを検討できます。これにより、それらがプライベートであることを明確にすることができます....たった1つのAレコードについては、おそらく気にしないでしょう。

私はしばらく前にNANOGリストでこのトピックについて長い議論をしました。私はいつもそれは悪い考えだと思っていましたが、実際にはそれほど悪い考えではないことがわかりました。困難は主にrDNSルックアップ（プライベートアドレスの場合は外部では機能しない）に起因するものであり、VPNなどを介してアドレスへのアクセスを提供する場合、VPNクライアントが適切に保護されていることを確認することが重要ですVPNがダウンしているときのトラフィックの「漏洩」。

私はそれのために行くと言います。攻撃者が名前を内部アドレスに解決できることから何か意味のあるものを得ることができれば、より大きなセキュリティ問題を抱えていることになります。

一般に、RFC1918アドレスをパブリックDNSに導入すると、実際の問題ではないにしても、将来のある時点で混乱が生じます。IP、ホストレコード、またはゾーンのプライベートDNSビューを使用して、ファイアウォールの背後にあるRFC1918アドレスを使用しますが、パブリックビューには含めません。

提出された他の応答に基づいて私の応答を明確にするために、パブリックDNSにRFC1918アドレスを導入することは、セキュリティ上の問題ではなく、偽造だと思います。誰かが問題をトラブルシューティングするために私に電話し、DNSのRFC1918アドレスを偶然見つけた場合、私は本当にゆっくり話し始め、最近再起動したかどうかを尋ねます。たぶんそれは私の側のである、私は知らない。しかし、私が言ったように、それはする必要のあることではなく、ある時点で混乱と誤解（コンピューターではなく人間）を引き起こす可能性があります。なぜそれを危険にさらすのですか？

いいえ、プライベートDNSアドレスをパブリックDNSに入れないでください。

まず、情報が漏洩しますが、これは比較的小さな問題です。

MXレコードがその特定のホストエントリを指している場合の最悪の問題は、そのホストエントリにメールを送信しようとすると、だれでもメール配信タイムアウトが発生することです。

送信者のメールソフトウェアによっては、バウンスが発生する場合があります。

さらに悪いことに、RFC1918アドレススペース（ネットワーク内で使用する必要があります）を使用していて、送信者もそうである場合、代わりにメールを自分のネットワークに送信しようとする可能性があります。

例えば：

• ネットワークには内部メールサーバーがありますが、スプリットDNSはありません
• したがって、adminはDNSにパブリックIPアドレスと内部IPアドレスの両方を配置します
• MXレコードは両方を指します：

 $ORIGIN example.com
 @        IN   MX    mail.example.com
 mail     IN   A     192.168.1.2
          IN   A     some_public_IP

• これを見た人は192.168.1.2に接続しようとするかもしれません
• 最良の場合、ルートがないためバウンスします
• ただし、192.168.1.2を使用するサーバーもある場合、メールは間違った場所に送られます

はい、それは壊れた構成ですが、私はこれを（そしてさらに悪いことに）見ました。

いいえ、それはDNSのせいではなく、言われたことをしているだけです。

可能性はわずかですが、MITM攻撃のいくつかに備えて設定している可能性があると思います。

私の懸念はこれでしょう。そのメールサーバーを指すように構成されたメールクライアントを持つユーザーの1人が、ラップトップを他のネットワークに接続するとします。他のネットワークでも同じRFC1918が使用されている場合はどうなりますか。そのラップトップは、smtpサーバーへのログインを試行し、ユーザーの資格情報を必要のないサーバーに提供する可能性があります。これは特にあなたがSMTPと言っていて、SSLを必要とする場所については言及しなかったので、本当です。

2つのオプションは/ etc / hostsで、パブリックゾーンにプライベートIPアドレスを配置します。前者をお勧めします。これが多数のホストを表す場合、独自のリゾルバを内部で実行することを検討する必要があります。それほど難しくはありません。

それに微妙な問題があるかもしれません。1つは、DNS Rebind攻撃の一般的なソリューションが、パブリックDNSサーバーから解決されたローカルDNSエントリをフィルタリングすることです。したがって、リバインド攻撃に自分自身を開放するか、ローカルアドレスが機能しないか、より高度な構成が必要です（ソフトウェア/ルーターで許可されている場合）。

hostsファイルに保存することをお勧めします。とにかく1台のマシンのみが接続することになっている場合、パブリックDNSに入れることで何が得られますか？

プライベートで10.0.0.0/8、192.168.0.0/16、または172.16.0.0/12を意味する場合は、しないでください。ほとんどのインターネットルーターは、それが何であるかを認識します。プライベートアドレスは、パブリックインターネットに直接送信されることはありません。これが、NATの人気を支えました。パブリックDNSサーバーにアクセスしようとすると、DNSからプライベートIPアドレスが取得されますが、パケットはどこにも送信されません。接続がプライベートアドレスにインターネットを横断しようとするため、途中の一部の（正常に構成された）ルーターはパケットをそのまま食べてしまいます。

「外部」から「内部」に届くメールを取得したい場合、ある時点で、パケットがファイアウォールを通過する必要があります。これを処理するDMZアドレスを設定することをお勧めします。これは、設置されているルーター/ファイアウォールによって厳密に制御される単一のパブリックIPアドレスです。あなたが記述する既存のセットアップは、まさにそれを行うように聞こえます。

編集：意図の明確化...（以下のコメントを参照）。これが意味をなさない場合、私は自分の投稿を削除することに投票します。

同様の情報を探していたので、ここに到着しました。多くの人がプライベートIPアドレスを漏らしてもいいと言っていることに驚きました。ハッキングされるという点では、安全なネットワーク上にいる場合でも大きな違いはありません。ただし、DigitalOceanはすべてのローカルネットワークトラフィックをまったく同じケーブルでやり取りしており、誰もが実際に他のすべてのトラフィックにアクセスできます（おそらく中間者攻撃で実行可能です）。情報は確かに私のトラフィックをハッキングするための一歩をあなたに与えます。（現在、各クライアントには、AWSなどの他のクラウドサービスと同様に、専用の予約済みプライベートネットワークがあります。）

そうは言っても、独自のBIND9サービスを使用すると、パブリックIPとプライベートIPを簡単に定義できます。これはview、条件を含む機能を使用して行われます。これにより、自分の内部IPアドレスの1つから質問している場合にのみ、1つのDNSを照会し、内部IPに関する回答を取得できます。

セットアップには2つのゾーンが必要です。選択にはを使用しmatch-clientsます。BIND9を使用したTwo-in-one DNSサーバーからのセットアップの例を次に示します。

acl slaves {
    195.234.42.0/24;    // XName
    193.218.105.144/28; // XName
    193.24.212.232/29;  // XName
};

acl internals {
    127.0.0.0/8;
    10.0.0.0/24;
};

view "internal" {
    match-clients { internals; };
    recursion yes;
    zone "example.com" {
        type master;
        file "/etc/bind/internals/db.example.com";
    };
};
view "external" {
    match-clients { any; };
    recursion no;
    zone "example.com" {
        type master;
        file "/etc/bind/externals/db.example.com";
        allow-transfer { slaves; };
    };
};

ここに外部ゾーンがあり、IPはプライベートではないことがわかります

; example.com
$TTL    604800
@       IN      SOA     ns1.example.com. root.example.com. (
                     2006020201 ; Serial
                         604800 ; Refresh
                          86400 ; Retry
                        2419200 ; Expire
                         604800); Negative Cache TTL
;
@       IN      NS      ns1
        IN      MX      10 mail
        IN      A       192.0.2.1
ns1     IN      A       192.0.2.1
mail    IN      A       192.0.2.128 ; We have our mail server somewhere else.
www     IN      A       192.0.2.1
client1 IN      A       192.0.2.201 ; We connect to client1 very often.

内部ゾーンについては、最初に外部ゾーンを含めます。これがどのように機能するかです。つまり、内部コンピューターの場合は、内部ゾーンにのみアクセスするため、外部ゾーンの定義が必要なので、$includeコマンドは次のようになります。

$include "/etc/bind/external/db.example.com"
@       IN      A       10.0.0.1
boss    IN      A       10.0.0.100
printer IN      A       10.0.0.101
scrtry  IN      A       10.0.0.102
sip01   IN      A       10.0.0.201
lab     IN      A       10.0.0.103

最後に、すべてのコンピューターがそのDNSとそのスレーブを使用するようにする必要があります。静的ネットワークを想定すると、/etc/network/interfacesファイルを編集し、nameserverオプションでDNS IPを使用することを意味します。このようなもの：

iface eth0 inet static
    ...
    nameserver 10.0.0.1 10.0.0.103 ...

これで準備は完了です。