Я делал это с другими поставщиками 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значение, не распознает его, и оно не работает:
;; 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 не позволил нам ввести его, сообщив, что нам нужно ввести только символы 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
Надеюсь, это будет полезно.