Answers:
有人会说，任何公共DNS记录都不应公开私有IP地址。...以为是让潜在的攻击者可以利用一些利用私有系统可能需要的信息。
就我个人而言，我认为混淆是一种较差的安全性形式，尤其是在我们谈论IP地址时，因为总的来说无论如何它们都很容易猜到，因此我不认为这是现实的安全性折衷。
这里更大的考虑是确保您的公共用户不要将此DNS记录作为托管应用程序的常规公共服务的一部分。即：外部DNS查找以某种方式开始解析为他们无法到达的地址。
除此之外，我看不出将私有地址A记录放入公共空间是否有问题的根本原因…………尤其是当您没有备用DNS服务器来承载它们时。
如果确实决定将此记录放入公共DNS空间，则可以考虑在同一服务器上创建一个单独的区域来保存所有“私有”记录。这将使它们更加明确地表明它们是私有的。...但是对于一个A唱片，我可能不会打扰。
不久前，我在NANOG列表上就此主题进行了长时间的讨论。尽管我一直认为这是一个坏主意，但事实证明，这在实践中并不是一个坏主意。困难主要来自rDNS查找（用于私有地址，只是在外部环境中不起作用），当您通过VPN或类似方式提供对地址的访问时，确保正确保护VPN客户端免受访问很重要VPN断开时“泄漏”流量。
我说去吧。如果攻击者能够从解析名称到内部地址的过程中获得有意义的意义，那么您将面临更大的安全问题。
通常，在将来的某个时候，将RFC1918地址引入公共DNS会引起混乱（即使不是真正的问题）。使用您区域的IP，主机记录或私有DNS视图来使用防火墙后面的RFC1918地址，但不要将它们包括在公共视图中。
为了根据其他提交的响应澄清我的响应，我认为将RFC1918地址引入公共DNS是一个人造问题，而不是安全问题。如果有人打电话给我解决问题，而我偶然发现了DNS中的RFC1918地址，我的谈话速度就会非常缓慢，并询问他们最近是否重新启动。我不知道这也许对我来说很势利。但是就像我说的那样，这不是必须要做的事情，并且在某些时候可能会引起混乱和沟通不畅（人，而不是计算机）。为什么要冒险呢？
不，不要将您的私有IP地址放在公共DNS中。
首先，它泄漏信息，尽管这是一个相对较小的问题。
如果您的MX记录指向该特定主机条目，则更糟糕的问题是，任何尝试向其发送邮件的人最多将获得邮件传递超时。
根据发件人的邮件软件，它们可能会反弹。
更糟糕的是，如果您使用的是RFC1918地址空间（您应该在网络内部），而发件人也是如此，那么他们很有可能会尝试将邮件传递到自己的网络中。
例如：
$ORIGIN example.com
@ IN MX mail.example.com
mail IN A 192.168.1.2
IN A some_public_IP
是的，这是一个损坏的配置，但是我已经看到了这种情况（而且更糟）。
不，这不是DNS的错，它只是在执行所告知的操作。
尽管可能性很小，但我认为您可能已经准备好接受MITM攻击。
我担心的是这个。假设您有一个配置了指向该邮件服务器的邮件客户端的用户，将他们的笔记本电脑带到其他网络。如果其他网络也恰好使用相同的RFC1918，将会发生什么情况。该笔记本电脑可能会尝试登录到smtp服务器，并将用户的凭据提供给不应该包含该服务器的服务器。尤其是因为您说的是SMTP，而没有提到您需要SSL。
您的两个选项是/ etc / hosts，并在您的公共区域中放置一个私有IP地址。我建议前者。如果这表示大量主机，则应考虑在内部运行自己的解析器，这并不难。
可能有一些细微的问题。一种是针对DNS重新绑定攻击的常见解决方案会过滤从公共DNS服务器解析的本地DNS条目。因此，您要么开放自己以重新绑定攻击，要么本地地址不起作用，或者需要更复杂的配置（如果您的软件/路由器甚至允许的话）。
最好将其保留在hosts文件中。如果始终只有一台计算机连接到该计算机，那么将其放入公共DNS会获得什么收益？
/etc/hosts文件不切实际，因为然后所有2,000台计算机都需要管理这些IP /名称对...
如果私下里是10.0.0.0/8、192.168.0.0/16或172.16.0.0/12，那么请不要。大多数Internet路由器以它的本质来识别它- 绝不能以直接方式路由到公共Internet 的私有地址，这有助于NAT的普及。任何尝试联系您的公共DNS服务器的人都将从DNS检索私有IP地址，只是将数据包发送到....无处。当他们的连接尝试将Internet遍历到您的专用地址时，沿途的某些（配置合理）路由器会简单地吞噬该数据包。
如果您希望从“外部”获取电子邮件，而从“内部”获取电子邮件，则在某些时候，数据包必须穿过防火墙。我建议设置一个DMZ地址来处理此问题-一个单一的公共IP地址，该地址由您安装的任何路由器/防火墙严格控制。您描述的现有设置听起来确实可以做到这一点。
编辑：意图的澄清...（请参阅下面的评论）。如果这没有意义，我将投票删除自己的帖子。
我到达这里的原因是我在寻找类似的信息，但感到惊讶的是，许多人说泄漏您的私有IP地址很好。我想就被黑客入侵而言，如果您处于安全的网络中并没有太大的区别。但是，DigitalOcean可以使用完全相同的电缆来传输所有本地网络流量，而每个人实际上都可以访问其他人的流量（可能对“中间人攻击”是可行的。）如果您只是将一台计算机放在同一数据中心，信息无疑可以使您更进一步地窃取我的流量。（现在，每个客户端都有自己的保留专用网络，就像其他云服务（例如AWS）一样。）
话虽如此，利用您自己的BIND9服务，您可以轻松定义公共IP和私有IP。使用view包含条件的功能可完成此操作。这样，仅当您从自己的内部IP地址中进行查询时，才可以查询一个DNS并获得有关内部IP的答案。
该设置需要两个区域。选择使用match-clients。这是使用BIND9从二合一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 ...
现在您应该已经准备就绪。