小编And*_*w B的帖子

这是一个关于区域顶点（或根部）CNAME的规范问题

相对普遍的知识是CNAME，域顶端的记录是一种禁忌做法。

例子： example.com. IN CNAME ithurts.example.net.

在最好的情况下，名称服务器软件可能会拒绝加载配置，在最坏的情况下，它可能会接受此配置并使 example.com 的配置无效。

最近，我让一家网络托管公司将指令传递给一个业务部门，我们需要将我们域的顶点 CNAME 命名为新记录。知道这将是一个自杀配置，当提供给 BIND 时，我告诉他们我们将无法遵守，这通常是愚蠢的建议。该网络托管公司的立场是，标准定义 RFC 并没有完全禁止它，并且他们的软件支持它。如果我们不能对顶点进行 CNAME，他们的建议是根本没有顶点记录，并且他们不会提供重定向网络服务器。...什么？

我们大多数人都知道RFC1912坚持这一点A CNAME record is not allowed to coexist with any other data.，但让我们在这里对自己诚实，RFC 只是信息性的。我所知道的最接近禁止这种做法的措辞来自RFC1034：

如果节点上存在 CNAME RR，则不应存在其他数据；这可确保规范名称及其别名的数据不能不同。

不幸的是，我已经在这个行业工作了足够长的时间，我知道“不应该”与“必须不”不同，这对于大多数软件设计师来说已经足够了。知道任何缺少指向灌篮的简洁链接都会浪费我的时间，我最终让公司因为推荐的配置可能会在没有适当披露的情况下破坏常用软件的配置而受到责骂。

这让我们进入问答环节。这一次，我希望我们能够真正了解顶级 CNAME 的疯狂，而不是像我们通常在有人发布该主题时所做的那样回避这个问题。RFC1912是不受限制的，就像我没有想到的任何其他适用于此的信息 RFC 一样。让我们关闭这个婴儿。

所以，说我从一个SSH会话断开连接，我已经开始之后rsync或cp或其他任何命令，可以是长期运行。在我断开连接后，该命令会一直运行直到完成还是只是被杀死？

一直想知道这个。

是否可以在域顶部设置 CNAME 记录？（即@ CNAME www，@ CNAME foobar.com.等）

我的 ISP 说只能将 CNAME 用于子域，但我在其他地方读过，即使不推荐也应该可以。

引用 RFC 来支持意见（包括 Serverfault Q&A）是非常常见的，但是普通 IT 员工对于哪些 RFC 定义标准以及哪些纯粹是提供信息的理解很差。这应该不足为奇：所有经验水平的系统管理员通常都会避免对 RFC 睁一只眼闭一只眼，除非他们别无选择。

在像我们这样的网站上，非常重要的是我们不要在我们赞成的答案中延续常见的误解。来自搜索引擎的随机用户将假设没有争议评论的赞成票是审查的充分指标。最近，我偶然发现了 2011 年的一个答案，这表明这在某些情况下绝对不会在我们投票时被抓住，并且可能需要做出一些努力来通知我们的社区和整个互联网。

因此，事不宜迟，如何区分可作为互联网标准引用的 RFC 和纯粹提供信息的 RFC？

在最近的一次审计中，我们被要求在运行 linux (bind9) 的 DNS 服务器上安装防病毒软件。服务器在渗透测试期间没有受到损害，但这是给出的建议之一。

1. 通常安装linux杀毒软件是为了扫描发往用户的流量，那么在dns服务器上安装杀毒软件的目的是什么？

2. 你对这个提议有什么看法？

3. 你真的在你的 linux 服务器上运行防病毒软件吗？

4. 如果是这样，您会推荐哪种防病毒软件，或者您目前正在使用哪种防病毒软件？

这是一个关于 DNS 地理冗余的规范问题。

众所周知，在提供弹性 Web 服务时，非常需要位于不同物理位置的地理冗余 DNS 服务器。文件BCP 16对此进行了深入介绍，但一些最常提到的原因包括：

• 防止数据中心灾难。地震发生。机架发生火灾并烧毁附近的服务器和网络设备。如果数据中心的物理问题同时关闭两个 DNS 服务器，即使它们不在同一行，多个 DNS 服务器也不会给您带来多大好处。

• 防止上游对等问题。如果共享的上游网络对等点小睡，多个 DNS 服务器将无法防止出现问题。无论是上游问题完全使您脱机，还是只是将所有 DNS 服务器与一小部分用户群隔离，最终结果都是即使服务本身位于完全不同的数据中心，人们也无法访问您的域。

这一切都很好，但是如果我在同一个 IP 地址上运行我的所有服务，那么冗余 DNS 服务器真的有必要吗？如果没有人可以访问我的域提供的任何内容，我看不出拥有第二个 DNS 服务器会给我带来什么好处。

我知道这被认为是最佳实践，但这似乎毫无意义！

当 DNS 缓存的准确性有问题时，dig +trace往往是确定面向 Internet 的 DNS 记录的权威答案的推荐方法。这在与 配对时似乎特别有用+additional，这也显示了胶水记录。

有时似乎在这一点上存在一些分歧——有人说它依赖本地解析器来查找中间名称服务器的 IP 地址，但命令输出没有提供任何迹象表明这超出了 root 的初始列表名称服务器。如果目的+trace是从根服务器开始并跟踪您的方式，那么假设情况并非如此，这似乎是合乎逻辑的。（至少如果您有正确的根名称服务器列表）

是否dig +trace真的将本地解析器用于根名称服务器之外的任何内容？

$ORIGIN example.com. ; not necessary, using this to self-document

$TTL 3600
@        IN     SOA   ns1.example.com. admin.example.com. (
                      1970010100 7200 1800 1209600 300)

@        IN     NS   ns1.example.com.
@        IN     NS   ns2.example.com.

@        IN     A    198.51.100.1
ns1      IN     A    198.51.100.2
ns2      IN     A    198.51.100.3

sub1     IN     NS   ns1.example.edu.

sub2     IN     NS   ns1.sub2
ns1.sub2 IN     A    203.0.113.1 ; inline glue record

NS 记录在域顶点下的作用是众所周知的。它们的存在是为了将子域的权限委托给另一个名称服务器。上面的例子应包括的NS记录sub1和sub2。这些允许名称服务器为它认为自己不具有权威性的域部分分发引用。

在NS的目的，记录在一个域的顶点，ns1而ns2在这种情况下，似乎较少地受到互联网的大了解。我的理解（可能不是整体的）如下：

1. 缓存 DNS 服务器不使用它们来确定域的权威服务器。这由在注册商级别定义的名称服务器胶水处理。注册商从不使用此信息来生成胶水记录。
2. 它们不 …

这是一个关于保护公共 DNS 解析器的规范问题

开放式 DNS 服务器看起来非常简洁和方便，因为它们提供了我们可以在公司内一致使用的 IP 地址，无论它们位于何处。Google 和 OpenDNS 提供了此功能，但我不确定我是否希望这些公司能够访问我们的 DNS 查询。

我想设置这样的东西供我们公司使用，但我听到很多关于这是危险的做法（特别是在放大攻击方面），我想确保我们这样做是正确的。在构建这种类型的环境时，我需要记住哪些事情？

围绕反向 DNS 的要求令人困惑！人们经常谈论如果不存在反向 DNS，一切都会中断，这听起来很可怕。即使在应用程序不需要反向 DNS 的情况下，也经常引用 RFC 来支持强制 PTR 记录创建。

其中一些 RFC 包括：

RFC1912：常见的 DNS 操作和配置错误

每个可访问 Internet 的主机都应该有一个名称。... 确保您的 PTR 和 A 记录匹配。对于每个 IP 地址，在 in-addr.arpa 域中都应该有一个匹配的 PTR 记录。如果主机是多宿主的（多个 IP 地址），请确保所有 IP 地址都有相应的 PTR 记录（不仅仅是第一个）。没有匹配的 PTR 和 A 记录可能会导致 Internet 服务的丢失，类似于根本没有在 DNS 中注册。

RFC1033：域管理员操作指南

添加主机。

 To add a new host to your zone files:

    Edit the appropriate zone file for the domain the host is in.

    Add an entry for each address of …

Run Code Online (Sandbox Code Playgroud)