我已经在其他 DNS 提供商那里完成了此操作，但我在 UltraDNS 的 DNS 管理界面上卡住了。我需要在一个TXT条目中输入多个值，以便它们解析为单个字符串，每个值都用“”标记并用空格分隔。
我们希望 TXT 记录返回的示例如下（使用 Linux 的 dig 进行测试）：
;; 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 字符集的代码）。
无效输入：评论仅支持 ASCII 字符
例如输入如下内容：
\txtvers=1\"<sp>\"proto=https\"<sp>\"path=/acs/resources/configurations\
该软件也使用SRV和PTR记录并且这些工作 - 由于这个格式问题，它无法从值中获取TXT应有的路径。
答案1
这里需要注意的是，一条TXT记录可以有多个值，记录数据包含一个或多个字符串，每个字符串最多可包含 255 个字符。
也就是说，一条TXT具有多个值的记录和多条TXT各有一个值的记录不是一回事，不应期望它们被解释为相同的。
你最初展示的实际上并不是一个TXT记录单个字符串，每个值都用 " 标记标记并用空格分隔而是一个TXT包含三个独立字符串值的记录，这些字符串值不包含任何引号或空格。
这种理解尤其重要，因为您在尝试解决问题时尝试做的一件事就是转义这些用于格式化但实际上不是值一部分的字符。
对于任何理解并使用 DNS 的软件主文件格式（DNS 记录的标准文本表示），您最初包含的内容... TXT "txtvers=1" "proto=https" "path=/acs/resources/configurations"将被理解和解释为TXT具有三个独立字符串值（txtvers=1、proto=https、path=/acs/resources/configurations）的一条记录。
如果您的服务提供商的界面不接受这种输入形式，并且他们不提供其他输入多个值的方法（您从他们那里收到的答案表明情况很可能如此），则可能无法将所需的记录输入到他们的系统中。
如果确实如此，您可能必须考虑在其他地方托管此记录（包括不移动整个区域，而是将所需的TXT记录托管在其他地方的其他区域中，并仅添加CNAME指向那里的选项，前提是相关软件不会以某种方式反对这一点）。
也就是说，在TXT作为其他标准一部分的专门用途中，更常见的是（具有广泛的例子，如 SPF 和 DKIM）在记录中使用多个字符串值TXT纯粹是为了允许长值，并定义所有字符串值应该在进一步解释之前简单地连接起来，而不是使用一些内部分隔符（通常是;）来表示单个、可能很长的字符串内的多值内容。
您的服务提供商很可能已经专门研究了非常常见的“长值”场景，并以某种方式支持该场景（尤其可能是因为 DKIM）。
无论哪种方式，如果使用这些记录的软件的设计完全由您决定，那么更好的办法可能是简单地遵守这方面的规范，并使用与这些广泛专业化中使用的相同方法来存储多值内容TXT。（但是，如果此系统已在使用中，这种更改显然会影响与现有记录的兼容性）。
答案2
解决方法：按照以下方法添加 TXT 记录
parmset=txtvers=1,proto=https,path=/acs/resources/configurations
希望这有帮助