Un registro HTTPS describe cómo contactar un sitio web. Es la variante dedicada del SVCB para la web. Puede designar un objetivo y anunciar parámetros como los protocolos, el puerto y los datos ECH. Los navegadores lo utilizan para elegir la mejor conexión.
Un registro HTTPS contiene un nombre, un tipo, una prioridad, un objetivo, parámetros y un TTL. El TTL indica cuánto tiempo la respuesta permanece en caché en el resolutor local.
| Nombre | Tipo | Prioridad | Objetivo | Parámetros | TTL en segundos |
|---|
| test.captaindns.com | HTTPS | 1 | cdn.ejemplo.net. | alpn=h3,h2 port=443 ipv4hint=203.0.113.10 | 3600 |
En este ejemplo el nombre se dirige al sitio web. El objetivo es otro nombre de host. Los parámetros indican los protocolos, la puerta de entrada y una dirección de respaldo. Un TTL a 3600 corresponde a una hora.
La prioridad a cero activa el modo alias. El nombre se comporta entonces como un alias hacia el objetivo.
| Nombre | Tipo | Prioridad | Objetivo | Parámetros | TTL en segundos |
|---|
| captaindns.com | HTTPS | 0 | cdn.ejemplo.net. | (ningún parámetro) | 3600 |
Este modo sirve para dirigirse a otra zona manteniendo la conformidad en el apex donde un CNAME no es deseado.
| Nombre del parámetro | Función |
|---|
| alpn | Anuncia los protocolos como h2 o h3 |
| port | Indica la puerta de entrada del servicio |
| ipv4hint | Proporciona direcciones v4 indicativas |
| ipv6hint | Proporciona direcciones v6 indicativas |
| ech | Publica los datos ECH para cifrar el ClientHello |
Estos parámetros guían al cliente. No reemplazan los registros A y AAAA que siguen siendo la fuente de direcciones.
Un TTL corto hace más visible un cambio. Práctico durante una transición.
Un TTL medio o largo reduce las consultas hacia los servidores autoritarios. Adaptado a un servicio estable.
Reducir el TTL algunas horas antes de un cambio luego subirlo después de la validación.
Bueno saber
Los clientes que no entienden el registro HTTPS utilizan A y AAAA. Publicar HTTPS no elimina la necesidad de mantener estas direcciones.
En www para anunciar h3 o un objetivo de difusión. En el apex en modo alias para dirigirse a un nombre manteniendo la conformidad. En un subdominio de aplicación si el servicio web reside allí.
HTTPS puede coexistir con A y AAAA. Los navegadores eligen IPv6 cuando es posible y vuelven a IPv4 si es necesario.
A evitar
Publicar HTTPS sin A ni AAAA en el objetivo.
Encadenar varios objetivos sin razón.
Declarar parámetros que no corresponden al servicio real.
Una búsqueda DNS en línea permite introducir un nombre. Se ve la prioridad, el objetivo, los parámetros y el TTL tal como se perciben desde Internet. Es un primer control útil. Hacer luego una prueba local desde su máquina.
Windows proporciona nslookup. Se puede usar en modo interactivo.
nslookup
set q=https
ejemplo.com
nslookup
set q=https
server 1.1.1.1
ejemplo.com
La primera parte interroga según la configuración de red de la máquina. La segunda fuerza el uso de un resolutor tercero, aquí el de Cloudflare.
En estos sistemas el comando dig es práctico y fácil de usar.
dig HTTPS ejemplo.com
dig HTTPS ejemplo.com @1.1.1.1
Una prioridad a cero indica un alias. Un valor superior a cero describe un servicio con parámetros.
La presencia de alpn guía la elección h3 o h2. Los campos ipv4hint e ipv6hint son solo indicios.
Un TTL restante elevado puede explicar un desfase después de un cambio.
- Elegir el objetivo. Alias en el apex o publicación de parámetros en
www. - Reducir el TTL a 300 o incluso 60 segundos antes de la implementación.
- Publicar el registro HTTPS con la prioridad, el objetivo y los parámetros elegidos.
- Verificar con nslookup o con el comando dig desde varias redes.
- Subir el TTL cuando todo esté estable.
Consejo práctico
Documentar la prioridad, el objetivo y cada parámetro. Conservar la fecha y la razón del cambio. Esta traza facilita los controles.
Publicar alpn h3 en www. Mantener h2 para compatibilidad.
Usar el modo alias para dirigirse al nombre proporcionado por el servicio. Mantener A y AAAA en el objetivo.
Publicar ech cuando la plataforma lo proporciona. Verificar el soporte del lado del navegador.
- Si el sitio no se beneficia de h3 verificar la presencia de alpn y el soporte del lado del servidor.
- Si los clientes ignoran HTTPS verificar A y AAAA en el objetivo.
- Si aparece un bucle verificar que el objetivo no reenvía hacia el nombre de origen.
- Si la respuesta sigue siendo antigua a pesar de la actualización esperar la expiración del TTL y purgar la caché del resolutor local si es posible.
En resumen, un registro HTTPS anuncia la forma óptima de contactar un sitio web. Puede servir como alias controlado y publicar parámetros útiles como alpn, port y ech. Un TTL bien ajustado facilita las transiciones. La verificación pasa por una herramienta en línea luego por nslookup y por dig.
Con estas referencias la gestión permanece clara. Los cambios se desarrollan sin estrés. Los usuarios acceden al sitio sin incidentes.