Todos los dominios, para funcionar, necesitas las DNS (Domain Name Server) que permiten informar de a qué dirección IP corresponde cada uno de los servicios que puede ofrecer un dominio.
Si utilizas las DNS de tu proveedor de alojamiento web (que habitualmente tiene su propio panel de control o usa cPanel, Plesk o similar) ya se encargará de crearlo todo… pero no está de más entender qué hacen.
Elegir el proveedor
Al igual que tenemos la empresa donde registramos un dominio, la empresa que nos gestiona las DNS puede ser la misma o distinta. Existen algunos proveedores gratuitos que pueden ser útiles si no dispones de este servicio.
- 1984: Aunque se centran en dar alojamiento, tienen su servicio de Free DNS para cualquier usuario.
- BuddyNS: Aunque sólo ofrecen 300K peticiones/mes, es más que suficiente y tienen una buena infraestructura distribuida.
- ClouDNS: Aunque la versión gratuita no es muy amplia, no deja de ser otra opción distribuida importante y conocida.
- Cloudflare: Ofrecen varios servicios y parece que ahora mismo tienen cerca del 40% de la gestión de DNS del mundo.
- FreeDNS: Es de estos servicios que la comunidad pone a disposición de todo el mundo, siempre actualizado y a la última.
- Geoscaling: Lo interesante de este servicio es que permite distribuir las entradas dependiendo del punto de origen del usuario. Si un usuario está en América, lo mandas a un servidor en US, si está en Europa, a uno en DE…
- Hurricane Electric Free DNS: Personalmente el que más me gusta y uno de los que utilizo. Es visualmente feo, pero funcional y si sabes de DNS te deja hacer prácticamente de todo. Además acaban de añadir soporte a las CAA y tienen servicio dinámico. Ofrecen 50 entradas gratuitas.
- Namecheap FreeDNS: Aunque se centran en registrar dominios, puedes usar sus servicios de DNS de forma gratuita aunque el dominio no esté con ellos.
- NS1: Tiene buena pinta, y su servicio de pago parece muy interesante. Ofrecen 50 entradas gratuitas con 500K consultas gratuitas.
- Rackspace: Tienen el servicio simplemente gratis por darte de alta con ellos. Usan el estándar de BIND9 en modo Anycast.
Configurando el dominio
Cuando te das de alta en cualquier proveedor (ya sea tu hosting, o cualquier proveedor como los anteriores) te tendrán que dar, al menos, dos servidores de nombres NS. Son los famosos ns1.example.com
y ns2.example.com
, que en realidad pueden ser cualquier hostname. Te pueden llegar a dar hasta 5 de ellos.
Estos NS son los que has de configurar en tu dominio (o subdominio delegado). A partir de ese momento, cuando alguien haga una llamada a tu dominio, se resolverán las peticiones según estén configurados en el proveedor.
En este momento, el fichero de DNS será parecido a esto:
example.com. SOA 86400 ns1.example.net. dnsmaster.example.net. 2019073102 86400 7200 3600000 86400
example.com. NS 86400 ns1.example.net
example.com. NS 86400 ns2.example.net
Las entradas SOA las genera el sistema, y las entradas NS serán las mismas que tendrás que poner en tu dominio.
¿Qué necesita mi WordPress?
Vamos a plantear que usaremos nuestro WordPress en el sitio www.example.com
. También queremos que el example.com
redirija al sitio.
Esto sería lo mínimo necesario para hacer que nuestro sitio web funcione, por lo que deberemos crear entradas de tipo A (y AAAA).
example.com. A 3600 198.51.100.20
www.example.com. A 3600 198.51.100.20
En caso de que tu proveedor también te ofrezca IPv6, podrías añadir una dirección con AAAA:
example.com. AAAA 3600 2001:db8::20
www.example.com. AAAA 3600 2001:db8::20
Mi proveedor pone CNAME en el www
El CNAME es un sistema de alias. Esto significa que si haces algo como esto:
example.com. A 3600 198.51.100.20
www.example.com. CNAME 3600 example.com
Lo que estás haciendo es que, cuando se haga una llamada al www
, el sistema devuelva que la IP es un alias del example.com
; posteriormente, se deberá hacer una llamada al example.com para conseguir la dirección IP. Esto significa que para saber la IP del www
tendrás que hacer dos peticiones DNS en vez de una, y eso significa tiempo, y eso significa que Core Web Vitals dará peores resultados.
Tu dominio siempre debería tener una entrada A
Otra de las reglas de oro, aunque ha evolucionado, pero en el que muchos servicios de validación se basan, por ejemplo, los servicios de correo, es que el dominio (sin subdominios) tenga una entrada A que resuelva a una dirección IP. Esto, indirectamente, indica que el dominio es funcional. También, por otro lado, un dominio sólo puede tener entradas A y no CNAME. ¿Por qué? Cosas de los estándares de Internet.
¿Puedo necesitar más DNS para WordPress?
En principio con esto tendrías suficiente. Eso sí, a partir de aquí se abre un mundo de posibilidades.
Validación en herramientas de Webmasters
Una de las mejores formas de validar Google Search Console, Bing Webmasters o Yandex Webmasters. En estos casos suelen darte dos opciones de validación. Una es mediante un TXT, y otra es mediante un CNAME.
Por ejemplo, Google te pedirá que crees una entrada similar a esto:
example.com. TXT 86400 google-site-verification=VACXsfhn2ZMUB9QS2BpPtNqHYLN9qrAUaxyW
En el caso de Bing, te pedirá un CNAME de un subdominio.
xnqzj8ky2j2xnf2nxxmn29a5.example.com. CNAME 86400 verify.bing.com
Y Yandex te pedirá algo similar al de Google:
example.com. TXT 86400 yandex-verification: 4g7ye3mxtqyfrf62
Las entradas CNAME de Bing lo que hará es que si haces una llamada a ese subdominio que te dan, resuelva una IP de Bing.
Las entradas de tipo TXT, como se puede intuir, son entradas de texto. Son campos libres de entre 1 y 255 caracteres que, habitualmente comienzan con una palabra clave tipo google-site-verification
o yandex-verification
, y que después indican un contenido único.
Quiero correo electrónico
Las entradas DNS sobre el correo electrónico te las tendrá que dar tu proveedor de correo. Si usas hosting compartido suelen venir ya configuradas. Si usas un servicio como Google Workspace o similar, ellos te dirán que entradas DNS deberás añadir.
Recibir correo
Aún así, hay unos elementos muy básicos para que funcione el correo. Lo mínimo es tener una o varias entradas de tipo MX. Vamos a usar de ejemplo las que te pide poner Google.
example.com. MX 10 86400 aspmx.l.google.com
example.com. MX 20 86400 alt1.aspmx.l.google.com
example.com. MX 20 86400 alt2.aspmx.l.google.com
Con estas entradas le estamos diciendo a quien nos quiera enviar un correo que el buzón de entrada está en los servidores de Google.
Validar quién envía mi correo
Con esto sería suficiente pero… ¿Verdad que no queremos spam ni phishing? Pues haciendo unas cuantas mejoras podemos conseguir reducir esto.
La primera de las formas es mediante los SPF. Estas entradas avisan de qué y quién puede mandar correos. Qué máquinas pueden hacerlo. Por norma general quien manda correo en nuestro nombre va a ser 2 lugares. El primero de ellos es Gmail, porque es donde vamos a recibir el correo. El segundo es nuestro propio WordPress, que de tanto en tanto nos manda mensajes a nosotros o a los usuarios.
example.com. TXT 86400 v=spf1 ip4:198.51.100.20 include:_spf.google.com -all
En este caso vamos a indicarle que se mandarán correos desde la IP en la que tenemos nuestra web (ip4:198.51.100.20
) o desde alguna de las decenas de IP desde las que manda Google. En este caso delegamos en Google la gestión con un sistema de inclusión (include:_spf.google.com
). En este subdominio ellos incluyen su lista de IP.
Con esto haremos que, quien reciba un correo desde una IP que no sea una de las válidas, reciba un mensaje de que ese correo puede ser sospechoso, es decir, que no lo ha sido mandado desde un lugar válido.
Cifrar mi correo
Otro de los problemas que puede haber con el correo es que alguien lo intercepte y lo modifique. Y como no queremos que eso ocurra, vamos a cifrarlo de alguna manera para que, quien reciba el correo pueda validar que no ha sido manipulado. Esto lo conseguimos mediante los DKIM.
Los proveedores de correo suelen generar una clave o te permite en algún lugar generarla. Siguiendo con el caso de Google, en el panel de gestión nos permite generar una clave, que será similar a esto.
google._domainkey.example.com. 86400 TXT v=DKIM1; k=rsa; p=MIIBIjApp7LacTh6CG8nEjjpQIDAQAB;
Si alguien modifica un mensaje, quien reciba el mensaje podría recibir un aviso de que ese mensaje ha podido ser manipulado.
Forzar a que se validen los protocolos
Aunque la mayoría de sistemas ya usan el SPF y el DKIM, suelen simplemente avisar de los problemas, pero no los fuerzan al máximo. Para esto tenemos el DMARC, que es quien fuerza las políticas a decidir.
Si queremos que se cumplan las reglas al 100%, podemos añadir este elemento a las DNS.
_dmarc.example.com. TXT 86400 v=DMARC1; p=reject; pct=100; aspf=s; adkim=s;
Con esto le estamos diciendo que rechace los correos que no cumplan (p=reject
), que revise el 100% del correo (pct=100
), que revise de forma estricta el SPF (aspf=s
), y que revise de forma estricta el DKIM (adkim=s
).
Mi logo en el correo
En algunos servicios, como Gmail, en algunas cuentas de correo se puede ver la foto de la persona que te lo envía. Pero no siempre el correo es un usuario de Gmail, o simplemente el correo no es una persona. Para estos casos en los que queremos configurar una imagen por defecto, tenemos el BIMI.
default._bimi.example.com. TXT 86400 v=BIMI1; l=https://www.example.com/imagen.svg; a=self;
Hay que tener en cuenta que el sistema de BIMI sólo soporta imágenes en formato SVG.
Validar mi certificado TLS de Let’s Encrypt
Hay muchas maneras de validar un certificado TLS (que permite el cifrado para el HTTPS), pero si queremos conseguir un nivel más alto de seguridad, una forma de hacerlo en configurando las DNS.
Cada proveedor tiene una manera propia de hacerlo, pero si has de crearlos manualmente, esta sería la forma óptima.
Lo primero es configurar, en este caso, que sólo puede generar certificados Let’s Encrypt y ningún otro sistema de certificados.
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 iodef "mailto:email@example.com"
En el primero de los elementos le decimos que el que puede generar certificados el Let’s Encrypt. En el segundo de los casos le indicamos a qué cuenta de correo nos pueden llegar avisos en caso de que el certificado tenga problemas o esté a punto de caducar.
Lo siguiente que nos puede pedir el sistema, es que incluyamos un identificador para validar que nosotros somos los propietarios del dominio, y por tanto el sistema pueda generar un certificado válido.
_acme-challenge.example.com. TXT 86400 hyuLQzJZACnXrW7Cu8DdKLQUS8V78YmBwXg6
Resolución inversa
Para acabar, y en caso de que tú seas el propietario (que la IP sea dedicada tuya) de una IP, deberías configurar la resolución inversa. En este caso, lo que hacemos es validar que la IP puede resolver y es válida. Siguiendo con la IP que hemos configurado al principio, lo habitual sería tener algo como esto.
Esta entrada DNS no la has de poner en tu dominio, sino que lo has de pedir a tu proveedor, ya que él, al ser el propietario de la IP, es el que ha de configurar la resolución.
20.100.51.198.in-addr.arpa. PTR 86400 server.example.com.
Sí, hay más entradas DNS
Existen muchos más tipos de entradas para las DNS, aunque ya no suelen ser tan habituales para un sitio web. Aún así, siempre puedes darle un vistazo a los distintos Tipos de registros DNS.
Sobre este documento
Este documento está regulado por la licencia EUPL v1.2, publicado en WP SysAdmin y creado por Javier Casares. Por favor, si utilizas este contenido en tu sitio web, tu presentación o cualquier material que distribuyas, recuerda hacer una mención a este sitio o a su autor, y teniendo que poner el material que crees bajo licencia EUPL.