Un registro SVCB describe cómo contactar un servicio. Puede designar otro nombre y dar parámetros como el protocolo, la dirección de respaldo y el puerto. Para un sitio web, se publica a menudo un registro HTTPS que es la variante dedicada del SVCB.
Un registro SVCB 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 |
|---|
| _imap._tcp.ejemplo.com | SVCB | 1 | mail.ejemplo.net. | alpn=imap port=993 ipv4hint=203.0.113.10 | 3600 |
En este ejemplo el nombre se dirige al servicio imap en tcp. El objetivo es otro nombre de host. Los parámetros indican el protocolo, la puerta de entrada y una dirección de respaldo. Un TTL a 3600 corresponde a una hora.
La prioridad a cero activa un modo alias. El nombre se comporta entonces como un alias hacia el objetivo.
| Nombre | Tipo | Prioridad | Objetivo | Parámetros | TTL en segundos |
|---|
| apex.ejemplo.com | SVCB | 0 | cdn.ejemplo.net. | (ningún parámetro) | 3600 |
Este modo sirve de puente. Evita usar un CNAME donde no es deseado.
| Nombre del parámetro | Función |
|---|
| alpn | Anuncia los protocolos soportados 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
Para la web privilegiar un registro HTTPS. Sigue las mismas reglas que SVCB y agrega campos útiles a los navegadores.
En un nombre de servicio dedicado como _imap._tcp o _smtp._tcp cuando el protocolo lo prevé.
En el apex en modo alias si se debe dirigir a otro nombre evitando un CNAME.
SVCB puede coexistir con A y AAAA. Los clientes que no entienden SVCB utilizan las direcciones clásicas.
A evitar
Encadenar objetivos sin razón. Ir a lo esencial.
Publicar parámetros incoherentes con el servicio real.
Olvidar A o AAAA en el objetivo cuando el cliente debe dirigirse allí.
Una búsqueda DNS en línea permite introducir un nombre de dominio. 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=svcb
ejemplo.com
nslookup
set q=svcb
server 1.1.1.1
ejemplo.com
La primera parte consulta 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 SVCB ejemplo.com
dig SVCB ejemplo.com @1.1.1.1
Una prioridad a cero indica un alias. Un valor superior a cero indica un servicio con parámetros.
La presencia de alpn guía la elección del protocolo. Los campos ipv4hint e ipv6hint son solo indicios.
Un TTL restante elevado puede explicar un desfase después de un cambio.
- Definir la necesidad. Alias hacia un objetivo o publicación de parámetros.
- Reducir el TTL a 300 o incluso 60 segundos algunas horas antes de la implementación.
- Publicar el SVCB con la prioridad 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 un SVCB en _api._tcp para anunciar alpn y port. La aplicación sabe cómo conectarse.
Usar el modo alias para dirigirse al nombre proporcionado por el servicio. Mantener A y AAAA en el objetivo.
En un sitio web publicar un registro HTTPS dedicado con alpn h3. Agregar ech si el servicio lo proporciona.
- Si los clientes ignoran SVCB verificar que A y AAAA existan en el objetivo.
- Si se elige el protocolo incorrecto verificar alpn.
- 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 SVCB describe un servicio y puede servir como alias controlado. Los parámetros guían al cliente sin reemplazar A y AAAA. 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 servicio sin incidentes.