Tipos de registro compatibles
NexDNS admite 14 tipos de registros DNS. Todos los tipos excepto SOA pueden ser creados y editados por los usuarios. Los registros SOA son gestionados automáticamente por el sistema cuando se crea una zona.
| Tipo | Propósito | Creado por usuario |
|---|---|---|
A | Asigna un nombre a una dirección IPv4 | Sí |
AAAA | Asigna un nombre a una dirección IPv6 | Sí |
CNAME | Crea un alias hacia otro nombre de host | Sí |
MX | Enruta el correo a un servidor de correo | Sí |
TXT | Almacena texto arbitrario (SPF, DKIM, verificación, etc.) | Sí |
NS | Delega un subdominio a otros servidores de nombres | Solo subdominios (NS del ápice gestionado por el sistema) |
SRV | Localiza un servicio (host + puerto) | Sí |
CAA | Controla qué CAs pueden emitir certificados | Sí |
PTR | DNS inverso – asigna una IP a un nombre de host | Sí |
ALIAS | Como CNAME pero permitido en el ápice de la zona | Sí |
DNAME | Redirige un subárbol DNS completo a otro dominio | Sí |
DS | Firmante de delegación DNSSEC – vincula zona hija con padre | Sí |
TLSA | Asocia un certificado TLS con un dominio (DANE) | Sí |
SOA | Start of Authority – metadatos de zona (serial, refresh, retry, etc.) | Gestionado por el sistema (solo lectura) |
Campos comunes
Cada registro DNS tiene los siguientes campos comunes además de sus campos específicos de tipo.
Nombre
El nombre del registro (nombre de host). Usa @ o deja vacío para referirte al ápice de la zona (p. ej., example.com en sí). Introduce un subdominio como www para crear www.example.com. Se agrega automáticamente un punto final.
Tipo
El tipo de registro. Una vez creado un registro, el tipo no puede cambiarse – necesitas eliminar y recrear el registro.
TTL (tiempo de vida)
Cuánto tiempo (en segundos) los resolvers deben almacenar en caché este registro. El valor predeterminado es 3600 (1 hora). Rango válido: 0 a 2,147,483,647. Hay preajustes rápidos disponibles en el panel: 5 minutos (300), 1 hora (3600) y 1 día (86400).
Registro A
Un registro A asigna un nombre de dominio a una dirección IPv4. Es el tipo de registro más común – indica a los navegadores y otros clientes a qué servidor conectarse.
Campos
| Campo | Descripción | Validación |
|---|---|---|
address |
La dirección IPv4 a la que debe resolver este nombre. | Debe ser una dirección IPv4 válida (p. ej., 203.0.113.50) |
Ejemplo
| Nombre | TTL | Tipo | Valor |
|---|---|---|---|
| @ | 3600 | A | 203.0.113.50 |
| www | 3600 | A | 203.0.113.50 |
Registro AAAA
Un registro AAAA asigna un nombre de dominio a una dirección IPv6. Funciona de manera idéntica a un registro A pero para redes IPv6.
Campos
| Campo | Descripción | Validación |
|---|---|---|
address |
La dirección IPv6 a la que debe resolver este nombre. | Debe ser una dirección IPv6 válida (p. ej., 2001:db8::1) |
Ejemplo
| Nombre | TTL | Tipo | Valor |
|---|---|---|---|
| @ | 3600 | AAAA | 2001:db8::1 |
Registro CNAME
Un registro CNAME (Nombre Canónico) crea un alias de un nombre a otro. Cuando un resolver busca un CNAME, sigue el alias y devuelve los registros del destino en su lugar.
Restricciones
- Los registros CNAME no pueden crearse en el ápice de la zona (@). Usa un registro ALIAS en su lugar para alias en el ápice.
- Según RFC 1035, un CNAME no puede coexistir con ningún otro tipo de registro en el mismo nombre. Si tienes un registro A en www, no puedes añadir un CNAME en www – y viceversa.
Campos
| Campo | Descripción | Validación |
|---|---|---|
hostname |
El nombre de host de destino al que apunta este alias. | Nombre de host válido (alfanumérico y guiones, máximo 253 caracteres en total, etiquetas de 1 a 63 caracteres cada una) |
Ejemplo
| Nombre | TTL | Tipo | Valor |
|---|---|---|---|
| www | 3600 | CNAME | example.com. |
| blog | 3600 | CNAME | mysite.hosting.com. |
Registro MX
Un registro MX (Mail Exchange) especifica qué servidor de correo es responsable de aceptar correo en nombre del dominio. Múltiples registros MX con diferentes prioridades proporcionan conmutación por error.
Campos
| Campo | Descripción | Validación |
|---|---|---|
priority |
Determina el orden en que se intentan los servidores de correo. Los valores más bajos se intentan primero. | Entero, 0-65535 |
host |
El nombre de host del servidor de correo. | Nombre de host válido, o . (punto) para un Null MX con prioridad 0 (RFC 7505) |
Ejemplo
| Nombre | TTL | Tipo | Valor |
|---|---|---|---|
| @ | 3600 | MX | 10 mail.example.com. |
| @ | 3600 | MX | 20 mail2.example.com. |
Un Null MX (host establecido en . con prioridad 0) indica que el dominio no acepta correo electrónico, según RFC 7505.
Registro TXT
Un registro TXT almacena datos de texto arbitrarios. Se usa comúnmente para autenticación de correo electrónico (SPF, DKIM, DMARC), verificación de propiedad de dominio y otros metadatos.
Campos
| Campo | Descripción | Validación |
|---|---|---|
value |
El contenido de texto del registro. | No debe estar vacío. El entrecomillado se maneja automáticamente – no necesitas añadir comillas dobles al inicio y final. |
Ejemplo
| Nombre | TTL | Tipo | Valor |
|---|---|---|---|
| @ | 3600 | TXT | "v=spf1 include:_spf.google.com ~all" |
| _dmarc | 3600 | TXT | "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com" |
El sistema envuelve automáticamente los valores TXT en comillas dobles para el almacenamiento DNS. Si tu valor ya está entrecomillado, no se entrecomillará doble.
Registro NS
Un registro NS (Name Server) delega un subdominio a un conjunto diferente de servidores de nombres. Se usa cuando un subdominio es gestionado por un proveedor DNS diferente.
Restricción
Los registros NS en el ápice de la zona son creados y gestionados automáticamente por el sistema según tu Grupo de Servidores NS. Solo puedes crear registros NS para subdominios.
Campos
| Campo | Descripción | Validación |
|---|---|---|
hostname |
El nombre de host del servidor de nombres para esta delegación. | Nombre de host válido (alfanumérico y guiones, máximo 253 caracteres en total, etiquetas de 1 a 63 caracteres cada una) |
Ejemplo
| Nombre | TTL | Tipo | Valor |
|---|---|---|---|
| subdomain | 86400 | NS | ns1.other-provider.com. |
Registro SRV
Un registro SRV (Servicio) especifica la ubicación (nombre de host y puerto) de un servicio particular. Es usado por aplicaciones como SIP, XMPP y servidores de juegos para descubrir servicios.
Campos
| Campo | Descripción | Validación |
|---|---|---|
priority |
Orden en que se intentan los servidores (menor = primero). | Entero, 0-65535 |
weight |
Peso relativo para balanceo de carga entre registros con la misma prioridad. | Entero, 0-65535 |
port |
El número de puerto TCP o UDP del servicio. | Entero, 0-65535 |
target |
El nombre de host de la máquina que proporciona el servicio. | Nombre de host válido, o . (punto) para indicar que el servicio no está disponible |
Ejemplo
| Nombre | TTL | Tipo | Valor |
|---|---|---|---|
| _sip._tcp | 3600 | SRV | 10 60 5060 sip.example.com. |
| _minecraft._tcp | 3600 | SRV | 0 5 25565 mc.example.com. |
El nombre del registro para registros SRV debe seguir la convención _servicio._protocolo (p. ej., _sip._tcp, _minecraft._tcp, _ldap._tcp).
Registro CAA
Un registro CAA (Certificate Authority Authorization) especifica qué Autoridades de Certificación (CAs) tienen permitido emitir certificados SSL/TLS para el dominio. Esto previene la emisión no autorizada de certificados.
Campos
| Campo | Descripción | Validación |
|---|---|---|
flags |
Normalmente 0. Establece en 128 para marcar esta propiedad como crítica (la CA debe entenderla o rechazar la emisión). | Entero, 0-255 |
tag |
El tipo de propiedad. | Debe ser uno de: issue, issuewild o iodef |
value |
El nombre de dominio de la CA (para issue/issuewild) o una URL de reporte (para iodef). | No debe estar vacío |
Ejemplo
| Nombre | TTL | Tipo | Valor |
|---|---|---|---|
| @ | 3600 | CAA | 0 issue "letsencrypt.org" |
| @ | 3600 | CAA | 0 issuewild ";" |
| @ | 3600 | CAA | 0 iodef "mailto:security@example.com" |
Registro PTR
Un registro PTR (Pointer) asigna una dirección IP de vuelta a un nombre de host. Se usa para búsquedas DNS inversas – por ejemplo, verificar que la dirección IP de un servidor resuelva a su nombre de host declarado.
Campos
| Campo | Descripción | Validación |
|---|---|---|
hostname |
El nombre de host directo al que esta dirección IP debe resolver. | Nombre de host válido (alfanumérico y guiones, máximo 253 caracteres en total, etiquetas de 1 a 63 caracteres cada una) |
Ejemplo
| Nombre | TTL | Tipo | Valor |
|---|---|---|---|
| 50 | 3600 | PTR | server.example.com. |
Registro ALIAS
Un registro ALIAS funciona como un CNAME pero puede usarse en el ápice de la zona (@). El servidor DNS resuelve el destino internamente y devuelve los registros A/AAAA resultantes. Usa ALIAS cuando necesites alias a nivel de ápice (p. ej., apuntar example.com a un nombre de host de balanceador de carga).
Campos
| Campo | Descripción | Validación |
|---|---|---|
hostname |
El nombre de host de destino para resolver y devolver registros. | Nombre de host válido (alfanumérico y guiones, máximo 253 caracteres en total, etiquetas de 1 a 63 caracteres cada una) |
Ejemplo
| Nombre | TTL | Tipo | Valor |
|---|---|---|---|
| @ | 3600 | ALIAS | myapp.herokuapp.com. |
Registro DNAME
Un registro DNAME redirige un subárbol completo del espacio de nombres DNS a otro dominio. A diferencia de CNAME (que crea alias de un solo nombre), DNAME crea alias de todos los nombres bajo el nodo especificado. Útil para migraciones de dominio y reestructuración organizacional.
Campos
| Campo | Descripción | Validación |
|---|---|---|
hostname |
El dominio de destino al que este subárbol debe ser mapeado. | Nombre de host válido (alfanumérico y guiones, máximo 253 caracteres en total, etiquetas de 1 a 63 caracteres cada una) |
Ejemplo
| Nombre | TTL | Tipo | Valor |
|---|---|---|---|
| legacy | 3600 | DNAME | new-domain.com. |
Registro DS
Un registro DS (Delegation Signer) se usa en DNSSEC para vincular una zona hija con su zona padre. Contiene un hash del registro DNSKEY de la zona hija, estableciendo una cadena de confianza.
Campos
| Campo | Descripción | Validación |
|---|---|---|
keytag |
Un identificador numérico que ayuda a los resolvers a encontrar el registro DNSKEY correspondiente rápidamente. | Entero, 0-65535 |
algorithm |
El número de algoritmo de firma DNSSEC (p. ej., 8 para RSA/SHA-256, 13 para ECDSA P-256). | Entero, 0-255 |
digest_type |
El algoritmo de hash usado para crear el digest (p. ej., 2 para SHA-256). | Entero, 0-255 |
digest |
El hash hexadecimal del registro DNSKEY de la zona hija. | No debe estar vacío (cadena hexadecimal) |
Ejemplo
| Nombre | TTL | Tipo | Valor |
|---|---|---|---|
| @ | 3600 | DS | 12345 8 2 49FD46E6C4B45C55D4AC69CBD...A9BE1B |
Registro TLSA
Un registro TLSA asocia un certificado o clave pública TLS/SSL con un nombre de dominio, habilitando la Autenticación de Entidades Nombradas basada en DNS (DANE). Permite a los clientes verificar certificados TLS sin depender únicamente de las CAs.
Campos
| Campo | Descripción | Validación |
|---|---|---|
usage |
Cómo verificar el certificado. | Entero, 0-3 (0 = restricción de CA, 1 = certificado de servicio, 2 = ancla de confianza, 3 = emitido por dominio) |
selector |
Qué parte del certificado comparar. | Entero, 0-1 (0 = certificado completo, 1 = solo clave pública) |
matching_type |
Cómo comparar los datos del certificado. | Entero, 0-2 (0 = coincidencia exacta, 1 = hash SHA-256, 2 = hash SHA-512) |
certificate |
Los datos del certificado o su hash en hexadecimal. | No debe estar vacío |
Ejemplo
| Nombre | TTL | Tipo | Valor |
|---|---|---|---|
| _443._tcp | 3600 | TLSA | 3 1 1 2BB183AF2B...9FA0925A |
Registro SOA
El registro SOA (Start of Authority) contiene información administrativa sobre la zona, incluyendo el servidor de nombres primario, el correo electrónico del responsable, el número de serie de la zona y los parámetros de tiempo para transferencias de zona.
Información
Los registros SOA se crean y gestionan automáticamente cuando se crea una zona. No pueden ser creados, editados ni eliminados por los usuarios. El número de serie se incrementa automáticamente cada vez que cambian los registros de la zona.
Ejemplo
ns1.nexdns.tech. hostmaster.example.com. 2024010101 10800 3600 604800 3600Configuraciones DNS comunes
Apuntar un dominio a un servidor web
Para apuntar tu dominio a un servidor web, crea registros A y AAAA para el dominio raíz, y opcionalmente un CNAME para el subdominio www.
Registros recomendados
| Nombre | Tipo | Valor | Propósito |
|---|---|---|---|
| @ | A | 203.0.113.50 | Dominio raíz vía IPv4 |
| @ | AAAA | 2001:db8::1 | Dominio raíz vía IPv6 |
| www | CNAME | example.com. | www redirige al raíz |
Si tu proveedor de hosting te proporciona un nombre de host en lugar de una dirección IP (p. ej., myapp.herokuapp.com), no puedes usar un CNAME en el ápice. Usa un registro ALIAS en @ en su lugar.
Configurar el correo electrónico
Una configuración completa de correo electrónico requiere registros MX (enrutamiento de correo) más registros TXT para autenticación (SPF, DKIM, DMARC). Tu proveedor de correo te proporcionará los valores exactos.
Registros MX (enrutamiento de correo)
| Nombre | Tipo | Valor |
|---|---|---|
| @ | MX | 10 mail.example.com. |
| @ | MX | 20 mail-backup.example.com. |
SPF (Sender Policy Framework)
SPF define qué servidores tienen permitido enviar correo en nombre de tu dominio. Es un registro TXT en el ápice de la zona.
| Nombre | Tipo | Valor |
|---|---|---|
| @ | TXT | "v=spf1 mx a include:_spf.google.com ~all" |
DKIM (DomainKeys Identified Mail)
DKIM agrega una firma digital a los correos salientes. La clave pública se publica como un registro TXT. Tu proveedor de correo te proporcionará el nombre y valor exactos.
| Nombre | Tipo | Valor |
|---|---|---|
| default._domainkey | TXT | "v=DKIM1; k=rsa; p=MIGfMA0GCS..." |
DMARC (autenticación de mensajes basada en dominio)
DMARC indica a los servidores de correo receptores qué hacer con los correos que no pasan las verificaciones SPF o DKIM. Es un registro TXT en _dmarc.
| Nombre | Tipo | Valor |
|---|---|---|
| _dmarc | TXT | "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com" |
Configurar subdominios
Crea subdominios agregando registros con el nombre del subdominio en el campo Nombre.
| Nombre | Tipo | Valor | Propósito |
|---|---|---|---|
| blog | CNAME | mysite.wordpress.com. | Alojado en plataforma externa |
| shop | A | 198.51.100.10 | Directo a dirección IP |
| api | CNAME | api-gateway.cloud.com. | Endpoint de servicio en la nube |
Verificación de certificado SSL
Las autoridades de certificación SSL/TLS frecuentemente requieren verificación de dominio basada en DNS. Te solicitarán crear un registro TXT o CNAME específico.
Verificación por TXT (p. ej., Let's Encrypt)
| Nombre | Tipo | Valor |
|---|---|---|
| _acme-challenge | TXT | "gfj9Xq...Rg85nM" |
Verificación por CNAME (p. ej., AWS ACM, DigiCert)
| Nombre | Tipo | Valor |
|---|---|---|
| _acme-challenge | CNAME | dcv.example-ca.com. |
Usa un TTL bajo (300 segundos) para registros de verificación para que se propaguen rápidamente. Puedes eliminarlos después de que se emita el certificado.
Solución de problemas
Retraso en la propagación DNS
Después de crear o cambiar un registro DNS, puede tomar tiempo que el cambio sea visible a nivel mundial. Esto se debe a que los resolvers DNS en todo el mundo almacenan en caché los registros según el valor TTL.
Para cambios urgentes, reduce el TTL a 300 segundos (5 minutos) antes de realizar el cambio, espera a que expire el TTL anterior, luego haz tu cambio. Puedes aumentar el TTL nuevamente después.
Entender el TTL
TTL (Tiempo de Vida) controla cuánto tiempo los resolvers DNS almacenan en caché un registro antes de consultar al servidor autoritativo nuevamente. Un TTL más bajo significa que los cambios se propagan más rápido pero aumenta la carga de consultas. Un TTL más alto reduce la carga pero hace que los cambios tarden más en tomar efecto.
| Valor TTL | Duración | Caso de uso |
|---|---|---|
300 | 5 minutos | Registros que cambian frecuentemente, pruebas, migraciones |
3600 | 1 hora | Predeterminado – buen equilibrio entre rendimiento y flexibilidad |
86400 | 1 día | Registros estables que rara vez cambian (MX, NS) |
NexDNS acepta valores TTL de 0 a 2,147,483,647 segundos. El valor predeterminado para nuevos registros es 3600 (1 hora).
Conflictos de CNAME
Los registros CNAME tienen reglas estrictas definidas por RFC 1035 que NexDNS aplica automáticamente:
- Un CNAME no puede crearse en el ápice de la zona (@). El sistema rechazará esto con un error. Usa un registro ALIAS en su lugar.
- Un CNAME no puede coexistir con ningún otro registro en el mismo nombre. Si ya tienes un registro A o TXT en www, no puedes añadir un CNAME en www hasta que elimines los registros existentes.
- Si necesitas un comportamiento similar a CNAME en el ápice, usa un registro ALIAS. Se resuelve del lado del servidor y devuelve registros A/AAAA de forma transparente.
No se pueden crear registros NS en el ápice de la zona
Los registros NS en el ápice de la zona (@ o el dominio base) son gestionados automáticamente por el sistema según tu Grupo de Servidores NS. Solo puedes crear registros NS para subdominios – esto se usa para delegar un subdominio a un proveedor DNS diferente.
Límite de registros alcanzado
Cada plan de suscripción tiene un número máximo de registros por zona. Si recibes un error de cuota, has alcanzado este límite. Puedes actualizar tu plan para un límite mayor, o eliminar registros no utilizados. Incluso los planes ilimitados tienen un límite máximo de 10,000 registros por zona.
Errores de validación de nombre de host
Los nombres de host utilizados en registros CNAME, NS, PTR, ALIAS, DNAME, MX y SRV deben cumplir con los estándares DNS:
- Longitud total máxima de 253 caracteres (excluyendo el punto final).
- Cada etiqueta (parte entre puntos) debe tener de 1 a 63 caracteres de longitud.
- Las etiquetas deben comenzar y terminar con un carácter alfanumérico (a-z, 0-9).
- Las etiquetas solo pueden contener caracteres alfanuméricos y guiones (-).