Capa 7 · Aplicación · Teoría — Modelo OSI

La capa 7, la de aplicación, es la que ve el usuario: lo que escribe en el navegador, la carpeta que abre, el correo que manda. Y lo primero que hace casi cualquier aplicación antes de hablar con nadie es buscar un nombre: nadie escribe https://10.20.1.200, se escribe https://intranet.empresa.lan. Alguien tiene que traducir ese nombre a una dirección.

Aquí las averías son las del “va por IP, pero no por nombre”. El ping a 10.20.1.200 contesta, la intranet abre si se escribe la dirección, y aun así por su nombre no carga, o lleva a un servidor que ya no existe, o el servidor contesta con un error. Todo lo de abajo está bien: lo que falla es cómo encuentra cada aplicación a quién hablar, o lo que le pide al llegar. Es la famosa frase de los técnicos: “siempre es el DNS”.

La capa de aplicación, arriba del todo: los protocolos que usan los programas (HTTP, DNS, SMTP…), con sus mensajes y sus códigos.

Qué es la capa de aplicación

Es donde viven los protocolos de los programas: HTTP (las webs), DNS (los nombres), SMTP e IMAP (el correo), SMB (las carpetas compartidas), RDP (el escritorio remoto). Cada uno tiene sus mensajes (una petición, una respuesta) y, casi siempre, códigos de respuesta que dicen qué ha pasado. En TCP/IP es la capa de arriba del todo, y recoge lo que en OSI son las capas 5, 6 y 7: por eso las sesiones y la presentación las llevaba cada aplicación.

Para el técnico, lo importante de esta capa es que cuando todo lo de abajo va bien, lo que queda es la aplicación: qué nombre pide, a quién se lo pregunta y qué le contestan.

Nombres en vez de direcciones: el DNS

El DNS (Domain Name System) traduce nombres a direcciones. Está repartido: nadie tiene todos los nombres del mundo. Cada zona (como empresa.lan) la lleva un servidor, que es autoritativo para ella: sus respuestas son las buenas. Lo que hay dentro son registros:

Registro	Qué dice	Ejemplo
A	el nombre tiene esta IPv4	`intranet` → 10.20.1.200
CNAME	el nombre es otro nombre	`www` → `intranet`
MX	el correo de este dominio va a	`empresa.es` → `mail.empresa.es`
PTR	la dirección se llama (al revés)	10.20.1.200 → `srv-sede`

Cada registro lleva además un TTL (time to live): cuántos segundos puede guardar la respuesta quien la recibe antes de volver a preguntar. Con un TTL de una hora, un cambio tarda hasta una hora en llegar a todos.

nslookup pregunta al servidor DNS del equipo y enseña quién contesta y qué:

Pregunta al servidor de la empresa, que es el dueño de la zona

C:\Users\ventas2> nslookup intranet.empresa.lan
Servidor:  srv-sede.empresa.lan
Address:  10.20.1.200

Nombre:  intranet.empresa.lan
Address:  10.20.1.200

Las dos primeras líneas son el servidor al que se preguntó. (Si sale UnKnown, es que el servidor no tiene nombre al revés, sin registro PTR: no es un error.) Luego, la respuesta.

Cómo resuelve un puesto

Cuando una aplicación pide un nombre, Windows no pregunta al DNS a la primera. Mira antes en dos sitios, y se fía de lo primero que encuentra:

Primero el archivo hosts, luego la caché y, si no, su servidor DNS, que contesta lo suyo y reenvía lo demás.

El archivo hosts (C:\Windows\System32\drivers\etc\hosts): una lista escrita a mano de nombres y direcciones. Lo que ponga ahí gana a todo lo demás, esté bien o mal. Alguien lo usó un día para una prueba y se olvidó de quitarlo: una avería clásica. Algunos instaladores también añaden su línea (la de su servidor de pruebas), con un comentario detrás.
La caché: las respuestas que ya le dieron, mientras no pase su TTL. ipconfig /displaydns la enseña, y ipconfig /flushdns la vacía. Por eso, después de arreglar un registro en el servidor, quien ya lo había preguntado sigue yendo a la dirección de antes hasta que caduque o la vacíe.
Su servidor DNS: el que tiene configurado (normalmente, el que le dio el DHCP).

La última línea no es un comentario: intranet.empresa.lan va a una IP vieja, solo en este puesto

C:\Users\conta1> type C:\Windows\System32\drivers\etc\hosts
# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#	127.0.0.1       localhost
#	::1             localhost
10.20.1.201     intranet.empresa.lan

Ojo con lo que engaña: nslookup no mira el hosts ni la caché, pregunta directamente al servidor DNS. Así que en ese puesto nslookup da la dirección buena y el navegador va a la vieja. Cuando no cuadran, el problema está en el puesto.

La caché guarda la respuesta vieja: le quedan 3412 segundos

C:\Users\ventas1> ipconfig /displaydns

Configuración IP de Windows

  intranet.empresa.lan
  ----------------------------------------
  Nombre de registro  . : intranet.empresa.lan
  Tipo de registro  . . : 1
  Período de vida . . . : 3412
  Longitud de datos . . : 4
  Sección . . . . . . . : respuesta
  Un registro (host). . : 10.20.1.201

C:\Users\ventas1> ipconfig /flushdns

Configuración IP de Windows

Se vació correctamente la caché de resolución de DNS.

El servidor DNS de la empresa

En una red con dominio de Windows, el controlador del dominio es también el servidor DNS: el dominio no funciona sin él (los puestos lo usan para encontrar a su controlador). En la sala es SRV-SEDE, y tiene la zona empresa.lan.

¿Y los nombres de internet, como www.empresa.es? Esos no son suyos. El servidor los reenvía a otro servidor DNS (el del proveedor): es su reenviador. Cuando la respuesta viene de otro, nslookup avisa de que no es “autoritativa”:

Un nombre de fuera: el servidor lo preguntó por su reenviador

C:\Users\ventas2> nslookup www.empresa.es
Servidor:  srv-sede.empresa.lan
Address:  10.20.1.200

Respuesta no autoritativa:
Nombre:  www.empresa.es
Address:  198.51.100.10

Sin reenviador, el servidor no sabe a quién preguntar, y lo de fuera falla aunque lo de dentro vaya bien:

Sin reenviador: lo de dentro resuelve, lo de fuera no

C:\Users\ventas2> nslookup www.empresa.es
Servidor:  srv-sede.empresa.lan
Address:  10.20.1.200

*** srv-sede.empresa.lan no encuentra www.empresa.es: Server failed

Y un nombre que no existe tiene su propio mensaje, distinto del fallo del servidor: *** srv-sede.empresa.lan no encuentra intranet2.empresa.lan: Non-existent domain. En el navegador, DNS_PROBE_FINISHED_NXDOMAIN; en ping, “La solicitud de ping no pudo encontrar el host”.

Las preguntas llegan al servidor por el puerto 53 (UDP), así que su Firewall tiene que dejarlas entrar (la regla «DNS (UDP, entrada)»). Si no, nadie contesta, ni siquiera para decir que no existe: nslookup dice DNS request timed out, y a todos les falla todo por nombre mientras por IP va.

De dónde saca un puesto su servidor DNS

El DHCP no solo da la dirección, la máscara y la puerta: también dice a qué servidor DNS preguntar (la opción 6). Si reparte uno que no es el de la empresa, los puestos de esa red resuelven internet, pero los nombres de la empresa no existen para ellos:

Con el DNS de la empresa, todo resuelve. Con uno público, internet sí y lo de la empresa no.

En la sala, el DHCP de la sede lo da el servidor (un ámbito por departamento, con su opción «Servidores DNS»), y el de la sucursal, su router (el dns-server del pool). Lo que tiene un puesto se ve con ipconfig /all:

El DHCP le dio 8.8.8.8 como servidor DNS: no es el de la empresa

C:\Users\ventas2> ipconfig /all | findstr "DHCP DNS"
   Sufijo DNS principal  . . . . . : empresa.lan
 Lista de búsqueda de sufijos DNS: empresa.lan
 Sufijo DNS específico para la conexión. . :
 DHCP habilitado . . . . . . . . . . . . . : sí
 Servidor DHCP . . . . . . . . . . . . . . : 10.20.1.200
 Servidores DNS. . . . . . . . . . . . . . : 8.8.8.8

(El sufijo empresa.lan es el del dominio: Windows lo pone detrás de un nombre sin puntos, así que srv-sede es srv-sede.empresa.lan.)

Se arregla donde se reparte, y después cada puesto tiene que renovar su concesión para enterarse (ipconfig /renew, o esperar a que la renueve solo). Al revés pasa igual: un puesto pide lo suyo al DHCP al arrancar, así que si alguien cambia lo que se reparte, el primero que se reinicia se lleva lo nuevo y los demás siguen con lo de antes hasta renovar. En un router Cisco:

Que el pool de la sucursal reparta el DNS de la empresa

R-SUCURSAL(config)# ip dhcp pool SUCURSAL
R-SUCURSAL(dhcp-config)# dns-server 10.20.1.200
R-SUCURSAL(dhcp-config)# end

HTTP por nombre: la cabecera Host

Un mismo servidor web puede tener varios sitios en la misma dirección. ¿Cómo sabe cuál quiere el navegador? Porque cada petición HTTP lleva el nombre que se escribió en la cabecera Host. El servidor busca un sitio con ese nombre; si ninguno lo tiene, IIS contesta 400 Bad Request - Invalid Hostname:

La misma dirección, dos peticiones: con el nombre que el servidor conoce, la página; con otro, un 400.

Así que “por IP va y por nombre no” también puede ser esto: el DNS contesta bien, se llega al servidor, y el sitio no reconoce el nombre. curl.exe -I lo enseña:

El DNS va bien (se llegó al servidor), pero ningún sitio tiene ese nombre

C:\Users\ventas2> curl.exe -I https://intranet.empresa.lan/
HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Fri, 25 Sep 2026 07:14:03 GMT
Connection: close
Content-Length: 334

Cada respuesta HTTP empieza por un código de estado, y el primer número dice de quién es el problema:

Código	Qué dice
200 OK	todo bien
301 / 302	está en otra dirección (redirección)
400 Bad Request	la petición no vale (por ejemplo, un `Host` desconocido)
403 Forbidden	existe, pero no te deja
404 Not Found	esa ruta no existe
500 Internal Server Error	la aplicación ha fallado

Los 2xx son éxito, los 3xx, “ve a otro sitio”; los 4xx, algo de la petición (el cliente) y los 5xx, algo del servidor.

El correo

El correo tiene sus propios protocolos: SMTP para mandar (de tu programa al servidor, y de un servidor a otro), e IMAP (o el viejo POP3) para leer lo que te ha llegado. ¿Cómo sabe un servidor a dónde entregar un correo para empresa.es? Por el DNS: el registro MX de ese dominio dice qué servidores reciben su correo (el de menor número, primero).

El correo de empresa.es va a mail.empresa.es

C:\Users\ventas2> nslookup -type=MX empresa.es
Servidor:  srv-sede.empresa.lan
Address:  10.20.1.200

Respuesta no autoritativa:
empresa.es	MX preference = 10, mail exchanger = mail.empresa.es

(En la sala no hay correo: esta parte es solo de la teoría.)

Cómo se diagnostica la capa 7

Con las capas de abajo descartadas, se pregunta en este orden, y cada respuesta dice dónde mirar:

¿Va por IP? ¿El nombre da la IP buena? ¿La aplicación va bien? Cada «no» señala un sitio.

¿Va por la IP? (ping 10.20.1.200, el navegador con la dirección). Si no, el problema es de las capas 1 a 6.
¿El nombre da la IP buena? nslookup (lo que dice el servidor DNS) frente a ping por nombre (lo que usa de verdad el puesto). Si no cuadran, el puesto: su hosts o su caché. Si nslookup da una IP mala, el registro. Si no resuelve nada, ¿a qué servidor pregunta (ipconfig /all)? ¿Y ese servidor sabe reenviar lo de fuera?
¿A todos o a uno? A todos: el servidor DNS o su registro. A un departamento: lo que le reparte su DHCP. A un puesto: su hosts o su caché.
Si el nombre resuelve bien, ¿qué contesta la aplicación? Su código de estado (con curl.exe -I o -v): un 400 es la petición (el Host); un 404, la ruta; un 500, la aplicación.