我已經與其他 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由於此格式問題，它無法從該值中獲取我們應有的路徑。
答案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
希望有幫助