Dev*_*ugh 6 domain-name-system dns-hosting ptr-record srv-record txt-record
我已经与其他 DNS 提供商完成了此操作，但我被困在 UltraDNS 的 DNS 管理界面上。我需要在条目中输入多个值，TXT以便它们解析为单个字符串，每个值都在“标记中并用空格分隔。
我们希望 TXT 记录返回的示例如下（使用 dig for Linux 来测试这些）：
;; ANSWER SECTION:
name._avaya-ep-config._tcp.example.com. 119 IN TXT "txtvers=1" "proto=https" "path=/acs/resources/configurations"
然而，UltraDNS 支持人员表示，我们必须将它们作为单独的TXT记录输入 - 当我们这样做时，它会返回以下内容，并且正在查找该TXT值的软件无法识别它并且无法工作：
;; ANSWER SECTION:
name._avaya-ep-config._tcp.example.com. 218 IN TXT "proto=https"
name._avaya-ep-config._tcp.example.com. 218 IN TXT "txtvers=1"
name._avaya-ep-config._tcp.example.com. 218 IN TXT "path=/acs/resources/configurations"
我们尝试使用双引号，用于\按 RFC 引用，也使用按 RFC - 基于此处的 RFC： https ://www.rfc-editor.org/rfc/rfc1464
当我们尝试 RFC 示例中的一些建议时，UltraDNS 的 Web 界面不允许我们输入它，说我们必须只输入 ASCII 字符（都是如此，但它们也是其他 ASCII 字符集的代码）。
输入无效：注释仅支持 ASCII 字符
例如，输入时：
\txtvers=1\"<sp>\"proto=https\"<sp>\"path=/acs/resources/configurations\
该软件还使用SRV和记录这些工作 -只是由于此格式问题，PTR它无法从该值中获取我们应有的路径。TXT
这里要认识到的重要一点是，一条TXT记录可以是多值的，记录数据包含一个或多个字符串，每个字符串最多 255 个字符长。
即，TXT具有多个值的一条记录和TXT各具有一个值的多个记录不是一回事，并且不应期望被解释为相同。
您最初显示的实际上并不是一个TXT具有单个字符串的记录，其中每个值都在 " 标记中并以空格分隔，而是一个TXT具有三个单独的字符串值的记录，这些值不包含任何引号或空格。
这种理解尤为重要作为您在尝试解决问题时尝试做的事情之一，涉及转义这些用于格式化目的但实际上不是值的一部分的字符。
对于任何理解和使用 DNS主文件格式（DNS 记录的标准文本表示）的软件，您最初包含的内容... TXT "txtvers=1" "proto=https" "path=/acs/resources/configurations"将被理解和解释为具有三个单独字符串值 ( 、、 ) 的一条TXT记录。txtvers=1proto=httpspath=/acs/resources/configurations
如果您的服务提供商的界面不接受这种形式的输入，并且他们没有提供其他输入多个值的方法（您从他们那里收到的答案表明很可能是这种情况），则可能无法输入所需的记录进入他们的系统。
如果确实如此，您可能需要考虑在其他地方托管此记录（包括诸如不移动整个区域但将所需TXT记录放在其他地方托管的不同区域中以及仅CNAME在其中添加一个指向之类的选项，前提是有问题的软件并不以某种方式不同意这一点）。
也就是说，在TXT作为其他标准一部分的专门用途中，更常见的是（使用广泛的示例，例如 SPF 和 DKIM）将记录中多个字符串值的使用TXT纯粹定义为允许长值并定义所有在进一步解释之前，应该简单地连接字符串值，而不是;在单个可能很长的字符串内使用一些内部分隔符（通常是 ）来表示多值内容。
您的服务提供商很可能专门研究了非常常见的“长期价值”场景，并以某种方式支持该场景（尤其可能是因为 DKIM）。
无论哪种方式，如果使用这些记录的软件的设计完全取决于您，那么简单地遵守这方面的规范并使用与中使用的相同方法来存储多值内容可能是一个更好的主意。相反，这些广泛的TXT专业化。（但是，如果该系统已经在使用，这样的更改显然会影响与现有记录的兼容性）。