He hecho esto con otros proveedores de DNS pero estoy atascado en la interfaz de administración de DNS de UltraDNS. Necesito ingresar varios valores en una TXTentrada para que se resuelvan como una sola cadena con cada valor entre marcas " y separados por un espacio.
Un ejemplo de lo que queremos que devuelva el registro TXT es el siguiente (usando dig para Linux para probarlos):
;; ANSWER SECTION:
name._avaya-ep-config._tcp.example.com. 119 IN TXT "txtvers=1" "proto=https" "path=/acs/resources/configurations"
Sin embargo, el soporte de UltraDNS dijo que tenemos que ingresarlos como TXTregistros separados; cuando lo hacemos, devuelve lo siguiente y el software que busca este TXTvalor no lo reconoce y no funciona:
;; 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"
Hemos intentado utilizar comillas dobles, \para citar por RFC y también por RFC, según RFC aquí: https://www.rfc-editor.org/rfc/rfc1464
Cuando probamos algunas de las sugerencias del ejemplo RFC, la interfaz web de UltraDNS no nos permitió ingresar diciendo que solo teníamos que ingresar caracteres ASCII (que eran todos, pero también eran código para otros conjuntos de caracteres ASCII).
Entrada no válida: solo se admiten caracteres ASCII para comentarios
Al ingresar así por ejemplo:
\txtvers=1\"<sp>\"proto=https\"<sp>\"path=/acs/resources/configurations\
El software también usa SRVy PTRregistra, y eso funciona; simplemente no obtiene nuestra ruta del TXTvalor como debería debido a este problema de formato.
Respuesta1
Lo que es importante reconocer aquí es que un TXTregistro puede tener varios valores y los datos del registro contienen una o más cadenas, cada una de hasta 255 caracteres de largo.
Es decir, un TXTregistro con múltiples valores y múltiples TXTregistros con un valor cada uno no son lo mismo y no se debe esperar que se interpreten de la misma manera.
Lo que mostraste inicialmente no es en realidad un TXTdisco que hayauna sola cadena con cada valor en marcas " y separados por un espaciosino más bien un TXTregistro que tiene tres valores de cadena separados que no contienen comillas ni espacios.
Esta comprensión es particularmente importante ya que una de las cosas que intentó hacer en sus intentos de resolver el problema implicó escapar de estos caracteres que se utilizan con fines de formato pero que en realidad no son parte del valor.
Para cualquier software que comprenda y utilice el DNSformato de archivo maestro(representación de texto estándar de registros DNS), lo que incluyó inicialmente ... TXT "txtvers=1" "proto=https" "path=/acs/resources/configurations"se entendería e interpretaría como un TXTregistro con tres valores de cadena separados ( ,, txtvers=1) .proto=httpspath=/acs/resources/configurations
Si su proveedor de servicios tiene una interfaz que no acepta esta forma de entrada y no proporciona ningún otro medio para ingresar múltiples valores (la respuesta que recibió de ellos sugiere que ese podría ser el caso), es posible que no haya forma de ingresar el registro deseado. en su sistema.
Si ese es realmente el caso, es posible que deba considerar alojar este registro en otro lugar (incluidas opciones como no mover toda su zona pero tener el TXTregistro deseado en una zona diferente alojada en otro lugar y solo agregar un CNAMEpunto allí, siempre que el software en cuestión no está de alguna manera en desacuerdo con esto).
Dicho esto, en usos especializados de TXTcomo parte de otros estándares, es más común (con ejemplos generalizados como SPF y DKIM) definir el uso de múltiples valores de cadena en un TXTregistro simplemente como una forma de permitir valores largos y definir que todos los valores de la cadena simplemente deben concatenarse antes de realizar una interpretación adicional, en lugar de usar algún delimitador interno (generalmente ;) para el contenido de múltiples valores dentro de esa cadena única, potencialmente larga.
Es muy posible que su proveedor de servicios haya analizado específicamente el escenario muy común de "valor a largo plazo" y lo respalde de una forma u otra (especialmente debido a DKIM).
De cualquier manera, si el diseño del software que consume estos registros depende de usted, puede ser una mejor idea simplemente ajustarse a la norma a este respecto y utilizar el mismo enfoque para almacenar contenido multivalor que se utiliza en estas TXTespecializaciones generalizadas en su lugar. (Sin embargo, tal cambio obviamente afectaría la compatibilidad con los registros existentes si este sistema ya está en uso).
Respuesta2
Solución alternativa: agregue el registro TXT como se indica a continuación
parmset=txtvers=1,proto=https,path=/acs/resources/configurations
Espero que esto sea útil