Tipos de registros de DNS admitidos - Amazon Route 53

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Tipos de registros de DNS admitidos

Amazon Route 53 admite los tipos de registros de DNS que se indican en esta sección. Cada tipo de registro incluye también un ejemplo de cómo formatear el elemento Value cuando tenga acceso a Route 53 mediante la API.

nota

Para los tipos de registros que incluyen un nombre de dominio, especifique un nombre de dominio completo (por ejemplo, www.example.com). El punto final es opcional; Route 53 presupone que el nombre de dominio es completo. Esto significa que Route 53 trata a www.example.com (sin punto final) y www.example.com. (con punto final) de idéntica forma.

Route 53 proporciona una extensión a la funcionalidad DNS conocida como registros de alias. Al igual que los registros CNAME, los registros de alias le permiten enrutar el tráfico a AWS recursos seleccionados, como CloudFront distribuciones y buckets de Amazon S3. Para obtener más información, incluida una comparación de registros CNAME y alias, consulte Elección entre registros de alias y sin alias.

Un tipo de registro

Se utiliza un registro A para enrutar el tráfico a un recurso, como un servidor web, mediante una IPv4 dirección en notación decimal punteada.

Ejemplo de la consola de Amazon Route 53

192.0.2.1

Ejemplo de la API de Route 53

<Value>192.0.2.1</Value>

Tipo de registro AAAA

Se utiliza un registro AAAA para enrutar el tráfico a un recurso, como un servidor web, mediante una IPv6 dirección en formato hexadecimal separado por dos puntos.

Ejemplo de la consola de Amazon Route 53

2001:0db8:85a3:0:0:8a2e:0370:7334

Ejemplo de la API de Route 53

<Value>2001:0db8:85a3:0:0:8a2e:0370:7334</Value>

Tipo de registro de CAA

Un registro CAA especifica qué autoridades de certificación (CAs) pueden emitir certificados para un dominio o subdominio. La creación de un registro CAA ayuda a evitar que personas incorrectas CAs emitan certificados para sus dominios. Un registro de CAA no es un sustituto de los requisitos de seguridad que especifica su entidad de certificación como, por ejemplo, la necesidad de validar que usted es el propietario de un dominio.

Puede utilizar los registros CAA para especificar lo siguiente:

  • ¿Qué autoridades de certificación (CAs) pueden emitir SSL/TLS certificados, si los hay

  • La dirección de correo electrónico o URL con la que hay que contactar en caso de que una CA emita un certificado para el dominio o subdominio.

Cuando añade un registro de CAA a su zona alojada, debe especificar tres valores separados por espacios:

flags tag "value"

Tenga en cuenta lo siguiente en relación con el formato de los registros CAA:

  • El valor de tag solo puede contener los caracteres A-Z, a-z y 0-9.

  • Encuadre siempre value entre comillas ("").

  • Algunas CAs permiten o requieren valores adicionales paravalue. Especifique valores adicionales como pares nombre-valor y sepárelos con punto y coma (;), por ejemplo:

    0 issue "ca.example.net; account=123456"

  • En caso de que una CA reciba una solicitud de certificado para un subdominio (como www.example.com) y si no existe registro de CAA del subdominio, la CA enviará una consulta de DNS para un registro de CAA para el dominio principal (como example.com). Si existe un registro de dominio principal y si la solicitud de certificado es válida, la CA genera el certificado para el subdominio.

  • Le recomendamos que consulte a su CA para determinar qué valores especificar para un registro de CAA.

  • No se puede crear un registro de CAA y un registro CNAME que tengan el mismo nombre, ya que el DNS no permite utilizar el mismo nombre para un registro CNAME y cualquier otro tipo de registro.

Autorización a una CA a emitir un certificado para un dominio o subdominio

Para autorizar a una CA a emitir un certificado para un dominio o un subdominio, cree un registro que tenga el mismo nombre que el dominio o subdominio y especifique la siguiente configuración:

  • marcadores: 0

  • etiqueta: issue

  • valor: el código de la CA a la que autoriza a emitir un certificado para el dominio o subdominio

Por ejemplo, suponga que desea autorizar ca.example.net para que emita un certificado para example.com. Puede crear un registro de CAA para example.com con la siguiente configuración:

0 issue "ca.example.net"

Para obtener información sobre AWS Certificate Manager cómo autorizar la emisión de un certificado, consulte Configurar un registro CAA en la Guía del AWS Certificate Manager usuario.

Autorización a una CA a emitir un certificado comodín para un dominio o subdominio

Para autorizar a una CA a emitir un certificado comodín para un dominio o subdominio, cree un registro que tenga el mismo nombre que el dominio o subdominio y especifique la siguiente configuración: Un certificado comodín se aplica al dominio o subdominio y a todos sus subdominios.

  • marcadores: 0

  • etiqueta: issuewild

  • valor: el código de la CA a la que autoriza a emitir un certificado para un dominio o subdominio y sus subdominios

Por ejemplo, suponga que desea autorizar a ca.example.net a emitir un certificado comodín para example.com, que se aplica a example.com y todos sus subdominios. Puede crear un registro de CAA para example.com con la siguiente configuración:

0 issuewild "ca.example.net"

Cuando quiera autorizar a una CA a emitir un certificado comodín para un dominio o subdominio, cree un registro que tenga el mismo nombre que el dominio o subdominio y especifique la siguiente configuración: Un certificado comodín se aplica al dominio o subdominio y a todos sus subdominios.

Evitar que cualquier CA emita un certificado para un dominio o un subdominio

Para evitar que cualquier CA emita un certificado para un dominio o un subdominio, cree un registro que tenga el mismo nombre que el dominio o subdominio y especifique la siguiente configuración:

  • marcadores: 0

  • etiqueta: issue

  • valor: ";"

Por ejemplo, suponga que no desea que ninguna CA emita un certificado para example.com. Puede crear un registro de CAA para example.com con la siguiente configuración:

0 issue ";"

Si no quiere que ninguna CA emita un certificado para example.com o sus subdominios, debe crear un registro de CAA para example.com con la siguiente configuración:

0 issuewild ";"

nota

Si crea un registro de CAA para example.com y especifica los dos valores siguientes, una CA que utiliza el valor ca.example.net puede emitir el certificado para example.com:

0 issue ";" 0 issue "ca.example.net"

Solicitar que cualquier CA se ponga en contacto con usted si la CA recibe una solicitud de certificado no válida

Si desea que toda CA que reciba una solicitud no válida de certificado se ponga en contacto con usted, especifique la siguiente configuración:

  • marcadores: 0

  • etiqueta: iodef

  • valor: la dirección URL o la dirección de correo electrónico a la que desea que la CA envíe una notificación si recibe una solicitud no válida de certificado. Use el formato aplicable:

    "mailto:email-address"

    "http://URL"

    "https://URL"

Por ejemplo, si desea que toda CA que recibe una solicitud no válida de certificado envíe un correo electrónico a admin@example.com, cree un registro de CAA con la siguiente configuración:

0 iodef "mailto:admin@example.com"

Uso de otra opción compatible con la CA

Si la CA admite una característica que no está definida en RFC para registros de CAA, especifique la siguiente configuración:

  • marcadores: 128 (este valor impide que la CA emita un certificado si esta no es compatible con la característica especificada).

  • etiqueta: la etiqueta que la CA tiene permiso para utilizar

  • valor: el valor que corresponde al valor de etiqueta

Por ejemplo, suponga que la CA admita el envío de un mensaje de texto si recibe una solicitud de certificado no válida. (No conocemos ninguno CAs que admita esta opción). La configuración del registro podría ser la siguiente:

128 exampletag "15555551212"

Ejemplos

Ejemplo de la consola de Route 53

0 issue "ca.example.net" 0 iodef "mailto:admin@example.com"

Ejemplo de la API de Route 53

<ResourceRecord> <Value>0 issue "ca.example.net"</Value> <Value>0 iodef "mailto:admin@example.com"</Value> </ResourceRecord>

Tipo de registro CNAME

Un registro CNAME asigna consultas DNS para el nombre del registro actual, como acme.example.com, a otro dominio (example.com o example.net) o subdominio (acme.example.com o zenith.example.org).

importante

El protocolo DNS no permite crear un registro CNAME para el nodo superior de un espacio de nombres de DNS, también conocido como ápex de zona. Por ejemplo, si registra el nombre DNS example.com, el vértice de zona será example.com. No puede crear un registro CNAME para ejemplo.com, pero puede crear registros CNAME para www.ejemplo.com, nuevoproducto.ejemplo.com, etcétera.

Además, si crea un registro CNAME para un subdominio, no puede crear ningún otro registro para ese subdominio. Por ejemplo, si crea un CNAME para www.example.com, no puede crear ningún otro registro para el que el valor del campo Name (Nombre) sea www.example.com.

Amazon Route 53 también admite registros de alias, que le permiten enrutar las consultas a AWS recursos seleccionados, como CloudFront distribuciones y buckets de Amazon S3. Los alias son similares en cierto sentido al tipo de registro CNAME; sin embargo, puede crear un alias para el ápex de zona. Para obtener más información, consulte Elección entre registros de alias y sin alias.

Ejemplo de la consola de Route 53

hostname.example.com

Ejemplo de la API de Route 53

<Value>hostname.example.com</Value>

Tipo de registro DS

Un registro de firmante de delegación (DS) hace referencia a una clave de zona para una zona de subdominio delegada. Puede crear un registro DS cuando establezca una cadena de confianza al configurar la firma DNSSEC. Para obtener más información sobre la configuración de DNSSEC en Route 53, consulte Configuración de la firma de DNSSEC en Amazon Route 53.

Los tres primeros valores son números decimales que representan la etiqueta de clave, el algoritmo y el tipo de resumen. El cuarto valor es el resumen de la clave de zona. Para obtener más información acerca del formato del registro DS, consulte RFC 4034.

Ejemplo de la consola de Route 53

123 4 5 1234567890abcdef1234567890absdef

Ejemplo de la API de Route 53

<Value>123 4 5 1234567890abcdef1234567890absdef</Value>

Tipo de registro HTTPS

Un registro de recursos HTTPS es una forma del registro DNS de Service Binding (SVCB) que proporciona información de configuración ampliada, lo que permite al cliente conectarse de forma fácil y segura a un servicio con un protocolo HTTP. La información de configuración se proporciona en parámetros que permiten la conexión en una consulta de DNS, en lugar de necesitar varias consultas de DNS.

El formato de un registro de recursos HTTPS es:

SvcPriority TargetName SvcParams(optional)

Los siguientes parámetros se describen en la sección 9.1 del RFC 9460.

SvcPriority

Un número entero que representa la prioridad. La prioridad 0 significa modo alias y, por lo general, se utiliza para crear alias en el vértice de la zona. Este valor es un entero de 0 a 32767 para Route 53, de los cuales 1 a 32767 son registros de modo de servicio. Cuanto menor sea la prioridad, mayor será la preferencia.

TargetName

El nombre de dominio del alias objetivo (para el modo de alias) o del punto final alternativo (paraServiceMode).

SvcParams (opcional)

Una lista separada por espacios en blanco, en la que cada parámetro consta de un par clave=valor o de una clave independiente. Si hay más de un valor, se presentan como una lista separada por comas. Los siguientes son los definidos: SvcParams

  • 1:alpn— Protocolo de capa de aplicación: Protocolo de negociación IDs. El valor predeterminado es HTTP/1.1, h2 HTTP/2 sobre TLS y h3 HTTP/3 (HTTP sobre el protocolo QUIC).

  • 2:no-default-alpn— El valor predeterminado no es compatible y debe proporcionar un parámetro. alpn

  • 3:port— el punto final alternativo o el puerto al que se puede acceder al servicio.

  • 4:ipv4hint— sugerencias IPv4 de dirección.

  • 5:ech— Cliente cifrado Hola.

  • 6:ipv6hint— sugerencias IPv6 de dirección.

  • 7:dohpath— Plantilla DNS a través de HTTPS

  • 8:ohttp— El servicio opera con un objetivo HTTP Oblivious

Ejemplo de la consola Amazon Route 53 para el modo alias

0 example.com

Ejemplo de la consola Amazon Route 53 para el modo de servicio

16 example.com alpn="h2,h3" port=808

Ejemplo de la API de Amazon Route 53 para el modo alias

<Value>0 example.com</Value>

Ejemplo de la API de Route 53 para el modo de servicio

<Value>16 example.com alpn="h2,h3" port=808</Value>

Para obtener más información, consulte el RFC 9460, Vinculación de servicios y especificación de parámetros mediante el DNS (registros de recursos SVCB y HTTPS).

nota

Route 53 no admite el formato de presentación arbitrario de clave desconocida keyNNNNN

Tipo de registro MX

Un registro MX especifica los nombres de los servidores de correo y, si tiene dos o más servidores de este tipo, el orden de prioridad. Cada valor de un registro MX contiene dos valores, que son la prioridad y el nombre del dominio.

Priority (Prioridad)

Un número entero que representa la prioridad de un servidor de correo electrónico. Si especifica un único servidor, la prioridad puede ser cualquier número entero comprendido entre 0 y 65535. Si especifica varios servidores, el valor que especifique para la prioridad indica el primer servidor de correo electrónico al que se debe enviar el correo electrónico, el segundo y así sucesivamente. El servidor que tenga el valor más bajo para la prioridad será el prioritario. Por ejemplo, si tiene dos servidores de correo electrónico y especifica los valores de 10 y 20 para la prioridad, el correo electrónico siempre se envía al servidor con la prioridad de 10 a menos que no esté disponible. Si especifica los valores de 10 y 10, el correo electrónico se redirige a los dos servidores aproximadamente en partes iguales.

Nombre del dominio

El nombre del dominio del servidor de correo electrónico. Especifique el nombre (por ejemplo, mail.example.com) de un registro A o AAAA. En RFC 2181, Clarifications to the DNS Specification, la sección 10.3 prohíbe especificar el nombre de un registro CNAME para valor del nombre de dominio. (Cuando la especificación RFC habla de “alias”, se refiere a un registro CNAME, no a un registro de alias de Route 53).

Ejemplo de la consola de Amazon Route 53

10 mail.example.com

Ejemplo de la API de Route 53

<Value>10 mail.example.com</Value>

Tipo de registro NAPTR

Un NAPTR (Name Authority Pointer, Señalizador de autoridad de asignación de nombres) es un tipo de registro que usan las aplicaciones DDDS (Dynamic Delegation Discovery System, Sistema de detección de delegación dinámica) para convertir un valor en otro o para sustituir un valor por otro. Por ejemplo, un uso común es convertir números de teléfono a SIP. URIs

El elemento Value de un registro NAPTR consta de seis valores separados por espacios:

Order

Cuando especifica más de un registro, el orden en que desea que la aplicación DDDS evalúe los registros. Valores válidos: 0 - 65535.

Preference

Cuando especifica dos o más registros que tienen el mismo valor de Order, el orden preferido en el que desea que se evalúen esos registros. Por ejemplo, si dos registros tienen un valor de Order de 1, la primera aplicación DDDS evalúa el registro que tiene el valor de Preference menor. Valores válidos: 0 - 65535.

Indicadores

Un valor específico de las aplicaciones DDDS. Los valores definidos actualmente en RFC 3404 son las letras mayúsculas y minúsculas "A", "P", "S" y "U" y la cadena vacía, "". Incluya los valores de Flags entre comillas.

Servicio

Un valor específico de las aplicaciones DDDS. Incluya los valores de Service entre comillas.

Para obtener más información, consulte la sección correspondiente RFCs:

Regexp

Una expresión regular que la aplicación DDDS utiliza para convertir un valor de entrada en un valor de salida. Por ejemplo, un sistema de telefonía por IP podría utilizar una expresión regular para convertir un número de teléfono introducido por un usuario en un URI de SIP. Incluya los valores de Regexp entre comillas. Especifique un valor para Regexp o un valor para Replacement, pero no ambos.

Las expresiones regulares pueden incluir cualquiera de los siguientes caracteres ASCII imprimibles:

  • a-z

  • 0-9

  • - (guion)

  • (espacio)

  • ! # $ % & ' ( ) * + , - / : ; < = > ? @ [ ] ^ _ ` { | } ~ .

  • " (comillas). Para incluir un carácter de comillas literal en una cadena, incluya un carácter \ delante: \".

  • \ (barra diagonal invertida). Para incluir una barra diagonal invertida en una cadena, incluya un carácter \ delante: \\.

Especifique el resto de los valores, como los nombres de dominio internacionalizados, en formato octal.

Para ver la sintaxis de Regexp, consulte RFC 3402, sección 3.2, Substitution Expression Syntax

Reemplazo

El nombre de dominio completo (FQDN) del siguiente nombre de dominio para el que desea que la aplicación DDDS envíe una consulta DNS. La aplicación DDDS sustituye el valor de entrada por el valor que especifique para Replacement, si especifica alguno. Especifique un valor para Regexp o un valor para Replacement, pero no ambos. Si especifica un valor para Regexp, especifique un punto (.) para Replacement (Sustituto).

El nombre de dominio puede incluir a-z, 0-9 y - (guion).

Para obtener más información sobre las aplicaciones DDDS y los registros NAPTR, consulte lo siguiente: RFCs

Ejemplo de la consola de Amazon Route 53

100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" . 100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" . 100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .

Ejemplo de la API de Route 53

<ResourceRecord> <Value>100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" .</Value> <Value>100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" .</Value> <Value>100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .</Value> </ResourceRecord>

Tipo de registro NS

Un registro NS identifica los servidores de nombres de la zona alojada. Tenga en cuenta lo siguiente:

  • El uso más común de un registro NS es controlar cómo se enruta el tráfico de Internet para un dominio. Para utilizar los registros de una zona alojada para enrutar el tráfico de un dominio, actualice la configuración del registro de dominio para utilizar los cuatro servidores de nombres en el registro NS predeterminado. (Este es el registro NS que tiene el mismo nombre que la zona alojada).

  • Puede crear una zona alojada independiente para un subdominio (acme.example.com) y utilizarla para enrutar el tráfico de Internet del subdominio y de los subdominios de este (subdominio.acme.example.com). Para establecer esta configuración, conocida como “delegar la responsabilidad de un subdominio a una zona alojada”, se crea otro registro NS en la zona alojada para el dominio raíz (example.com). Para obtener más información, consulte Direccionamiento del tráfico de subdominios.

  • También se utilizan registros NS para configurar servidores de nombres de etiqueta blanca. Para obtener más información, consulte Configuración de servidores de nombres de etiqueta blanca.

  • Otro uso de un registro NS es para las zonas alojadas privadas cuando se crea una regla de delegación para delegar la autoridad de un subdominio a la resolución local. Debe crear este registro NS antes de crear una regla de delegado. Para obtener más información, consulte Cómo el punto final Route 53 Resolver reenvía las consultas de DNS de su red VPCs a su red.

Para obtener más información acerca de los registros NS, consulte Registros SOA y NS que crea Amazon Route 53 para una zona alojada pública.

Ejemplo de la consola de Amazon Route 53

ns-1.example.com

Ejemplo de la API de Route 53

<Value>ns-1.example.com</Value>

Tipo de registro PTR

Un registro PTR asigna una dirección IP al nombre de dominio correspondiente.

Ejemplo de la consola de Amazon Route 53

hostname.example.com

Ejemplo de la API de Route 53

<Value>hostname.example.com</Value>

Tipo de registro SOA

Un registro de inicio de autoridad (SOA) proporciona información sobre un dominio y la zona alojada de Amazon Route 53 correspondiente. Para obtener información sobre los campos de un registro SOA, consulte Registros SOA y NS que crea Amazon Route 53 para una zona alojada pública.

Ejemplo de la consola de Route 53

ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60

Ejemplo de la API de Route 53

<Value>ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60</Value>

Tipo de registro SPF

Los registros SPF se usaban anteriormente para verificar la identidad del remitente de mensajes de correo electrónico. Sin embargo, ya no se recomienda crear registros para los que el tipo de registro sea SPF. El RFC 7208, versión 1, titulado Marco de políticas de remitentes (SPF) para autorizar el uso de dominios en el correo electrónico, se ha actualizado para que diga: «... [Su] existencia y el mecanismo definido en [RFC4408] han provocado algunos problemas de interoperabilidad. Por lo tanto, su uso ya no es adecuado para SPF, versión 1; las implementaciones no van a utilizarlo”. En RFC 7208, consulte la sección 14.1, The SPF DNS Record Type.

En lugar de un registro SPF, le recomendamos que cree un registro TXT que contenga el valor correspondiente. Para obtener más información sobre valores válidos, consulte el artículo de Wikipedia Sender Policy Framework.

Ejemplo de la consola de Amazon Route 53

"v=spf1 ip4:192.168.0.1/16 -all"

Ejemplo de la API de Route 53

<Value>"v=spf1 ip4:192.168.0.1/16 -all"</Value>

Tipo de registro SRV

El elemento Value de un registro SRV consta de cuatro valores separados por espacios. Los tres primeros valores son números decimales que representan la prioridad, el peso y el puerto. El cuarto valor es un nombre de dominio. Los registros SRV se utilizan para acceder a servicios, como un servicio de correo electrónico o comunicaciones. Para obtener información sobre el formato del registro SRV, consulte la documentación del servicio al que desee conectarse.

Ejemplo de la consola de Amazon Route 53

10 5 80 hostname.example.com

Ejemplo de la API de Route 53

<Value>10 5 80 hostname.example.com</Value>

Tipo de registro SSHFP

Un registro de huellas dactilares de Secure Shell (SSHFP) identifica las claves SSH asociadas al nombre de dominio. Los registros de SSHFP deben estar protegidos con DNSSEC para poder establecer una cadena de confianza. Para obtener más información sobre DNSSEC, consulte Configuración de la firma de DNSSEC en Amazon Route 53

El formato de un registro de recursos SSHFP es:

[Key Algorithm] [Hash Type] Fingerprint

Los siguientes parámetros se definen en el RFC 4255.

Algoritmo clave

Tipo de algoritmo:

  • 0— Reservado y no utilizado.

  • 1: RSA— El algoritmo Rivest—Shamir—Adleman es uno de los primeros criptosistemas de clave pública y todavía se utiliza para la transmisión segura de datos.

  • 2: DSA— El algoritmo de firma digital es un estándar federal de procesamiento de información para firmas digitales. El DSA se basa en la exponenciación modular y en los modelos matemáticos de logaritmos discretos.

  • 3: ECDSA— El algoritmo de firma digital de curva elíptica es una variante del DSA que utiliza criptografía de curva elíptica.

  • 4: Ed25519— El algoritmo Ed25519 es el esquema de firma EdDSA que utiliza SHA-512 (SHA-2) y Curve25519.

  • 6: Ed448— Ed448 es el esquema de firma EdDSA que utiliza el Curve448. SHAKE256

Tipo de hash

Algoritmo utilizado para crear el hash de clave pública:

  • 0—Reservado y no utilizado.

  • 1: SHA-1

  • 2: SHA-256

Huella digital

Representación hexadecimal del hash.

Ejemplo de la consola de Amazon Route 53

1 1 09F6A01D2175742B257C6B98B7C72C44C4040683

Ejemplo de la API de Route 53

<Value>1 1 09F6A01D2175742B257C6B98B7C72C44C4040683</Value>

Para obtener más información, consulte el RFC 4255: Uso del DNS para publicar de forma segura las huellas digitales de claves de Secure Shell (SSH).

Tipo de registro SVCB

Se utiliza un registro SVCB para proporcionar información de configuración para acceder a los puntos finales del servicio. El SVCB es un registro DNS genérico y se puede utilizar para negociar los parámetros de una variedad de protocolos de aplicación.

El formato de un registro de recursos SVCB es:

SvcPriority TargetName SvcParams(optional)

Los siguientes parámetros se describen en la sección 2.3 del RFC 9460.

SvcPriority

Un número entero que representa la prioridad. La prioridad 0 significa modo alias y, por lo general, se utiliza para crear alias en el vértice de la zona. Cuanto menor sea la prioridad, mayor será la preferencia.

TargetName

El nombre de dominio del alias objetivo (para el modo de alias) o del punto final alternativo (paraServiceMode).

SvcParams (opcional)

Una lista separada por espacios en blanco, en la que cada parámetro consta de un par clave=valor o de una clave independiente. Si hay más de un valor, se presentan como una lista separada por comas. Este valor es un entero de 0 a 32767 para Route 53, de los cuales 1 a 32767 son registros de modo de servicio. Los siguientes son los definidos: SvcParams

  • 1:alpn— Protocolo de capa de aplicación: Protocolo de negociación IDs. El valor predeterminado es HTTP/1.1, h2 HTTP/2 sobre TLS y h3 HTTP/3 (HTTP sobre el protocolo QUIC).

  • 2:no-default-alpn— El valor predeterminado no es compatible y debe proporcionar un parámetro. alpn

  • 3:port— el puerto del punto final alternativo desde el que se puede acceder al servicio.

  • 4:ipv4hint— sugerencias IPv4 de dirección.

  • 5:ech— Cliente cifrado Hola.

  • 6:ipv6hint— sugerencias IPv6 de dirección.

  • 7:dohpath— Plantilla DNS a través de HTTPS

  • 8:ohttp— El servicio opera con un objetivo HTTP Oblivious

Ejemplo de la consola Amazon Route 53 para el modo alias

0 example.com

Ejemplo de la consola Amazon Route 53 para el modo de servicio

16 example.com alpn="h2,h3" port=808

Ejemplo de la API de Amazon Route 53 para el modo alias

<Value>0 example.com</Value>

Ejemplo de la API de Route 53 para el modo de servicio

<Value>16 example.com alpn="h2,h3" port=808</Value>

Para obtener más información, consulte el RFC 9460, Vinculación de servicios y especificación de parámetros mediante el DNS (registros de recursos SVCB y HTTPS).

nota

Route 53 no admite el formato de presentación arbitrario de clave desconocida keyNNNNN

Tipo de registro TLSA

Se utiliza un registro TLSA para utilizar la autenticación de entidades con nombre (DANE) basada en DNS. Un registro TLSA asocia una certificate/public clave a un punto final de Transport Layer Security (TLS) y los clientes pueden validar la certificate/public clave mediante un registro TLSA firmado con DNSSEC.

Solo se puede confiar en los registros de TLSA si el DNSSEC está habilitado en su dominio. Para obtener más información sobre DNSSEC, consulte Configuración de la firma de DNSSEC en Amazon Route 53

El formato de un registro de recursos de la TLSA es:

[Certificate usage] Selector [Matching type] [Certificate association data]

Los siguientes parámetros se especifican en la sección 3 del RFC 6698.

Uso de certificados

Especifica la asociación proporcionada que se utilizará para que coincida con el certificado presentado en el protocolo de enlace TLS:

  • 0: Restricción de CA: el certificado o la clave pública debe encontrarse en cualquiera de las rutas de certificación de la infraestructura de clave pública (PKIX) del certificado de entidad final proporcionado por el servidor en TLS. Esta restricción limita lo que se CAs puede utilizar para emitir certificados para un servicio específico.

  • 1: Restricción de certificado de servicio: especifica un certificado de entidad final (o la clave pública) que debe coincidir con el certificado de entidad final proporcionado por el servidor en TLS. Esta certificación limita qué certificado de entidad final puede usar un servicio específico en un host.

  • 2: Una afirmación de anclaje de confianza: especifica un certificado (o la clave pública) que debe usarse como «ancla de confianza» al validar el certificado de entidad final emitido por el servidor en TLS. Permite al administrador de un dominio especificar un ancla de confianza.

  • 3: Certificación emitida por el dominio: especifica un certificado (o la clave pública) que debe coincidir con el certificado de la entidad final emitido por el servidor en TLS. Esta certificación permite al administrador de dominios emitir certificados para un dominio sin la participación de una entidad emisora de certificados externa. No es necesario que este certificado pase la validación de PKIX.

Selector

Especifica qué parte del certificado presentado por el servidor en el protocolo de enlace coincide con el valor de la asociación:

  • 0: Debe coincidir todo el certificado.

  • 1: La clave pública del asunto, o la estructura binaria codificada en DER, debe coincidir.

Tipo coincidente

Especifica la presentación (según lo determinado por el campo Selector) de la coincidencia del certificado:

  • 0: Coincidencia exacta del contenido.

  • 1: hash SHA-256.

  • 2: hachís SHA-512.

Datos de asociación del certificado

Los datos que se van a comparar se basan en la configuración de los demás campos.

Ejemplo de la consola de Amazon Route 53

0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971

Ejemplo de la API de Route 53

<Value>0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971</Value>

Para obtener más información, consulte el RFC 6698, Protocolo de seguridad de la capa de transporte (TLS) de autenticación de entidades nombradas (DANE) basada en DNS: TLSA.

Tipo de registro TXT

Un registro TXT contiene una o varias cadenas que se encierran entre comillas dobles ("). Al utilizar la política de direccionamiento sencilla, incluye todos los valores de un dominio (example.com) o subdominio (www.example.com) en el mismo registro TXT.

Introducción de valores de registro TXT

Una única cadena puede incluir hasta 255 caracteres, entre las que se incluyen las siguientes:

  • a-z

  • A-Z

  • 0-9

  • Espacio

  • - (guion)

  • ! " # $ % & ' ( ) * + , - / : ; < = > ? @ [ \ ] ^ _ ` { | } ~ .

Si necesita introducir un valor de más de 255 caracteres, divida el valor en cadenas de 255 caracteres o menos e incluya cada cadena entre comillas dobles ("). En la consola, enumere todas las cadenas de la misma línea:

"String 1" "String 2" "String 3"

En la API, incluya todas las cadenas en el mismo elemento Value:

<Value>"String 1" "String 2" "String 3"</Value>

La longitud máxima de un valor en un registro TXT es de 4000 caracteres.

Para ingresar más de un valor TXT, ingrese un valor por fila.

Caracteres especiales en un valor de registro TXT

Si su registro TXT contiene alguno de los siguientes caracteres, debe especificarlos mediante códigos de escape en el formato siguiente: \ three-digit octal code

  • Caracteres de 000 a 040 octales (de 0 a 32 decimales, de 0x20 a 0x00 hexadecimales)

  • Caracteres de 177 a 377 octales (de 127 a 255 decimales, de 0x7F a 0xFF hexadecimales)

Por ejemplo, si el valor de su registro TXT es "exämple.com", especifique "ex\344mple.com".

Para mapear los caracteres ASCII y los códigos octales, busque «códigos octales ASCII» en Internet. Una referencia útil es ASCII Code - The extended ASCII table.

Para incluir una comilla (") en una cadena, ponga una contrabarra (\) delante de esta: \".

Mayúsculas y minúsculas en un valor de registro TXT

Se distingue entre mayúsculas y minúsculas, por lo que "Ab" y "aB" son valores diferentes.

Ejemplos

Ejemplo de la consola de Amazon Route 53

Ponga cada valor en una línea independiente:

"This string includes \"quotation marks\"." "The last character in this string is an accented e specified in octal format: \351" "v=spf1 ip4:192.168.0.1/16 -all"

Ejemplo de la API de Route 53

Ponga cada valor en un elemento Value independiente:

<Value>"This string includes \"quotation marks\"."</Value> <Value>"The last character in this string is an accented e specified in octal format: \351"</Value> <Value>"v=spf1 ip4:192.168.0.1/16 -all"</Value>