Skip to content

Dominios, DNS y HTTPS

Prefacio

Cuando escribes www.google.com en tu navegador y presionas Enter, ¿qué sucede detrás de escena? Esta acción aparentemente simple implica una serie de procesos de colaboración que incluyen resolución de nombres de dominio, consultas DNS, cifrado TLS y más. Comprender estos mecanismos es esencial para cualquier desarrollador: determina directamente si tu sitio web puede ser visitado y si tus datos pueden ser interceptados.

¿Qué aprenderás en este artículo?

Después de completar este capítulo, obtendrás:

  • Principios de DNS: comprender el proceso completo de cómo los nombres de dominio se traducen a direcciones IP
  • Tipos de registros: dominar los usos de los registros DNS comunes como A, CNAME, MX, etc.
  • Mecanismo HTTPS: comprender cómo el handshake TLS establece una conexión segura
  • Sistema de certificados: conocer la cadena de confianza de los certificados digitales y el mecanismo de verificación
  • Conciencia de seguridad: entender por qué HTTPS es un requisito mínimo de la Web moderna
CapítuloContenidoConcepto clave
Capítulo 1Resolución DNSConsulta recursiva, consulta iterativa
Capítulo 2Registros DNSA, CNAME, MX, TXT
Capítulo 3HTTPS y TLSProceso de handshake, comunicación cifrada
Capítulo 4Cadena de confianza de certificadosCA, certificado raíz, certificado intermedio
Capítulo 5HTTP vs HTTPSTexto plano vs cifrado, comparación de seguridad

0. Panorama general: del nombre de dominio a la conexión segura

La comunicación en Internet se basa en direcciones IP (como 142.250.80.46), pero los humanos no pueden recordar estos números. Por eso inventamos el Sistema de Nombres de Dominio (DNS), la "agenda telefónica" de Internet, que traduce los nombres de dominio legibles por humanos en direcciones IP legibles por máquinas.

Pero poder encontrar el servidor no es suficiente. Si el contenido de la comunicación se transmite en texto plano, cualquier intermediario puede interceptar o alterar tus datos. HTTPS resuelve este problema: añade una capa de cifrado TLS sobre HTTP, garantizando la confidencialidad e integridad de los datos durante la transmisión.

Una visita web completa

  1. Resolución de nombre de dominio: el navegador pregunta al DNS "¿cuál es la IP de www.google.com?", el DNS responde "142.250.80.46"
  2. Conexión TCP: el navegador establece un handshake TCP de tres vías con el servidor
  3. Handshake TLS: ambas partes negocian algoritmos de cifrado, verifican certificados e intercambian claves
  4. Comunicación cifrada: todos los datos HTTP se transmiten a través del canal cifrado

1. Resolución DNS: la "agenda telefónica" de Internet

El principio de funcionamiento de DNS (Domain Name System) es como buscar en una agenda telefónica: conoces el nombre de la persona (nombre de dominio) y necesitas encontrar su número de teléfono (dirección IP). Pero la "agenda telefónica" de Internet no es un solo libro, sino un sistema distribuido y jerárquico.

🔍 DNS Resolution Simulator

🌐
Browser cache
💻
OS cache
🔄
Recursive resolver
🌍
Root name server
📂
TLD server
🏠
Authoritative DNS server
Resolution flow: When the browser visits a website, it first translates the domain name into an IP address. This process checks multiple caches and servers until the matching IP is found.

Los cuatro pasos de la resolución DNS

  1. Caché del navegador: primero busca en la caché local; si ya has visitado este dominio antes, usa la IP en caché directamente
  2. Resolvedor recursivo: si no está en la caché, la solicitud se envía al resolvedor recursivo del ISP (como 8.8.8.8)
  3. Consulta jerárquica: el resolvedor recursivo pregunta sucesivamente al servidor raíz → servidor TLD (.com) → servidor autoritativo (google.com)
  4. Retorno del resultado: el servidor autoritativo devuelve la IP final, el resolvedor recursivo almacena en caché el resultado y lo devuelve al navegador
NivelServidorResponsabilidadCantidad
RaízRoot ServerConoce las direcciones de todos los TLD13 grupos globally
TLDTLD ServerAdministra .com, .cn, .org, etc.Un grupo por sufijo
AutoritativoAuthoritativeAlmacena los registros DNS de dominios específicosAl menos 2 por dominio
Resolvedor recursivoResolverRealiza todo el proceso de consulta en nombre del usuarioISP o DNS público

2. Tipos de registros DNS: la "tabla de configuración" detrás de los dominios

DNS no solo traduce nombres de dominio a direcciones IP. A través de diferentes tipos de registros DNS, puedes controlar la entrega de correo, redirecciones de dominios, descubrimiento de servicios y más. Comprender estos tipos de registros es fundamental para configurar dominios y solucionar problemas de red.

📋 DNS Record Type Cheatsheet

AAddress record

Maps a domain name to an IPv4 address. This is the most common DNS record type and is ultimately what browsers need when visiting a site.

Example record
example.com. IN A 93.184.216.34
Common uses
  • Point a website domain to a server IP
  • Point subdomains to different servers
  • Return multiple IPs for load balancing
Tip: DNS does more than translate domains into IP addresses. It also supports mail routing, domain verification, load balancing, and other features through different record types.
Tipo de registroUsoEjemplo
ADominio → dirección IPv4example.com → 93.184.216.34
AAAADominio → dirección IPv6example.com → 2606:2800:220:1:...
CNAMEDominio → otro dominio (alias)www.example.com → example.com
MXEspecifica el servidor de correoexample.com → mail.example.com
TXTAlmacena información de textoVerificación SPF, verificación de propiedad del dominio
NSEspecifica el servidor DNS autoritativoexample.com → ns1.example.com

Configuración DNS en escenarios reales

  • Desplegar un sitio web: añade un registro A que apunte a la IP del servidor, o un CNAME que apunte al dominio del CDN
  • Configurar correo electrónico: añade un registro MX que apunte al servidor de correo, y un registro TXT para configurar SPF/DKIM contra el spam
  • Verificar la propiedad del dominio: el proveedor de servicios en la nube te pedirá que añadas un registro TXT específico para demostrar que posees el dominio
  • Balanceo de carga: configura múltiples registros A para el mismo dominio, el DNS distribuye el tráfico por turnos

3. HTTPS y TLS: poniento un "chaleco antibalas" a los datos

El protocolo HTTP transmite datos en texto plano, como enviar una postal donde el cartero (intermediario) puede leer el contenido libremente. HTTPS añade una capa de cifrado TLS (Transport Layer Security) sobre HTTP, equivalente a meter la postal en un sobre sellado.

El handshake TLS es el paso clave para establecer una conexión segura. Antes de transmitir datos formalmente, completa la autenticación de identidad y la negociación de claves.

🤝 TLS Handshake Demo

💻
Client (browser)
Client Hello
Send supported TLS versions, cipher suites, and random number
Server Hello
Choose TLS version, cipher suite, and server random number
Certificate
Server sends its digital certificate with public key
Key Exchange
Both sides negotiate and generate a session key
Finished
Both sides confirm the handshake and start encrypted communication
🖥️
Server

Pasos clave del handshake TLS 1.3

  1. Client Hello: el cliente envía una lista de algoritmos de cifrado compatibles y un número aleatorio
  2. Server Hello: el servidor selecciona el algoritmo de cifrado, devuelve el certificado digital y un número aleatorio
  3. Verificación del certificado: el cliente verifica si el certificado del servidor es confiable (verifica la firma de la CA, la validez, la coincidencia del dominio)
  4. Intercambio de claves: ambas partes negocian una clave compartida mediante el algoritmo ECDHE (la clave en sí no se transmite por la red)
  5. Comunicación cifrada: todos los datos posteriores se transmiten cifrados con la clave simétrica negociada
CaracterísticaTLS 1.2TLS 1.3
Viajes de ida y vuelta del handshake2-RTT1-RTT (primera vez) / 0-RTT (reanudación)
Intercambio de clavesRSA o ECDHESolo ECDHE (seguridad hacia adelante)
Algoritmos de cifradoSoporta muchos algoritmos antiguosSolo conserva algoritmos seguros
RendimientoMás lentoMás rápido

4. Cadena de confianza de certificados: ¿por qué confiar en este sitio web?

El paso más crítico en el handshake TLS es la "verificación del certificado". ¿Cómo determina el navegador que el certificado de un sitio web es auténtico y no una falsificación de un atacante? La respuesta es la cadena de confianza de certificados, un sistema de respaldo de confianza en capas.

🔗 Certificate Trust Chain

Click each certificate layer to inspect its details and role in the trust chain.

🏛️
Root Certificate (Root CA)
Starting point of trust
issues
🏢
Intermediate Certificate (Intermediate CA)
Bridge of trust
issues
🌐
Server Certificate
Website identity card
🏛️Root Certificate (Root CA)
IssuerDigiCert Global Root G2 (self-signed)
Validity25 years (2013 - 2038)
Key lengthRSA 2048-bit
StorageOS/browser built-in trust store
ScaleAbout 150 trusted root certificates globally
The root certificate is the anchor of the whole trust chain. It is self-signed by a root certificate authority and preinstalled in operating systems and browsers. Only a small number of root CAs exist globally, protected by strict audits and physical security. Root CA private keys are usually stored offline in hardware security modules.
🔍 Browser Verification Flow
1Browser receives the server certificate and reads issuer information.
2It finds the intermediate certificate and verifies the server certificate signature with the intermediate CA public key.
3It then verifies the intermediate certificate signature with the root CA public key.
4It confirms the root certificate exists in the local trust store, so the whole chain is valid.

Estructura de tres niveles de la cadena de confianza

  1. Certificado raíz (Root CA): emitido por una Autoridad Certificadora de confianza, preinstalado en sistemas operativos y navegadores. Este es el "ancla" de confianza.
  2. Certificado intermedio (Intermediate CA): emitido por la CA raíz, utilizado para emitir certificados finales. La CA raíz no emite certificados de sitios web directamente por razones de aislamiento de seguridad.
  3. Certificado final (Leaf Certificate): el certificado que tu sitio web utiliza realmente, emitido por la CA intermedia, contiene información como el dominio, la clave pública y la fecha de validez.
Tipo de certificadoNivel de verificaciónVelocidad de emisiónEscenario de uso
DV (Validación de dominio)Solo verifica la propiedad del dominioMinutosSitios personales, blogs
OV (Validación de organización)Verifica la identidad de la organizaciónDíasSitios web corporativos
EV (Validación extendida)Verificación estricta de la organizaciónSemanasBancos, instituciones financieras
Certificado comodínCubre todos los subdominiosDepende del tipoEscenarios con múltiples subdominios

5. HTTP vs HTTPS: ¿por qué el cifrado es el requisito mínimo?

En 2024, más del 95% del tráfico web global ya se transmite a través de HTTPS. El navegador Chrome marca los sitios HTTP con una advertencia de "No seguro", y los motores de búsqueda también reducen el ranking de los sitios HTTP. HTTPS ya no es una "opción", sino un requisito mínimo de la Web moderna.

🔐 HTTP vs HTTPS Data Transfer

💻
Browser
Original data
password=MySecret123&user=zhangsan
🔓 Plaintext transfer
🕵️
A man-in-the-middle can eavesdrop
🖥️
Server
ItemHTTPHTTPS
Port80443
Data encryptionNone (plaintext)TLS symmetric encryption
Identity verificationNoneCA certificate verifies server identity
Data integrityNo guaranteeMAC check prevents tampering
SEO impactSearch engines may rank it lowerPreferred by search engines
Performance costNo extra overheadTLS handshake adds about 1-2 RTT
DimensiónHTTPHTTPS
Transmisión de datosTexto plano, puede ser interceptadoCifrado, no puede ser interceptado
AutenticaciónNinguna, no se puede verificar la identidad del servidorSí, verifica el servidor mediante certificados
Integridad de datosSin protección, puede ser alteradoCon protección, la alteración es detectada
Puerto80443
Impacto SEORanking de búsqueda reducidoBonificación en ranking de búsqueda
Indicador del navegadorMuestra advertencia "No seguro"Muestra icono de candado

Obtener certificados HTTPS gratuitos

Let's Encrypt es una autoridad certificadora gratuita y automatizada que permite a cualquier sitio web habilitar HTTPS sin costo. Junto con la herramienta Certbot, puedes solicitar y renovar automáticamente certificados con un solo comando. La mayoría de las plataformas en la nube y proveedores de CDN también ofrecen certificados SSL gratuitos.


Resumen

Los nombres de dominio, DNS y HTTPS son los tres pilares de la infraestructura de Internet. DNS nos permite acceder a sitios web usando nombres legibles por humanos, y HTTPS garantiza que el proceso de comunicación sea seguro y confiable.

Repaso de los puntos clave de este capítulo:

  1. DNS es un sistema jerárquico: dominio raíz → TLD → dominio autoritativo, consulta por niveles, acelerada por caché
  2. Los tipos de registros tienen usos distintos: el registro A apunta a una IP, CNAME crea un alias, MX gestiona el correo, TXT se usa para verificación
  3. El handshake TLS establece confianza: verificación de certificados + negociación de claves, TLS 1.3 solo necesita 1-RTT
  4. Cadena de confianza de certificados: CA raíz → CA intermedia → certificado final, respaldo en capas
  5. HTTPS es el requisito mínimo: los certificados gratuitos (Let's Encrypt) hacen que el cifrado no tenga barreras

Lecturas complementarias