专用网络的顶级域/域后缀?

Ott*_*tto 147 domain-name-system local-area-network hostname best-practices

在我们的办公室,我们有一个带有纯内部 DNS 设置的局域网,所有客户端都命名为whatever.lan. 我还有一个 VMware 环境,在纯虚拟机网络上,我将虚拟机命名为whatever.vm.

目前,该网络为虚拟机是不是从我们的局域网访问,但我们正在建立一个生产网络将这些虚拟机迁移到,这是从局域网访问。因此,我们正在尝试为我们正在设置的这个新网络上的来宾应用的域后缀/TLD 制定一个约定,但鉴于此.vm,我们无法提出一个好的约定,.local并且.lan所有这些都在我们的环境中具有现有的内涵。

那么,在这种情况下,最佳做法是什么?是否有可安全用于纯内部网络的 TLD 或域名列表?

bor*_*yer 111

不要使用发明的 TLD。如果 ICANN 将其委托给它,你就会遇到大麻烦。如果您与碰巧使用相同虚拟 TLD 的另一个组织合并,则情况相同。这就是为什么首选全球唯一的域名。

标准RFC 2606为示例、文档、测试保留名称,但没有用于一般用途,并且有充分的理由:今天,获得真实且唯一的域名是如此容易和便宜,以至于没有充分的理由使用假一个。

因此,购买iamthebest.org并使用它来命名您的设备。

  • 为了完全安全,我会将所有内容放在公司域名的子域中,例如 local.company.org、vm.company.org 等。 (61认同)
  • 我唯一的反对是你不能真正“购买”一个域名:你只能租一个。一些笨蛋忘记支付账单(这在一些备受瞩目的案例中发生过),并且您配置的核心部分用于一些随机的擅自占地者。所以你用的是你公司的域名?高管们决定重塑品牌或被收购,而你却被一个旧名字所困扰。.local 过去工作得很好,但现在被某家公司以拒绝玩得开心的方式抢占了。我真的很想看到像 .lan 或 .internal 之类的东西正式保留用于此目的,但在那之前这是最好的选择。 (17认同)
  • 同意@Joel Coel,您是租房者,仅此而已。应该有两个保留的 TLD 名称*仅供内部使用*,应被视为公共无效且公共网络无法访问。一个名称供内部家庭使用,第二个名称供内部业务使用。两者都将被视为“私有 TLD”,就像我们拥有不可路由的“私有子网”(192.168.xx 等)一样。这允许家庭用户除了被迫进入 .local 和 mDNS 之外还可以做一些事情。同样适用于在没有域的 NAT 后面运行内部 LAN 的小型企业。 (13认同)
  • +1 这个。大概你的公司已经有一个域。只需从此创建一个子域即可。它不必在您的 LAN 之外可见/可解析。 (4认同)
  • [RFC8375](https://tools.ietf.org/html/rfc8375) 中的 `home.arpa.` 现已在 [IANA](https://www.iana.org/assignments/special-use-domain) 上保留-名称/特殊用途域名.xhtml)。因此您可以在您的专用网络上使用它(或其子域)。 (4认同)
  • 好吧,即使有非常优秀的律师,您也很难通过调用商标来声明“.lan”或“.local”。并且“仅限内部”的论点非常薄弱:组织合并,与合作伙伴组织建立虚拟专用网络,并且简单地犯下诸如“私有”名称泄露的错误。 (3认同)
  • 域名的使用仅限于那些有资金维护注册域名的人,这是一个荒谬的想法。虽然大多数注册商都没有那么贵,但越来越难以不以“my-new-project-idea.com”结尾,它非常好打。坦白说,抢域名的程度和有限的价值超出了最初的公众淘金热,比ipv4的情况差很多 (3认同)
  • 来自 The Register - [您在网络上使用 .home 和 .mail 吗?ICANN 正在考虑 .corp、.mail、.home 点词域](https://www.theregister.co.uk/2017/03/13/icann_gtlds_corp_home_mail/) *爱好金钱的 DNS 监管者思考的“高风险”gTLD * (2认同)
  • 我的印度尼西亚朋友刚刚报告说 test.lan 是由她的 ISP 解析的:)) (2认同)

Jay*_*aud 61

将您公司注册域的子域用于您不希望其名称在 Internet 上可用的内部计算机。(当然,只在您的内部 DNS 服务器上托管这些名称。)以下是虚构的 Example Corporation 的一些示例。

面向 Internet 的服务器:
www.example.com
mail.example.com
dns1.example.com

内部机器:
dc1.corp.example.com
dns1.corp.example.com
client1.corp.example.com

我使用“corp”表示该子域描述了内部公司网络上的机器,但您可以在此处使用任何您想要的名称,例如“internal”:client1.internal.example.com。

还要记住,DNS 区域和子域不必与您的网络编号方案保持一致。例如,我的公司有 37 个地点,每个地点都有自己的子网,但所有地点都使用相同的(内部)域名。相反,您可以只有一个或几个子网,但可以有许多对等的内部域或子域级别来帮助您组织计算机。


bli*_*ihp 59

自从写了这个问题的先前答案以来,已经有几个 RFC 稍微改变了指南。 RFC 6761讨论了特殊用途的域名,但没有为专用网络提供具体的指导。 RFC 6762仍然建议不要使用未注册的 TLD,但也承认在某些情况下无论如何都会这样做。由于常用的.local与 Multicast DNS(RFC 的主要主题)冲突,附录 G. Private DNS Namespaces推荐以下 TLD:

  • 内联网
  • 内部的
  • 私人的
  • 公司

IANA 似乎认可这两个 RFC,但(目前)不包含附录 G 中列出的名称。

换句话说:你不应该这样做。但是,当您决定无论如何都要这样做时,请使用上述名称之一。

  • 我不同意。关键是建议的荒谬之处:“不要这样做......但是当你这样做时......” 家庭/小型企业/非公开网络应该注册顶级域名的期望是不现实的。人们 ** 正在** 使用未注册的 TLD 到目前为止更好地帮助每个人并说“好的,这是您可以在内部使用的未注册的 TLD 列表”,而不是假装每个人都会遵循强硬的建议。 (12认同)
  • 附录 G 在您引用的列表之前有:“我们根本不建议使用未注册的顶级域名”。这才是更关键的一点。给出的名称并不是“推荐”使用的,它们只是观察到的名称,它们比“.local”工作得更好,“.local”是为 MulticastDNS 保留的,这是附录 G 中的讨论。 (6认同)
  • 那时我们仍会存在分歧。事实上,有些人像内部一样使用 TLD(例如,在许多文档中找到的“.MAIL”)正是这些 TLD 无法委托且现已无限期失效的原因。因此,继续建议人们以这种方式使用 TLD 是对全球互联网社区的损害。该建议称,由于某些顶级域名已经被这样滥用,如果人们不得不滥用,他们应该重复使用这些顶级域名,而不是滥用新的顶级域名。RFC2606 明确规定 TLD 可以在内部使用:`.EXAMPLE` `.TEST` `.INVALID` (2认同)
  • 来自 [RFC8375](https://tools.ietf.org/html/rfc8375) 的 `home.arpa.` 现在保留在 [IANA](https://www.iana.org/assignments/special-use-domain -names/special-use-domain-names.xhtml)。 (2认同)

小智 34

使用内部子域还有另一个优势:巧妙地使用搜索后缀和仅主机名而不是 FQDN,您可以构建在开发、QA 和生产中都可以使用的配置文件。

例如,您总是在配置文件中使用“database = dbserv1”。

在开发服务器上,将搜索后缀设置为“dev.example.com”=> 使用的数据库服务器:dbserv1.dev.example.com

在 QA 服务器上,将搜索后缀设置为“qa.example.com”=> 使用的数据库服务器:dbserv1.qa.example.com

在生产服务器上,将搜索后缀设置为“example.com”=> 使用的数据库服务器:dbserv1.example.com

这样,您可以在每个环境中使用相同的设置。

  • 直到有人用生产搜索后缀错误配置他们的工作站来测试问题,然后无意中更新了一堆生产记录。 (30认同)
  • 请永远不要这样做。这是您在第一次阅读 O'Reilly 的“BIND & DNS”一书后意识到自己“可以”做的“聪明”事情之一。但是,故障排除/追踪少数系统的**痛苦**恰好使用了一些硬编码的FQDN主机名*或*使用错误的(即prod而不是qa)手动错误配置,这样的搜索后缀将超过**所有** 获得的便利。 (4认同)
  • 那太棒了。 (2认同)
  • 这是非常粗略的,SRV 记录非常容易解析并且可以放置在任何区域中,这样同一个数据库服务器可以为多个区域提供服务。在这种情况下,一些代码将填充配置文件中的值。并且您可以使用数据库的名称作为 SRV 键和指向主机名的当然值。我从不依赖搜索后缀。您还可以对 TXT 记录发挥创意,并可以用 aes-256 加密(然后是 base64 编码)值填充它们,如果它们是秘密的话。您可以将 TXT 记录用于各种事情。 (2认同)

gav*_*koa 17

与往常一样,有法律上和事实上的标准。

虽然“非营利” ICANN 在政治和金钱方面发挥作用,但我们普通人却在受苦。IETF 曾经.home为个人家庭 Intranet引入(RFC 7788),但他们没有权力控制只为盈利的 IANA 播放器,并重新引入了.home.arpa(RFC 8375)下的域,因为 IETF 仅控制.arpa

https://tools.ietf.org/html/rfc6762 的附录 G提到:

.intranet .internal .private .corp .home .lan
Run Code Online (Sandbox Code Playgroud)

如果您真的想要内部 TLD,请使用。

大玩家(谷歌、亚马逊).internal用于虚拟内联网:

那些公司可以购买互联网。因此,在.internal内部使用TLD实际上是安全的))

  • 这是一个很好的答案,因为它涵盖了根据规范在技术上最好的内容和从实际角度来看安全的内容。 (4认同)
  • 谢谢你的这个伟大的答案。我认为“那些公司可以购买互联网。因此在内部使用 .internal TLD 实际上是安全的”是关键的见解。如果这意味着谷歌和亚马逊可以避免在自己的基础设施中遇到小问题,他们就会重构互联网。他们无所不能。 (2认同)

Ben*_*oit 13

如前所述,您不应将未注册的 TLD 用于您的专用网络。尤其是现在 ICANN 几乎允许任何人注册新的 TLD。然后您应该使用真实的域名。

另一方面,RFC 1918是明确的:

对此类地址的间接引用应包含在企业内。此类引用的突出示例是 DNS 资源记录和其他引用内部私有地址的信息。

所以你的名字服务器也应该使用视图来防止私人记录在互联网上传输。

  • @GöranUddeborg:你误解了答案。答案不建议您注册自己的 TLD,它只是警告_可能会创建_可能与您选择的 TLD 冲突的新 TLD。建议是只注册您自己的域名(这很便宜)。 (2认同)
  • .internal 和 .local 实际上都被公司锁定以供内部使用。 (2认同)

Mik*_*ler 11

我们倾向于认为主机的虚拟命名与物理层没有区别——事实上,我们已经从物理层抽象出主机配置(软件)。

所以我们购买硬件项目,并在它们之上创建主机项目(并使用简单的关系在我们的文档中显示)。

目的是当主机存在时,DNS 不应该是决定性因素——因为我们已经让机器从一个空间移动到另一个空间——例如一个低性能的 web 应用程序不需要消耗昂贵的 CPU 周期——虚拟化它,并且它保留其命名方案,一切继续工作。