El sistema de nombres de dominio (DNS) juega un papel importante en Internet. Convierte nombres canónicos en direcciones IP y es vital en el enrutamiento del tráfico en la red. La resolución de DNS es un tema muy extenso y no podrá tratarse por completo en este artículo. En su lugar, mencionaré los pasos más importantes para hacer que un sitio web funcione desde un servidor en el que ha comprado una cuenta de alojamiento.

Resolución de DNS

Necesita registrar un sitio web como newdomain.com, nuevo dominio.org, nuevo dominio.biz, nuevo dominio.hosting, etc. Hoy en día hay muchos TLD nuevos como .trabaja, .alojamiento, etc. de cualquiera de los registradores de dominios. Los más comunes son como Godday.com, dominio.com, NameCheap.com, Bluehost.com
Una vez que compre el nombre de dominio del registrador anterior, ahora necesitamos encontrar una cuenta de alojamiento (puede ser un alojamiento compartido / alojamiento de revendedor o un servidor VPS / dedicado) . Si tiene una cuenta compartida / de revendedor, en su mayoría nos proporcionarán un par de servidores de nombres que deben usarse para apuntar el dominio a sus servidores. SI está comprando un vps / servidores dedicados, entonces es posible que tengamos que configurar el servidor con un servidor DNS para el que usamos principalmente paquetes con nombre o Bind.
Si está utilizando los servidores de nombres del registrador, debe crear todos los registros dns manualmente en ese panel. Si está utilizando un alojamiento compartido cpanel / plesk, la mayoría de ellos tendrán todos los registros dns creados al crear la cuenta y solo necesita apuntar los servidores de nombres del proveedor de alojamiento en el extremo del registrador.
Una vez apuntado, puede llevar entre 24 y 72 horas que los cambios se propaguen por Internet.

Comprensión de los registros DNS

Los registros DNS son configuraciones que nos ayudan a apuntar un dominio y su variedad de servicios a esos servidores o direcciones IP adecuados. Los registros dns actúan como un instructor, como si el dominio apuntara a esa ip, ese subdominio apuntara a otra ip, etc. Sin los registros DNS adecuados, los humanos tendrán que recordar la dirección IP y recordar una dirección IP será una tarea tediosa y así es como entra en juego la importancia del DNS.

No tenemos que recordar una dirección IP, ya que siempre será un problema para los humanos usar la dirección IP para ir al sitio web. Es por eso que registramos el nombre de dominio y usamos dns para que apunte correctamente al servidor de alojamiento. Antes de que se crearan los servidores o paquetes DNS, uno tendrá que escribir la dirección IP en el navegador y recordar la misma también. Con la introducción de IPV6 es literalmente imposible recordar la dirección IP incluso para aquellos que tienen la mejor capacidad de memoria.

Hay más de 70 registros dns y puede leer el enlace a continuación para ver todos los registros DNS posibles y sus detalles

https: // www.iana.org / assignments / dns-parameters / dns-parameters.xml

Estoy discutiendo los registros a continuación que son más necesarios para que un lego obtenga su sitio alojado y su correo electrónico fluya sin problemas.

Registro SOA
Valor TTL
Un registro
Registro AAAA
Registro NS
Registro MX
Registro TXT
Registro SPF
Registro DKIM
Registro DMARC
Registro PTR
Registro CNAME
Registro SRV
Registro de RP
Registro DNSKEYs

1. Registro SOA (INICIO DE AUTORIDAD)

El registro SOA es el registro más importante y, sin embargo, no tan popular. Es un registro obligatorio para que un archivo de zona DNS funcione y nos dé resultados. Este registro en particular tendrá el nombre de la zona, la dirección de correo electrónico de la persona responsable que maneja el archivo de zona del dominio, el número de serie actual, el servidor de nombres principal o primario para la zona y algunos elementos de tiempo que se miden y se muestran en segundos.

A continuación se muestra un ejemplo de registro SOA

dominio.com. 86400 EN SOA ns1.dominio.com. correo electrónico.dominio.com. (
2017100505; Número de serie
3600; actualizar
7200; reintentar
1209600; expirar
86400)
El formato exacto para esto es el siguiente
@ IN SOA servidor de nombre primario correo electrónico del hostmaster (
número de serie
tiempo de actualización
tiempo de reintento
time-to-expire
mínimo-TTL)

Servidor de nombres primario: Muestra el servidor de nombres que contiene los registros dns originales.

Hostmaster-correo electrónico: Dirección de correo electrónico del propietario responsable del dominio. Un período "."Se utilizará reemplazando un símbolo @. Para direcciones de correo electrónico que tienen un "."Ya en eso se escapará con un" / ".

Número de serie : Es el número de versión de la Zona y seguirá aumentando con cada actualización del archivo de Zona.

Tiempo para actualizar: Este valor muestra el tiempo de espera para verificar la actualización del número de serie. Esto es principalmente necesario cuando tiene un clúster dns o dns secundario que necesita buscar una actualización en el archivo maestro y debe copiarse el último en los otros servidores del clúster. Solo se aplica a aquellos que tienen dns secundarios o configuración de clúster.

Tiempo para reintentar: Determina cuánto tiempo debe esperar un servidor de nombres para volver a intentar la actualización si el último intento falló.Solo se aplica a aquellos que tienen dns secundarios o configuración de clúster.

Tiempo de expiración: determina cuánto tiempo debemos esperar antes de considerar que los datos de los servidores de nombres secundarios o de otros clústeres no son válidos y dejar de responder a las consultas de la zona respectiva.

TTL mínimo: ¿Cuánto tiempo debe un servidor de nombres o resolutores almacenar en caché una respuesta negativa?.

2. Valor TTL (tiempo de vida)

El valor TTL es el tiempo en segundos que los registros dns serán almacenados en caché por un servidor dns externo o un servidor de nombres y, después de eso, debería actualizarlo y tener el último valor . La principal importancia de esto es mientras está planificando una migración y necesita cambios de dns sin ningún tiempo de inactividad de dns. Los cambios en los servidores de nombres siempre pueden causar tiempo de inactividad, ya que no tenemos control sobre ellos. Por lo tanto, antes de la migración, normalmente cambiamos el valor TTL a 300 segundos 1 - 2 días antes, de modo que, después de la migración, cambiaremos las direcciones IP del servidor de nombres en el extremo del registrador y también cambiaremos las direcciones IP de todos los archivos de zona en el servidor antiguo por nuevas direcciones IP. para que comience a resolverse en un nuevo servidor en ambos casos, es decir, si el dns llega al servidor anterior, entonces apuntará el dominio desde ese servidor al nuevo servidor y si se toman los servidores de nombres recién actualizados, entonces también comenzará a cargarse desde nuevo servidor.

Si no se menciona ningún valor ttl, este será el valor predeterminado principal para todos los registros dns a menos que tengamos otro valor especificado en los registros.

Entrada de muestra
$ TTL 14400

3. Un registro

Un registro también se conoce como registros de direcciones o registros de host. Esto se usa principalmente para apuntar el dominio / subdominio, etc.a la dirección IP del servidor. Un registro solo se resuelve en una dirección IP y no hay otros argumentos / variables en el registro A. Los registros A se utilizan solo para apuntar a una dirección IPV4.

Sample A Record es el siguiente
dominio.com. 14400 EN 192.168.1.1

También podemos usar un registro dns comodín que cargará todos los subdominios en una ip

*.dominio.com 14400 EN 192.168.1.1

4. Registro AAAA

El registro AAAA es el mismo que el anterior. El propósito y el uso de este registro son todos iguales. La única diferencia es que esto se usa para apuntar el dominio a una IP IPV6 y si el dominio también tiene una versión IPv6, entonces necesitamos tener este registro A también apuntado .

Ejemplo de registro AAAA es el siguiente

dominio.com 14400 EN AAAA 0133: 4237: 89bc: cddf: 0123: 4267: 89ab: cddf

5. Registro NS (servidor de nombres)

La situación ideal será que el servidor de nombres a nivel de registrador y el archivo de zona dns sean los mismos y los registros ns no coincidentes pueden causar algunos problemas con algunos ISP, pero normalmente esa discrepancia no es un problema. Por lo tanto, los registros del servidor de nombres primario deben estar allí tanto en el registro como en el archivo de zona dns en el servidor que se menciona en el registro.

Entrada de muestra
dominio.com. 86400 IN NS ns1.dominio principal.com.
dominio.com. 86400 IN NS ns2.dominio principal.com.

Cuando tenga los servidores de nombres para el mismo dominio, asegúrese de agregar registros A para estos servidores de nombres .En el ejemplo anterior, está usando algún otro servidor de nombres registrado como ns1.dominio principal.com. Pero si desea utilizar ns1.dominio.com en sí mismo como servidor de nombres en el registrador y el servidor, debe configurar los registros HOST en el registro (que es el registro GLUE) y debe agregar también los registros A a continuación

ns1 14400 EN A 192.168.1.1
ns2 14400 EN 192.168.1.1

6. Registro MX (Mail Exchange)

Este es otro registro dns importante que determina el destino de sus correos entrantes a un dominio. Cuando alguien envía un correo a una cuenta de correo electrónico bajo un dominio, el servidor remoto estará enviando correos al servidor que se menciona en los registros MX y al que tiene el valor más bajo en prioridad que de hecho tiene la prioridad más alta

Registros MX de muestra

dominio.com 14400 IN MX 10 mail_1.dominio.com
dominio.com 14400 IN MX 20 mail_2.dominio.com
dominio.com 14400 IN MX 30 mail_3.dominio.com

En este ejemplo, si mail_1.dominio.com está inactivo, el correo se entregará a mail_2.dominio.com. Si mail_2.ejemplo.com también está inactivo, el correo se entregará a mail_3.dominio.com.Esto se usa principalmente cuando tiene un dominio agregado en varios servidores y tiene correo configurado en esos. Pero esos correos se dispersarán en esos servidores y es posible que tenga que verificarlos manualmente.

Si está utilizando los registros MX que tienen el mismo nombre de dominio, debe agregar los registros dns A adecuados. Como el de abajo . Pero si está utilizando aplicaciones de Google, Outlook, etc., entonces no es necesario agregar un registro A adicional para aquellos, ya que no tiene el control sobre ellos y esos proveedores deben agregarlos.

mail_1 14400 EN A 192.168.1.1
mail_2 14400 IN A 192.168.1.2
mail_3 14400 IN A 192.168.1.3

7. Registro TXT (texto)

Un registro TXT o un registro de texto en realidad no tienen ningún papel en la funcionalidad de los dominios y generalmente se usa para mostrar información o para algunas verificaciones, como cuando se registra en las aplicaciones de Google o en el servicio de correo de Outlook, luego le pedirán que agregue un Registro TXT que piden (un código único) para que puedan verificar la propiedad del dominio. Los registros SPF / DKIM también se basan en TXT pero tienen una funcionalidad para realizar. Estos también se pueden usar como una opción para autenticar su propiedad mientras se agrega a la cuenta de webmaster de Google y también a otros servicios relacionados con Google.

A continuación se muestra una entrada de dns de muestra para la verificación de Google

dominio.com. 300 IN TXT verificación del sitio de Google = gBmnBtGTIz_esMKJBKT-PxLH50M

8. Registro SPF (marco de políticas del remitente)

El registro SPF es básicamente un registro TXT, que normalmente publica todos los servidores de correo designados para un dominio o subdominio. El uso principal de este registro es demostrar la legitimidad de los correos electrónicos y evitar correos falsificados. Un servidor de correo de destino puede rechazar correos si no son de los servidores de correo registrados o mencionados en base a este registro.

Entrada de muestra
dominio.com. EN TXT "v = spf1 + a + mx + ip4: 192.168.1.5 -todos "

Esto dice que este dominio enviará correos legítimos solo desde un registro A, servidores de registro MX y también desde ip 192.168.1.5 y todos los demás pueden ser rechazados . Con el registro SPF anterior, el servidor receptor comprobará todos los servidores y la dirección IP que se menciona en el SPF. Si la dirección IP coincide, se pasará la verificación, y si no, fallará (el mensaje se rechazará automáticamente) y si usamos "~ all", que es una falla suave, el mensaje se marcará como FAIL pero no rechazado.

Puede hacer referencia a más sytanx desde este enlace.

9. Registro DKIM (DomainKeys Identified Mail)

Este también es un registro TXT, que también es un protocolo de autenticación de correo electrónico que es un poco más complicado que SPF. Este registro se crea para un subdominio que tiene un selector único para la clave y luego tendrá un "."Al agregar un registro de este tipo, agregará una firma digital a los encabezados del mensaje de correo electrónico. Esta firma se valida utilizando la clave pública publicada del registro DKIM. Esto es un poco complicado y si está en cpanel, ofrecen una opción para hacerlo fácilmente usando la opción de habilitar con un clic.

Entrada de muestra
defecto._domainkey 14400 IN TXT "v = DKIM1; k = rsa;
p = MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmDb9e2q41oLc0ZDtSNo2Ik4khVMUMkv98N1Y0
FehUCcFUIUIUIUIUIuiuicfhdyeytrytrryuytytfyfyfytrytrytrtyrytrytrytrytrytdyBQ3XatuaEj
qGR0zfaY6RSU ++ gqGF8ZRpjJd + O3AcqRZT4ZT8d7Uhye6Ctgcv3kQEd5I2dTSpodIzWey8reysHJMdCvulRJYdP "
UWj5PrHfkwY7ec0ZNggTOpmlByXIPRx0Q / oBS9TLlAs785XJMNWjubyyjC6V5JUQ + tRyhwa28TWM / l6 / EIcYNBZE
fWx8oHQsBFLT0dNsRhq9ExX0UDMmbddD0zWoKtx + Wb7ItG0HPPVqne8jWkeXQIDAQAB \;

10. Registro DMARC

El registro DMARC funciona solo si hay registros adecuados de SPF y SKIM. Es una política de su proceso de autenticación de correo y cómo el servidor receptor debe manejar el correo si esto viola la política. Cuando un correo entrante llega al servidor remoto, consultará su registro DMARC y se asegurará de que consulten las siguientes preguntas

> ¿La firma DKIM de los correos entrantes es adecuada? ?
> ¿El mensaje proviene de un nombre de host de servidor / ip autorizado como se menciona en el registro SPF?.
> Si el encabezado de los correos entrantes tiene una alineación adecuada según el RFC 5322.

Entrada de muestra

_dmarc.dominio.com. IN TXT "v = DMARC1 \; p = ninguno \; rua = mailto: [correo electrónico protegido] \;
ruf = mailto: [correo electrónico protegido] \; pct = 100 "

_dmarc.dominio.com: Subdominio que está configurado para la autenticación de DMARC solo.

v = DMARC1: Versión Dmarc en uso.

p = ninguno: menciones sobre el tratamiento preferido de la póliza

rua =mailto: [correo electrónico protegido] : Los informes agregados se envían a este

ruf =mailto: [correo electrónico protegido] : Los informes forenses deben enviarse a esta cuenta de correo electrónico

pct = 100: Este es el porcentaje de correos en los que el propietario desea que el registro se verifique y se use para actualizaciones de políticas

DMARC / SPF / DKIM es todo necesario para una autenticación adecuada para los servicios de correo

11. Registro PTR (puntero)

Los registros PTR también se conocen como DNS inverso para la ip. Los registros PTR normalmente se configuran a nivel de proveedor de alojamiento o proveedor de servidor. Los registros PTR nos ayudan a hacer coincidir una dirección IP con un dominio o un subdominio (normalmente con un nombre de dominio completo FQDN) lo que ayudará a que las consultas DNS inversas funcionen correctamente.

Entonces, como requisito previo para configurar dns inversos para una ip, ahora los proveedores de hosting / servidor solicitan primero configurar un registro para el dominio / subdominio para esa IP y una vez hecho esto, el centro de datos configurará el RDNS (DNS inverso registro).

12.Registro CNAME (nombre canónico)

El registro CNAME ayuda a apuntar un dominio o subdominio a otro dominio o subdominio.

Entrada de muestra:
nuevo dominio.com 14400 EN dominio CNAME.com.
correo 14400 EN correo CNAME.dominio.com.

Ejemplo 1, apunta al nuevo dominio.com al dominio.com donde el segundo ejemplo apunta al correo.nuevo dominio.com al correo.dominio.com. Con estos registros, cuando llega una solicitud a newdomain.com, encontrará un registro CNAME en el dominio.com. Después de eso, comenzará una nueva búsqueda de dominio.com y enviará la solicitud al dominio.com y lo mismo ocurre con el segundo registro también.

13.Registro SRV (servicio)

El registro SRV nos ayuda a apuntar a un servicio particular que se está ejecutando en su dominio o subdominio a un dominio de destino. Esto nos ayuda a dirigir el tráfico de servicios particulares como el servidor de chat o los servicios de mensajería a otro servidor.

Entrada de muestra:

_sipfederationtls._tcp. 3600 IN SRV 100 1 5061 sipfed.en línea.Lync.com.
_Servicio._protocolo.ejemplo.com 3600 IN SRV 10 0 5060 servicio.ejemplo.com
_Servicio._proto.nombre. Objetivo de puerto de peso de prioridad SRV de clase TTL.

Servicio : El nombre de los servicios debe comenzar con un guión bajo "_" y será seguido por un ".”El servicio podría ser cualquier cosa como _chat, _xmpp, _sipfederationtls (que se utiliza para los servidores de intercambio de Microsoft), etc.

Protocolo:El nombre del protocolo también debe comenzar con un guión bajo y luego un "."En este caso es" _tcp."Y nos dice que es un protocolo TCP que está en uso.

Nombre : El nombre o el nombre de dominio es el dominio que recibirá el tráfico original de este servicio.

Prioridad: Es el primer número mencionado en los ejemplos anteriores (100 y 10 respectivamente) le ayuda a establecer la prioridad para el servidor de destino y un número más bajo significa una prioridad más alta. Esto es similar a la prioridad de registro MX y funciona de manera similar, ya que podemos configurar otro registro como respaldo también con otra prioridad.

Peso : Si creamos registros similares con la misma prioridad, entonces el factor decisivo será este valor particular. El peso es 1 y 0 respectivamente en los ejemplos anteriores.

Puerto : esto muestra el puerto TCP o UDP en el que se está ejecutando el servicio.

Objetivo : este es el subdominio o dominio de destino al que se redirigirá este servicio y debe tener un registro A / AAAA válido para que este tráfico se redirija allí.

14. Registro de RP (Persona responsable)

Esto normalmente no es necesario hoy en día, ya que hay una dirección de correo electrónico asociada con el registro SOA. Pero si algún dominio desea tener una mención específica aparte de la cuenta de correo electrónico de registro SOA predeterminada, entonces podemos agregar un registro RP.

15. Registro DNSKEY

El registro DNSkey contiene una clave pública que será utilizada por los resolutores para verificar las firmas dnssec.

Entrada de muestra

dominio.com. 300 IN DNSKEY 257 3 5 Z10wdRIHGJGGIUGIUGKUOIKHpouptYRSyrsYRDfYTpoPO
ipoEUofZcndFN2aVd ==
Nombre ttl clase RRtype flags_filed Protocolo Algoritmo public_key

Nombre : es el nombre de dominio o el nombre de host normalmente

EN : Representa la clase de registro y la predeterminada es IN (que significa Internet)

Tipo de registro: tipo de registro es el tipo de registro y en este caso será DNSKEY

Banderas: Las banderas archivadas están en un formato cableado que es un carácter de 2 bytes de longitud. Los valores posibles son 0, 256 y 257. Si el valor es 256, significa que el registro dnskey contiene ZSK (clave de firma de zona) pagado y si el valor es 257, entonces contiene KSK (componente de clave de firma de clave. En resumen, este campo contiene un número impar cuando contiene un par de claves KSK.

Protocolo: Esto siempre tiene un valor de 3, para DNSSEC.

Llave pública : la clave pública son los datos de la clave y, en este caso, es "Z10wdRIHGJGGIUGIUGKUOIKHpouptYRSyrsYRDfYTpoPOipoEUofZcndFN2aVd =="

Algoritmo: Nos ayuda a identificar public_keys utilizando diferentes algoritmos y a continuación están los más utilizados

1 = RSA / MD5
2 = Diffie-Hellman (esto no es compatible con BIND)
3 = DSA
4 = Reservado
5 = RSA / SHA1
6 = DSA / SHA1 / NSEC3
7 = RSA / SHA1 / NSEC3
8 = RSA / SHA-256
10 = RSA / SHA-512

Conclusión

Espero que esto realmente les ayude a todos a comprender el DNS y a garantizar que su alojamiento esté configurado correctamente.

Conceptos básicos de resolución de DNS necesarios para el alojamiento web