whatever.lan。我也有一个VMware环境，并且在仅虚拟机的网络上，我将虚拟机命名为whatever.vm。当前，用于虚拟机的网络无法从我们的局域网访问，但是我们正在建立一个生产网络，以将这些虚拟机迁移到该网络，这可以通过LAN进行访问。结果，我们试图为我们要建立的这个新网络上的访客应用一个域名后缀/ TLD的约定，但是鉴于
.vm，我们无法提出一个好的约定.local和.lan在我们的环境中都具有现有的含义。，在这种情况下的最佳实践是什么？在纯内部网络上可以安全使用的顶级域名（TLD）或域名列表吗？
#1 楼
不要使用发明的TLD。如果ICANN要委派它，那么您将遇到很大的麻烦。如果您与碰巧使用相同虚拟TLD的另一个组织合并，则也是一样。这就是为什么首选全球唯一域名的原因。该标准RFC 2606保留了示例，文档，测试的名称，但不保留任何通用名称，这是有充分理由的：今天，它是如此容易且便宜要获得真实唯一的域名，没有充分的理由使用虚拟域名。
因此，请购买
iamthebest.org并使用它来命名设备。评论
为了完全安全，我会将所有内容都放到公司域名的子域中，例如local.company.org，vm.company.org等。
–drybjed
09年2月2日在8:14
+1。大概您的公司已经有一个域。只需由此创建一个子域。它不必在您的LAN外部可见/可解析。
–丹·卡利
09年6月2日在11:53
好吧，即使聘请了非常好的律师，您也将很难通过调用商标来声明“ .lan”或“ .local”。而且，“仅内部的”这一论点非常弱：组织合并，与合作伙伴组织建立虚拟专用网络，并且仅仅犯一些错误，以至于“私有”名称泄漏。
– Bortzmeyer
09年6月2日在19:34
我唯一能解决的问题是您不能真正“购买”域名：您只能租用一个。有些笨蛋忘记支付账单（这在一些引人注目的案例中就已经发生了），而您配置的核心部分归某个随机random屋者所有。那么您使用公司的域名吗？执行人员决定重塑品牌或被收购，而您却被保留了旧名字。 .local曾经可以很好地工作，但是现在已经被某些公司以拒绝玩得很好的方式抢占了先机。我真的很想看到类似.lan或.internal这样的正式用途，但是在那之前，这是最好的选择。
–乔尔·科尔（Joel Coel）
13年4月25日在20:36
同意@Joel Coel，您就是租房者，仅此而已。应该保留两个仅供内部使用的TLD名称，这些名称在公共场合应被视为无效并且公共网络无法访问。一个名称将用于家庭内部使用，第二个名称将用于内部业务使用。就像我们拥有不可路由的“专用子网”（192.168.x.x和ilk）一样，这两种方式都将被视为“专用TLD”。这使家庭用户除了被迫进入.local和mDNS之外还可以做其他事情。同上，适用于在没有域的NAT后运行内部LAN的小型企业。
–艾琳·佩恩（Avery Payne）
2014年12月12日18:20
#2 楼
将公司注册域的子域用于您不想在Internet上使用其名称的内部计算机。 （然后，当然，仅将这些名称托管在您的内部DNS服务器上。）以下是虚拟示例公司的一些示例。面向Internet的服务器：
www.example.com
mail.example.com
dns1.example.com
内部机器：
dc1.corp.example.com
dns1.corp.example.com
client1.corp.example.com
我使用“ corp”表示该子域描述了内部公司网络上的计算机，但是您可以在此处使用任何您想要的东西，例如“内部“：client1.internal.example.com。
也请记住，DNS区域和子域不必与您的网络编号方案保持一致。例如，我的公司有37个位置，每个位置都有自己的子网，但是所有位置都使用相同的（内部）域名。相反，您可能只有一个或几个子网，但是有许多对等内部域或子域级别可以帮助您组织计算机。
#3 楼
自从编写了该问题的先前答案以来，已经有一些RFC在某种程度上改变了指南。 RFC 6761讨论了特殊用途的域名，但未提供针对专用网络的特定指南。 RFC 6762仍然建议不要使用未注册的TLD，但也承认在某些情况下仍会这样做。由于常用的.local与多播DNS（RFC的主要主题）冲突，因此附录G。私有DNS命名空间建议使用以下TLD：intranet
内部
private
corp
home
lan
IANA似乎可以识别这两个RFC，但是（当前）不包含附录G中列出的名称。
换句话说：您不应该这样做。但是，无论如何，只要决定使用上述名称之一即可。
评论
附录G在您引用的列表之前：“我们完全不建议您使用未注册的顶级域”。这是更关键的一点。给出的名称不建议“使用”，它们只是观察到的名称，其效果比.local更好，后者是为MulticastDNS保留的，有关附录G中的讨论。
–帕特里克·梅夫克（Patrick Mevzek）
18/12/20在17:51
我不同意。关键是该建议的荒谬性：“不要这样做……但是，当您这样做时……”关于家庭/小型企业/非公开网络应该注册TLD的期望是不现实的。到目前为止，人们将使用未注册的TLD更好地帮助所有人，并说“好，这是您可以在内部使用的未注册TLD的列表”，而不是假装每个人都将遵循强硬的建议。
– blihp
18/12/21在2:54
那时我们将保持分歧。有些人使用TLD是内部使用（例如，在许多文档中找到的.MAIL），这一事实正是这些TLD无法委派并且现在无限期死亡的原因。因此，继续向人们推荐以这种方式使用TLD会对全球Internet社区造成损害。该建议说，由于某些顶级域名已经像那样被滥用，因此如果人们不得不滥用，则应该重用那些顶级域名，而不是滥用新的顶级域名。 RFC2606明确规定TLD在内部可以使用：.EXAMPLE .TEST .INVALID
–帕特里克·梅夫克（Patrick Mevzek）
18/12/21在14:03
home.arpa。 RFC8375中的内容现在在IANA上保留。
–卡洛斯·贝普勒（Carlos Beppler）
20-2-20在14:31
#4 楼
使用内部子域的另一个优点是：巧妙地使用搜索后缀和仅主机名而不是FQDN，您可以构建在开发，质量检查和生产中均可使用的配置文件。例如，您始终在配置文件中使用“ database = dbserv1”。
在开发服务器上，将搜索后缀设置为“ dev.example.com”
=>使用的数据库服务器：dbserv1.dev.example.com
在质量检查服务器上，将搜索后缀设置为“ qa.example.com”
=>数据库使用的服务器：dbserv1.qa.example.com
在生产服务器上，将搜索后缀设置为“ example.com”。
=>使用的数据库服务器：dbserv1.example.com
这样，您可以在每个环境中使用相同的设置。
评论
那太好了。
–克里斯·马格努森（Chris Magnuson）
2012年3月14日14:35
直到有人用生产搜索后缀对工作站进行错误配置以测试问题，然后又无意中更新了一系列生产记录。
–乔尔·科尔（Joel Coel）
13年4月25日在20:43
这非常粗糙，SRV记录非常易于解析，并且可以放置在任何区域中，因此同一数据库服务器可以服务多个区域。在这种情况下，一些代码将填充您的配置文件中的值。您可以使用数据库名称作为SRV密钥，当然也可以使用指向主机名的值。我永远不会依靠搜索后缀。如果它们是秘密的话，您还可以使TXT记录变得很有创意，并可以将它们填充为aes-256加密（然后以base64编码）的值。您可以将TXT记录用于各种事情。
– figtrap
15-10-12在1:12
看到了，但是我想要的是example.com，example.dev和example.stg。后2个仅在专用网络上，我可以为零配置访问设置本地DNS服务器吗？对于所有站点，仍在此处使用类似的配置，只是将更改移至tld。易于使用主机文件对.dev进行配置，但配置为零...
– DigitalDesignDj
16年1月2日，18：21
格式化/填充配置文件不应成为提升代码的瓶颈
–雷神召唤师
20 Mar 27 '20 3:53
#5 楼
如前所述，您不应将未注册的TLD用于您的专用网络。尤其是现在ICANN允许几乎任何人都可以注册新TLD。然后应该使用真实域名。
另一方面，RFC 1918很清楚：
企业中应包含对此类地址的间接引用。
此类引用的突出示例是DNS资源记录和其他引用内部私有地址的信息。
因此，您的名称服务器还应该使用视图来防止私人记录在Internet上传输。
评论
由于价格昂贵，除大型组织外，任何人通常都无法注册自己的TLD。绝对不适合家庭用户。
–葛兰·乌德堡
20年1月14日在8:58
@GöranUddeborg：您误解了答案。答案不建议您注册自己的TLD，只是警告可能会创建新的TLD，这可能与您选择的TLD冲突。建议是仅注册您自己的域名（很便宜）。
–sleske
20-4-2在12:22
#6 楼
我们倾向于认为主机的虚拟命名与物理名称没有什么不同-实际上，我们已经从物理层抽象了主机配置（软件）。因此，我们购买了硬件，并在它们之上创建主机项（并使用简单的关系在我们的文档中进行说明）。
目的是当主机存在时，DNS不应成为决定因素-正如我们机器已经从一个空间转移到另一个空间-例如，性能低下的Webapp无需消耗昂贵的CPU周期-将其虚拟化，并保留其命名方案，一切都会继续进行。
#7 楼
一如既往，存在着法律上和事实上的标准。ICANN在“非营利组织”的政治和金钱中扮演着我们普通百姓遭受的苦难。 IETF曾经为个人家庭Intranet引入了
.home（RFC 7788），但由于IETF仅控制.home.arpa，因此IETF仅能控制以个人为目的的IANA播放器，并且无法根据.arpa（RFC 8375）重新引入域。https附录G ：//tools.ietf.org/html/rfc6762提到：
.intranet .internal .private .corp .home .lan
如果您真的想要内部TLD，则可以使用。
大型企业（谷歌，亚马逊）将
.internal用于虚拟Intranet：https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html-专用（内部）DNS主机名解析为该主机的专用IPv4地址实例。
私有DNS主机名的形式对于
ip-private-ipv4-address.ec2.internal 区域来说是
us-east-1，对于其他区域来说是ip-private-ipv4-address.region.compute.internal形式（其中private-ipv4-address是反向查找IP地址）。
https://cloud.google.com/compute/docs/internal-dns
所有在2018年9月6日之后启用Compute Engine API的组织或独立项目的区域DNS
[INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal。 那些公司可以购买互联网。因此，在内部使用
.internal TLD实际上是安全的））#8 楼
我不确定这是否对您有帮助，但是对于我的AWS帐户中的内部DNS，我将.aws用作tld，它似乎运行得很好。我知道您应该使用一些TLD只是完全不使用，但除此之外，我认为它不是太严格。
我在一些较大的公司工作过，他们会使用身份验证源作为TLD，也就是说如果使用是一台MS / Windows服务器，使用Active Directory作为身份验证源，它将是
.ad，另外一些将是.ldap（为什么它们不只是使用相同的源？还是从同一目录服务复制的服务器？我不这样做）不知道，就像我到那儿一样）祝你好运
评论
亚马逊现在已经将.aws注册为TLD，因此您最终可能会开始发现问题：nic.aws
– Mark McKinstry
16年4月7日在1:09
有关信息，.aws已于最近“ 2016年3月25日”注册=> newgtlds.icann.org/en/program-status/delegated-strings
–布鲁诺·阿德莱（BrunoAdelé）
16年5月9日9:00
尽管我认为使用假冒的顶级域名（TLD）没什么大不了的，但是至少在整个系统都关闭并且使用代理与整个Internet进行通信的情况下，至少不是这样，但是“ .aws”是一个非常糟糕的选择，除非您不在AWS中！有太多可能的情况，您将无法再与AWS通信。
– figtrap
16-10-28在19:55
评论
不要使用.local。特别是如果您有任何Apple客户。出于以下原因而搁置了.test：secure.wikimedia.org/wikipedia/en/wiki/.test
@CWSpear这不是保留.test的实际原因，尽管它确实使它成为不连接到Internet的测试网络的安全域。
@Otto最佳做法将指示您获得一个“真实”域名（在ICANN认可的TLD下），并为您的本地内容创建一个子域（例如，注册mydomain.com，将internal.mydomain.com委派给内部NS ，并正确配置水平分割DNS（BIND中的“视图”），这样您就不会将内部名称/地址泄漏到互联网上，虽然不像TLD /伪TLD那样漂亮，但不像在您的域名下那样容易损坏控制。
但是：不要使用已经用于面向公众的生产服务的真实域名。在www.example.com和* .internal.example.com之间允许进行多种交互，而在www.example.com和* .example.net之间不允许进行多种交互，其中最值得注意的是跨站点Cookie设置。在同一域上运行内部和外部服务会增加以下风险：危害公共服务会损害内部服务，反之，不安全的内部服务可能会导致内部滥用外部服务。