标签: rfc

RFC-952（假设下第 1 点的最后一句话）禁止使用单字符主机名，我曾有过（7 年前的 2002年夏天）某些服务拒绝使用单字符主机名的经验（因为这些名称是不符合标准），但我在过去几年中看到了许多使用的单字符主机名。单字符主机名现在有效吗？（如果是这样，正确的验证参考是什么？）

编辑（整合答案中的一些信息）：DNS 的各个方面似乎在几个 RFC 中都有定义，包括1035、1123和2181。来自RFC-2181 第 11 节：

Note however, that the various applications that make use of DNS data
can have restrictions imposed on what particular values are
acceptable in their environment.  For example, that any binary label
can have an MX record does not imply that any binary name can be used
as the host part of an e-mail address. …

在独立环境中使用 Ubuntu 10.04 LTS 服务器并尝试使用视图为两个不同的客户端子网提供服务。获取有关 zone.rfc1918 文件的错误，所以我想知道该文件的用途。托管 rfc1918 地址有什么意义？

我使用的子网是 rfc 1918 地址，顺便说一句。包含默认的 zone.rfc1918 文件是否会让我（更多）头痛？

我很难找到记录源端口应该是随机的并且在 1024-65535 范围内的地方。

这是在哪个 RFC 中记录的？

编辑：
特权端口的第一个参考在 RFC2623 中
似乎这更多地取决于 TCP/IP 实现，它是事实上的标准。

IANA 正在分配端口号 (RFC1700)

我时不时地对我的 DNS 服务器进行检查，以确保它们运行正常并符合 RFC 规范。我曾经使用 DNSTools 网站来执行此操作，因为它让我对正在发生的事情有一个很好的了解 - 我的所有服务器是否都响应外部世界，并且重要的（尤其是 NS、MX）记录仍在正常运行和复制。还要查看我的 MX 记录是否已成功进入任何黑名单。

黑名单一直是一种痛苦，因为我一直无法找到一个可靠的“一站式商店”，让您可以检查那里的大多数主要黑名单。

我已经有一段时间没有使用 DNS 工具了，现在他们要求你付费（我没有反对，当你投资大型内部监控解决方案时，很难向上级证明是正确的，而我只是在做一个“感觉很好检查")

我的系统管理员同事使用什么来检查他们的 DNS 记录？

我们拥有的两种不同的第三方电子邮件产品对电子邮件的 MIME 源中存在content-id标头的反应不同。这导致了我们正在尝试解决的不一致的用户体验。

下面是一个例子：

--boundary-example
Content-Location: CID:somethingatelse 
Content-ID: <foo4atfoo1atbar.net>
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64

R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNv
cHlyaWdodCAoQykgMTk5LiBVbmF1dGhvcml6ZWQgZHV
wbGljYXRpb24gcHJvaGliaXRlZC4A etc..

一种电子邮件产品将此解释为嵌入的图像。另一个将其解释为普通附件（未嵌入）。如果我们完全删除Content-ID行，两个产品都认为附件未嵌入。

是否有特定的 RFC 可以明确得出哪种行为是正确的结论？我和一位同事回顾了 RFC2392，它在开篇摘要中说：

在电子邮件中使用 [MIME] 来传送网页及其
相关图像需要一个 URL 方案，以允许 HTML 引用
消息中包含的图像或其他数据。Content-ID
统一资源定位符“cid:”用于此目的。[…]“cid”方案是指消息的特定正文部分；它的使用通常仅限于引用与引用正文部分相同的消息中的其他正文部分。“mid”方案还可以通过包含内容ID的地址来指代指定消息内的特定正文部分。

所以，虽然不是绝对的，我们倾向于认为，既然所有的嵌入式项目需要的CID引用他们，并且它是“一般仅限于相同的消息在身体其他部位，”和附件并不需要一个CID ，电子邮件产品将 cid 的存在视为“意图嵌入”的指标是合理的行为。

我可以得到确认吗？

我的域注册商和 DNS 提供当前忽略对未知域的 DNS 请求。忽略我的意思是黑洞并且从不响应，这会导致我的 DNS 客户端和解析器库重试、退出并最终超时。

dig @NS3.DNSOWL.COM somedomainthatdoesntexist.org
...
;; connection timed out; no servers could be reached

在调查其他流行的域名服务时，我发现这种行为非常独特，因为其他提供商返回的 RCODE 为 5 (REFUSED)：

dig @DNS1.NAME-SERVICES.COM somedomainthatdoesntexist.org
dig @NS-284.AWSDNS-35.COM somedomainthatdoesntexist.org
dig @NS21.DOMAINCONTROL.COM somedomainthatdoesntexist.org

全部返回如下内容：

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64732

或者

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31219

返回REFUSED或NXDOMAIN立即返回是合适的恕我直言，而不是仅仅在服务器机房地板上删除请求。

当我向我的提供商抱怨他们的服务器没有响应时，他们要求我引用他们的服务器违反的 RFC。我知道他们要求我证明他们的服务器应该响应所有请求，这很奇怪，但就这样吧。

问题：

• 我的规定是，除非有重复的请求 ID 或某种 DOS 响应，否则服务器应始终响应请求。这样对吗？
• 我应该引用哪些 RFC 和特定部分来支持我的规定？

对我来说，不响应 DNS 查询是不好的。大多数客户端将退出，然后将相同的查询重新传输到相同的 DNS 服务器或另一台服务器。它们不仅会减慢客户端的速度，还会导致它们自己或其他服务器根据权威名称服务器和 NS 条目再次执行相同的查询。

在RFC 1536和 …

在 RFC 2822（定义电子邮件）中定义，任何行都不应该超过 78 个字符（不包括 CRLF）并且不得超过 998 个字符。使用带引号的可打印更长的行将被分成更多行，每行以 '=' 结束，直到达到真正的换行符。如果邮件包含超过 78（或 998）个字符的行但使用quoted-printable 编码，是否符合标准？

有一些争论认为这不符合要求，因为接收邮件客户端在解码引用的可打印消息后有更长的行。

编辑：按照 David Cary 提出的方式澄清问题：是的，我的意思是可引用打印的编码邮件应该与引用打印兼容，这意味着行不超过 76 个字符。但是解码的消息可能有比这个限制更长的行。所以我的问题是：在解码引用的可打印文本内容后，实现 RFC 1521 的客户端软件是否应该处理无限长的行？到目前为止，这两个答案都是肯定的（谢谢），但限制是 Netiquette（RFC 1855）不鼓励这样做。但是 Netiquette 甚至将行长度限制为 65 个字符，几乎没有人遵守这个限制。

我正在构建一个由多个子设备组成的设备，这些子设备通过设备内部的以太网连接。设备将连接到客户网络。客户网络可以使用私有 IP 地址。与内部网络的地址冲突将是一个问题（连接到两个网络的子设备将被混淆）。IPv6 不是一个选项。

我应该购买 IPv4 地址吗？或者我可以不使用 TEST-NET-3 (203.0.113.0/24) 或类似的东西？最佳做法是什么？

如果域及其名称服务器不共享 TLD，胶水记录通常不可用，如果它们不共享相同的二级域，则技术上不需要，这可能导致解析域的额外步骤。解析器必须首先查找名称服务器的地址，然后才能找到您的域的地址。但从理论上讲，您可以在其中添加更多步骤，而不仅仅是这两个步骤。

这里的问题是，这条链允许有多长？

如果xyz.com使用 nameserver ns1.xyz.info，
然后xyz.info使用 nameserver ns1.xyz.co，
然后xyz.co使用 nameserver ns1.xyz.cc，
然后xyz.cc使用 nameserver ns1.xyz.co.uk，...等等

...在解析器解析您最初想要的名称之前，您可能会得到一个很长的链供解析器解开。

大概有一个实际限制——BIND 应该只愿意遍历这么多链接，否则可能会出现拒绝服务。但是有官方限制吗？官方不需要解析器继续进行的某些步骤？

在查找 SMTP 错误代码时，我有时会看到“550”或“5.5.0”。有时虚线代码中的数字不同。

我找到了RFC 821 中定义的数字代码和RFC 3463 中的虚线代码。

这只是同一事物的不同符号，还是不同？如果它们不同，协议的哪些部分负责返回每个代码，为什么不同的代码？