将私有IP地址用作公共DNS服务器中的A记录是一个好主意-还是最好将这些服务器记录保留在每个DNS服务器中服务器本地主机文件？
#1 楼
有人会说，任何公共DNS记录都不应公开私有IP地址...。以为您使潜在的攻击者可以利用一些利用私有系统可能需要的信息。就我个人而言，我认为混淆是一种较差的安全性形式，尤其是在我们谈论IP地址时，因为总的来说无论如何它们都很容易猜到，因此我不认为这是现实的安全性折衷办法。
这里更大的考虑是确保您的公共用户不要在托管应用程序的常规公共服务中提取此DNS记录。即：外部DNS查找以某种方式开始解析为他们无法到达的地址。
除此之外，我看不出将私有地址A记录放入公共空间的根本原因。 ..尤其是当您没有备用DNS服务器来托管它们时。
如果您决定将此记录放入公共DNS空间，则可以考虑在同一服务器上创建一个单独的区域来保存所有“私人”记录。这样可以更清楚地表明它们打算是私有的。...不过，对于一个A记录，我可能不会打扰。
#2 楼
不久前，我在NANOG列表上就此主题进行了长时间的讨论。尽管我一直认为这是一个坏主意，但事实证明，这在实践中并不是一个坏主意。困难主要来自rDNS查找（用于私有地址，只是在外部环境中不起作用），当您通过VPN或类似方式提供对地址的访问时，确保适当保护VPN客户端免受当VPN断开时“泄漏”流量。我赞成这样做。如果攻击者能够从解析名称到内部地址的过程中获得有意义的意义，那么您将面临更大的安全问题。
评论
+1，感谢您在FUD对这个问题的所有答复中都保持理智。我的下背部区域存在“安全风险”，看到路由问题和DNS问题并入一个“不做”的反应，这简直让我想知道各地运行网络的人员的能力。
– MihaiLimbăşan
09年5月5日在16:19
更正：使“看到路由问题和DNS问题以及身份验证/身份问题合谋”。
– MihaiLimbăşan
09年5月5日在16:32
#3 楼
通常，将RFC1918地址引入公共DNS会在将来某个时候引起混乱，即使不是真正的问题也是如此。使用您所在区域的IP，主机记录或私有DNS视图来使用防火墙后面的RFC1918地址，但不要将它们包含在公共视图中。要根据其他提交的响应澄清我的响应，我认为将RFC1918地址引入公共DNS是一个人造问题，而不是安全问题。如果有人打电话给我解决问题，而我偶然发现了DNS中的RFC1918地址，我的谈话速度就会非常缓慢，并询问他们最近是否重新启动。我不知道这也许对我来说很势利。但是就像我说的那样，这不是必须要做的事情，并且在某些时候可能会引起混乱和沟通不畅（人为而非计算机）。为什么要冒险？
评论
这些是什么真正的问题？人们会以什么方式感到困惑？
–womble♦
09年5月5日，2：30
所以...有礼貌...不将1918年地址放入公共DNS中？我遇到了许多“隐藏”和“水平分割” DNS区域引起的问题，但是由公共DNS中的私有IP引起的问题却不是那么多。我只是看不到问题。
–womble♦
09年5月5日，下午2:36
@womble，如果计算机由于某种原因试图连接到网络外部的主机，并且他们没有获得SMTP服务器，而是期望它们在当前连接的LAN上的IP地址上拥有任何东西，则计算机可能会感到困惑。甚至可能是您的一个在远程计算机上使用笔记本电脑的员工可能开始以纯文本格式在其他人的网络上吐出用户名和密码，只是因为他们碰巧也有192.168.1.1
– Zoredache
09年5月5日，下午2:53
我对您的答案的问题是，您暗示了问题，但未提供任何详细信息。如果有理由不这样做，我想了解一下，以便就此问题做出充分的理性决定。
–womble♦
09年5月5日，下午2:53
@Zoredache：为什么有人解析一个他们无权访问的名字？无论如何，DNS并不是唯一可以获取私有地址的地方-例如HTML可以使用IP文字...
–womble♦
09年5月5日在2:56
#4 楼
不，不要将您的私有IP地址放在公共DNS中。首先，它泄漏信息，尽管这是一个相对较小的问题。
如果您的MX出现的问题更严重。记录指向该特定主机条目是，任何尝试向其发送邮件的人最多都将获得邮件传递超时。
根据发件人的邮件软件，它们可能会退回。
更糟的是，如果您使用的是RFC1918地址空间（您应该在网络内部），而发件人也是如此，那么他们很有可能会尝试将邮件传递到自己的网络中。
例如：
网络具有内部邮件服务器，但是没有拆分的DNS
$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的错，它只是在执行所告知的操作。
评论
如何将邮件传递到错误的机器是DNS问题？您应该验证SMTP服务器。这是SMTP配置问题，与DNS完全无关。您甚至没有在这里将苹果与橙子进行比较，而是将放射性黄油吐司与一根棍子上五毫克的拉格朗日衍生物进行了比较。如果您担心获得错误的MX或A，则应该使用DNSSEC而不是让DNS对其不负责的内容负责，并且如果您错误地将SMTP传递到错误的RFC1918号，则说明网络配置错误或设计错误。
– MihaiLimbăşan
09年5月5日在16:27
（为澄清起见，予以转发）
– MihaiLimbăşan
09年5月5日在16:28
如果您网络上的某人“编造”了一个IP号码，则该IP协议的功能完全符合设计要求，即不考虑安全性。您要问的是“我怎么能相信我实际上正在与应与之交谈的人交谈？” IP和/或DNS无法提供的答案，DNSSEC和/或SSL / TLS和/或应用程序层机制可以提供答案。
– MihaiLimbăşan
09年5月5日在16:30
只需阅读您对Dave帖子的评论-您的帖子现在变得更有意义了：)我仍然不同意前提，但我认为这不再是非理性的了...
– MihaiLimbăşan
09年5月5日在16:35
不，这根本不是关于身份验证，而是关于连接在错误的位置结束。当Verisign在2001年左右决定通配* .com时，我看到了很多。
– Alnitak
09年5月5日在16:46
#5 楼
尽管可能性很小，但我认为您可能已准备好进行MITM攻击。我担心的是这一点。假设您有一个配置了指向该邮件服务器的邮件客户端的用户，将他们的笔记本电脑带到其他网络。如果其他网络也恰好使用相同的RFC1918，将会发生什么情况。该笔记本电脑可能会尝试登录到smtp服务器，并将用户的凭据提供给不应该包含它的服务器。尤其是因为您说的是SMTP，而没有提到您需要SSL。
评论
如果用户在您的办公室以及其他地方拥有一台笔记本电脑，则他们很可能已经将自己的主机文件配置为指向MTA的内部IP，或者直接在其MUA配置中使用了该IP。最终结果相同。带来IPv6和RFC1918的废止，这是确保...的唯一方法。
–womble♦
09年5月5日3:00
优秀的点Zoredache。这是一个有趣的攻击媒介。根据MUA的不同，它可能会显示通常的“令人讨厌的事情，请单击我以执行您要我做的事情”对话框，否则，如果ssl证书不匹配，它可能会完全失败。
–戴夫·切尼
09年5月5日在16:33
如果有效网络中的所有服务器（即Web / HTTPS，IMAP和SMTP）都需要基于SSL / TLS的客户端连接，是否可以有效消除这种攻击情形？
–约翰尼·犹他州
19-09-23在10:53
@JohnnyUtahh，那么您需要所有服务器都支持具有有效证书的TLS，并且需要配置所有客户端以验证证书，并且永远不要尝试使用非TLS连接。现在是10年前的更常见的默认值。但是仍然有旧的/愚蠢的软件可以尝试非tls连接。
– Zoredache
19-09-23在21:48
是的，一切都有道理，谢谢@Zoredache。
–约翰尼·犹他州
19-09-23在23:42
#6 楼
您的两个选项是/ etc / hosts，并在您的公共区域中放置一个私有IP地址。我建议前者。如果这表示大量主机，则应考虑在内部运行自己的解析器，这并不难。评论
那当然是一种选择，但是为什么呢？运行内部解析器或使用诸如BIND视图之类的工具（更聪明），除了管理开销和维护负担之外还能获得什么？那是我不明白的。
– MihaiLimbăşan
09年5月5日在16:10
运行自己的名称服务器不是科学。如果您的网络足够大，以至于您考虑将/ etc / hosts用作hack或非常耗时，则需要在网络中设置一对解析器。作为一项附带好处，您可以减少离开网络的DNS流量，并可以加快常见查询的解决速度。
–戴夫·切尼
09年5月5日在16:17
我知道这不是火箭科学，但这是维护费用和潜在的安全风险。当然，与泄漏RFC1918网络的存在相比，更高的安全风险。 DNS流量完全可以忽略不计-我在工作中的DNS上托管了80多个中等大小和繁忙的区域文件，每周DNS流量不到Youtube的2分钟。加快查询分辨率实际上是DNS中针对RFC1918数字的第一个中肯理智的论据，我在这里已经看到:)赞成实际思考超出常规的直觉“哦，是的，这是安全隐患”反应:)
– MihaiLimbăşan
09年5月5日在16:23
@Alnitak：我知道您来自哪里，但这仍然不是DNS问题，并且我认为尝试解决通过DNS源自其他地方的问题根本不是一个好主意。问题应该从源头解决，而不是被DNS黑客修补-黑客使网络脆弱。
– MihaiLimbăşan
09年5月5日在16:34
好吧，是的，我同意。并且将您的私有主机的信息放置在公共DNS中是解决没有内部DNS服务器的问题的解决方案... :)问题是高层不知道此信息应该是“私有”的。
– Alnitak
09年5月5日在16:44
#7 楼
可能会有一些细微的问题。一种是针对DNS重新绑定攻击的常见解决方案会过滤从公共DNS服务器解析的本地DNS条目。因此，您要么开放自己以重新绑定攻击，要么本地地址不起作用，或者需要更复杂的配置（如果您的软件/路由器甚至允许的话）。评论
+1 DNS重新绑定是错误的！ medium.com/@brannondorsey/…
– Ohad Schneider
18年6月22日在20:36
#8 楼
最好将其保留在hosts文件中。如果只想连接一台计算机，将其放入公共DNS会获得什么？评论
在云中工作，您可能拥有数千个私有计算机。几年前，Netflix表示他们拥有2,000多个Cassandra节点。使用/ etc / hosts文件不切实际，因为所有2,000台计算机都需要管理这些IP /名称对...
– Alexis Wilke
19 Mar 15 '19在23:36
#9 楼
如果私下里是10.0.0.0/8、192.168.0.0/16或172.16.0.0/12，那不是。大多数Internet路由器都知道它的含义-绝不能以直接方式将私有地址路由到公共Internet，这正是NAT普及的原因。任何尝试联系您的公共DNS服务器的人都将从DNS检索私有IP地址，只是将数据包发送到....无处。当他们的连接尝试将Internet遍历到您的专用地址时，沿途的某些（配置合理）路由器将简单地将包活着吞掉。如果您想从“外部”获取电子邮件在某些时候，“内部”数据包必须穿过防火墙。我建议设置一个DMZ地址来处理此问题-一个单一的公共IP地址，该地址由您安装的任何路由器/防火墙严格控制。您描述的现有设置听起来确实可以做到。
编辑：意图的澄清...（请参阅下面的评论）。如果这没有意义，我将投票删除我自己的帖子。
评论
很好，但您尚未给出为什么不应该在DNS中发布RFC1918地址的实际原因。您刚刚描述了RFC1918地址是什么，并且可能没有到其中某些地址的路由。与其他IP地址有什么不同？可能没有通往198.41.0.4的路由-这是否意味着在DNS中发布198.41.0.4是错误的？ DNS是一个名称解析系统。它与路由无关，两者是正交的。您正在合计两类问题，这些问题基本上等于FUD。
– MihaiLimbăşan
09年5月5日在16:16
讨论的上下文是在公共DNS服务器中使用私有IP地址。该帖子的目的是表明，默认情况下，路由器不路由私有IP地址。我并不是试图表明您不能在DNS服务器中使用私有IP地址，只是您不应该将这些IP地址“提供给外部”。如果还不够清楚，我将很乐意撤回该职位。否则，我不同意，该职位是100％即时提供的-此人的最终结果是/他们将遇到问题/如果他们这样做。
–艾琳·佩恩（Avery Payne）
09年5月5日在16:43
点头在Alnitak的帖子下，您的评论已被清除：)谢谢。
– MihaiLimbăşan
09年5月5日17:19
“任何试图与您的公共DNS服务器联系的人都会从DNS检索私有IP地址，只是将数据包发送到...。无处”-不，您实际上已经描述了DNS重新绑定，并且它可以在某些最安全的路由器上运行在那里，包括我的PepWave Surf SOHO：rebind.network/rebind
– Ohad Schneider
18年6月22日在20:45
#10 楼
我到达这里的时候我正在寻找类似的信息，但令我惊讶的是，很多人说泄漏您的私有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 ...
现在您应该已经准备就绪。
评论
+1，出于原因请参阅对womble答案的评论：）
– MihaiLimbăşan
09年5月5日在16:20
这是有关此问题的一个很好的例子：merit.edu/mail.archives/nanog/2006-09/msg00364.html
–sucuri
09年8月4日在19:12
如果您的敏感服务器具有公共IP地址，但是在防火墙后面限制访问，则此建议是否仍然适用？如果公用IP地址的公用DNS给出了基础架构的路线图，那么攻击者难道不是有什么用吗？主机识别？
–肯尼
2011-11-28 12:51
@Kenny是的，从理论上讲，确实有一定用处，但这并不是很难获得的信息，因为公共IP地址的范围很容易被发现。我会在回答中解决这个问题，并补充一点我会认为，如果您依赖隐藏IP地址或主机名作为任何实质性的防线，那么您已经遇到了更大的问题。
–高杰夫
2011-11-28 14:12
@Kenny就您而言，当然希望将公开可发现的信息量减到最少，并且您不想透露不需要或至少没有某种良好的成本/收益交易的信息-脱掉考虑。那里没有争论。除此之外，我要说的核心（我认为我们同意）仅是，混淆是一种较差的安全形式，没有绝对的好/坏，只有成本/收益的连续取舍可以进行。根据您的风险承受能力等情况，逐案考虑
–高杰夫
2011年11月28日在18:17