Ввод нескольких значений TXT DNS в виде одной записи TXT, каждое из которых указано в знаках "", но разделены пробелами
Я сделал это с другими провайдерами 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://tools.ietf.org/html/rfc1464
Когда мы попробовали некоторые предложения из примера RFC, веб-интерфейс UltraDNS не позволил нам войти в него, сказав, что мы должны были вводить только символы ASCII (которые были, но они также были кодом для других наборов символов ASCII).
Неверный ввод: для комментария поддерживаются только символы ASCII
При вводе, как это, например:
\txtvers=1\"<sp>\"proto=https\"<sp>\"path=/acs/resources/configurations\
Программное обеспечение также использует SRV а также PTR записи и эти работы - это просто не получить наш путь от TXT значение как следует из-за этой проблемы форматирования.
2 ответа
Здесь важно признать, что 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 специализации вместо. (Однако такое изменение, очевидно, повлияет на совместимость с существующими записями, если эта система уже используется).
Обходной путь: добавьте запись TXT, как показано ниже.
parmset=txtvers=1,proto=https,path=/acs/resources/configurations
Надеюсь, это полезно