Я делал это с другими поставщиками DNS, но я застрял в интерфейсе управления DNS UltraDNS. Мне нужно ввести несколько значений в TXT запись, поэтому они разрешаются как одна строка с каждым значением в знаках "и разделенными пробелом".
Пример того, что мы хотим, чтобы возвращала запись TXT, выглядит следующим образом (используя dig для Linux для проверки):
;; ANSWER SECTION:
name._avaya-ep-config._tcp.example.com. 119 IN TXT "txtvers=1" "proto=https" "path=/acs/resources/configurations"
Однако в поддержке UltraDNS сказали, что мы должны вводить их как отдельные TXT записи - когда мы это делаем, он возвращает приведенное ниже и программное обеспечение, которое ищет это TXT value не распознает это и не работает:
;; 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://tools.ietf.org/html/rfc1464
Когда мы попробовали некоторые из предложений из примера RFC, веб-интерфейс UltraDNS не позволял нам вводить его, говоря, что мы должны вводить только символы 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=1, proto=https, path=/acs/resources/configurations).
Если у вашего поставщика услуг есть интерфейс, который не принимает эту форму ввода, и он не предоставляет никаких других средств ввода нескольких значений (полученный вами ответ предполагает, что это вполне может быть так), возможно, нет способа ввести желаемую запись. в их систему.
Если это действительно так, вам, возможно, придется рассмотреть возможность размещения этой записи в другом месте (включая такие варианты, как не перемещать всю зону, но иметь желаемый TXT запись в другой зоне, размещенной в другом месте, и только добавление CNAME указав туда, при условии, что рассматриваемое программное обеспечение каким-то образом не противоречит этому).
Тем не менее, при специализированном использовании TXT как часть других стандартов, более распространено (с широко распространенными примерами, такими как SPF и DKIM) определять использование нескольких строковых значений в TXT запись исключительно как средство разрешения длинных значений и определения того, что все строковые значения должны быть просто объединены перед дальнейшей интерпретацией, вместо этого используя некоторый внутренний разделитель (обычно ;) для многозначного содержимого внутри этой единственной потенциально длинной строки.
Вполне возможно, что ваш провайдер услуг специально рассмотрел очень распространенный сценарий «длинного значения» и так или иначе поддерживает его (особенно вероятно из-за DKIM).
В любом случае, если дизайн программного обеспечения, которое использует эти записи, зависит от вас, может быть лучше просто соответствовать норме в этом отношении и использовать тот же подход к хранению многозначного контента, который используется в эти широко распространенные TXT вместо этого специализации. (Однако такое изменение, очевидно, повлияет на совместимость с существующими записями, если эта система уже используется).