Correo electrónico

El símbolo arrobaforma parte de todos los correos electrónicos y está especificada en la norma RFC
5321.123

El correo electrónico (en inglés: electronic mail, comúnmente abreviado e-mail o email)45
es un servicio de red que permite a los usuarios enviar y recibir mensajes (también
denominados mensajes electrónicos o cartas digitales) mediante redes de comunicación
electrónica.6 El término «correo electrónico» proviene de la analogía con el correo postal:
ambos sirven para enviar y recibir mensajes, y se utilizan «buzones» intermedios
(servidores de correo). Por medio del correo electrónico se puede enviar no
solamente texto, sino todo tipo de archivos digitales,7 si bien suelen existir limitaciones al
tamaño de los archivos adjuntos.8 9

Los sistemas de correo electrónico se basan en un modelo de almacenamiento y reenvío,

de modo que no es necesario que ambos extremos se encuentren conectados
simultáneamente. Para ello se emplea un servidor de correo que hace las funciones de
intermediario, guardando temporalmente los mensajes antes de enviarse a sus
destinatarios.10 En Internet, existen multitud de estos servidores, que incluyen
a empresas, proveedores de servicios de internet y proveedores de correo tanto libres
como de pago.

Origen del correo electrónico[editar]

El correo electrónico es anterior a la creación de Internet. El primer antecedente data de
1962, cuando el Massachusetts Institute of Technology adquirió una computadora
de tiempo compartido modelo IBM 7090 (actualizado en 1963 a un IBM 7094) que permitía
a varios usuarios iniciar sesión desde terminales remotas, y así guardar archivos en el
disco. Este sistema se utilizó informalmente para intercambiar mensajes, pero ya
en 1965 se desarrolló el servicio MAIL, que facilitaba el envío de mensajes entre los
usuarios de esta máquina.11
El primer mensaje de correo electrónico genuinamente enviado a través de una red data
del año 1971. El mensaje, que contenía únicamente el texto «QWERTYUIOP», se envió a
través de la red ARPANET, aunque las máquinas estaban físicamente una junto a la otra.
La idea del correo electrónico sobre redes se debe a Ray Tomlinson, quien utilizó
el protocolo experimental CYPNET para enviar por red los mensajes, que hasta ese
momento solo comunicaban a los usuarios de una misma computadora.12
Fue así mismo Tomlinson quien incorporó el uso de la arroba (@) como divisor entre el
usuario y la computadora en la que se aloja la cuenta del usuario de destino.
Anteriormente no había necesidad de especificar la máquina de destino puesto que todos
los mensajes que se enviaban eran locales; sin embargo, con el nuevo sistema era preciso
distinguir el correo local del correo de red. El motivo de elegir este símbolo fue que en
inglés la arroba se lee «at» (en español en). Así, la dirección ejemplo@máquina.com se
lee ejemplo en máquina punto com.13
En 1977, el correo electrónico se convirtió en un servicio de red estandarizado, gracias a
diversos estándares parciales,14 que culminaron con la especificación RFC 733.15
Direcciones de correo electrónico[editar]

Cartel de la calle "Arroba", en el Parque Científico Tecnológico de la Universidad de Alcalá.

Para poder enviar o recibir mensajes de un correo electrónico es necesario disponer de

una cuenta de correo. Dicha cuenta es un buzón virtual identificado por una dirección de
correo electrónico de la forma «Juan.Nadie@ejemplo.com». Cada dirección se compone
de una parte local (en este caso Juan.Nadie), el símbolo separador @ y una parte que
identifica un dominio (en este caso ejemplo.com).16
Existen diversos modos de obtener una cuenta de correo electrónico:

 las empresas y administraciones suelen proporcionar una cuenta de correo

corporativo a sus empleados.
 los centros educativos, especialmente los universitarios, hacen lo propio con
empleados y alumnos.
 en el ámbito doméstico, los proveedores de servicios de internet suelen facilitar una o
varias cuentas por cada contrato.
 existen proveedores de correo que proporcionan este servicio a cambio de una cuota.
 finalmente, es posible obtener gratuitamente una cuenta de correo en servicios tales
como GMail, Yahoo Mail, Outlook.com y muchos otros.

Funcionamiento[editar]

Esquema de funcionamiento del correo electrónico mediante los protocolos SMTPy POP3.

En el ejemplo ficticio descrito por la figura, Ana (ana@a.org) envía un correo electrónico
a Bea (bea@b.com). Cada una de ellas tiene su cuenta de correo electrónico en
un servidor distinto (una en a.org, otra en b.com), pero estos se pondrán en contacto
para transferir el mensaje.
Secuencialmente, son ejecutados los siguientes pasos:

1. Ana escribe el correo con la ayuda de su cliente de correo electrónico. Cuando

envía el mensaje, el programa hace contacto con el servidor de correo usado
por Ana (en este caso, smtp.a.org). Se comunica usando un lenguaje conocido
como protocolo SMTP. Le transfiere el correo, y le da la orden de enviarlo.
 2. El servidor smtp.a.org debe entregar un correo a un usuario del dominio b.com,
pero no sabe con qué ordenador tiene que conectarse. Para ello, efectúa una
consulta al servidor DNS de su red, usando el protocolo DNS, y le pregunta qué
servidor es el encargado de gestionar el correo del dominio b.com. Técnicamente,
le está preguntando el registro MX asociado a ese dominio.
3. Como respuesta a esta petición, el servidor DNS contesta con el nombre de
dominio del servidor de correo de Bea. En este caso es mx.b.com; que en este
caso en particular es un servidor gestionado por el proveedor de Internet de Bea.
4. El servidor SMTP (smtp.a.org) ya puede conectarse con mx.b.com y transferirle
el mensaje, que quedará guardado en este ordenador. Se usa otra vez el
protocolo SMTP.
5. Posteriormente, cuando Bea inicie su programa cliente de correo electrónico, su
ordenador inicia una conexión, mediante el protocolo POP3 o IMAP, al servidor
que guarda los correos nuevos que le han llegado. Este ordenador (pop3.b.com)
es el mismo que el del paso anterior (mx.b.com), ya que se encarga tanto de
recibir correos del exterior como de entregárselos a sus usuarios. En el
esquema, Bea se descarga el mensaje de Ana mediante el protocolo POP3.
Esta es la secuencia básica, pero pueden darse varios casos especiales:

 Si ambas cuentas de correo están en la misma red, como una Intranet de una
empresa o el mismo servidor de correo: en estos casos el mensaje no se envía de un
servidor a otro porque ambos son el mismo. En el primero de los casos ni siquiera
atravesará la red Internet.
 Ana podría tener instalado un servidor SMTP en su propio ordenador, de forma que el
paso 1 se haría en su mismo ordenador. De la misma forma, Bea podría tener su
servidor de correo en el propio ordenador.
 Una persona puede no usar un cliente de correo electrónico, sino un cliente de correo
con interfaz web. El proceso es casi el mismo, pero se usan conexiones HTTP para
acceder al correo de cada usuario en vez de usar SMTP o IMAP/POP3.
 Normalmente existe más de un servidor de correo (MX) disponible de respaldo, para
que aunque uno falle, se siga pudiendo recibir correo.
 En los comienzos de Internet era habitual que los servidores estuvieran configurados
como open relay (relé abierto), es decir, que transmitían mensajes de cualquier
usuario y no solo de remitentes o destinatarios conocidos. Sin embargo este tipo de
funcionamiento ha caído en desuso, ya que facilitaban la difusión del spam, y de
hecho los estándares desaconsejan su uso.17

Escritura del mensaje[editar]

No se pueden mandar mensajes entre computadores personales o entre dos terminales de
una computadora central. Los mensajes se archivan en un buzón (una manera rápida de
mandar mensajes). Cuando una persona decide escribir un correo electrónico, su
programa (o correo web) le pedirá como mínimo tres cosas:

 Destinatario: una o varias direcciones de correo a las que ha de llegar el mensaje

 Asunto: una descripción corta que verá la persona que lo reciba antes de abrir el
correo
 El propio mensaje. Puede ser sólo texto, o incluir formato, y no hay límite de tamaño.
Además, se suele dar la opción de incluir archivos adjuntos al mensaje. Esto permite
traspasar datos informáticos de cualquier tipo mediante el correo electrónico.
Para especificar el destinatario del mensaje, se escribe su dirección de correo en el
campo llamado Para dentro de la interfaz (ver imagen de arriba). Si el destino son varias
personas, normalmente se puede usar una lista con todas las direcciones, separadas por
comas o punto y coma.
Además del campo Para existen los campos CC y CCO, que son opcionales y sirven para
hacer llegar copias del mensaje a otras personas:

 Campo CC (Copia de Carbón): quienes estén en esta lista recibirán también el

mensaje, pero verán que no va dirigido a ellos, sino a quien esté puesto en el
campo Para. Como el campo CC lo ven todos los que reciben el mensaje, tanto el
destinatario principal como los del campo CC pueden ver la lista completa.
 Campo CCO (Copia de Carbón Oculta): una variante del CC, que hace que los
destinatarios reciban el mensaje sin aparecer en ninguna lista. Por tanto, el
campo CCO nunca lo ve ningún destinatario.
Un ejemplo: Ana escribe un correo electrónico a Beatriz (su profesora), para enviarle un
trabajo. Sus compañeros de grupo, Carlos y David, quieren recibir una copia del mensaje
como comprobante de que se ha enviado correctamente, así que les incluye en el
campo CC. Por último, sabe que a su hermano Esteban también le gustaría ver este
trabajo aunque no forma parte del grupo, así que le incluye en el campo CCO para que
reciba una copia sin que los demás se enteren.
Entonces:

 Beatriz recibe el mensaje dirigido a ella (sale en el campo Para), y ve

que Carlos y David también lo han recibido
 Carlos recibe un mensaje que no va dirigido a él, pero ve que aparece en el
campo CC, y por eso lo recibe. En el campo Para sigue viendo a Beatriz
 David, igual que Carlos, ya que estaban en la misma lista (CC)
 Esteban recibe el correo de Ana, que está dirigido a Beatriz. Ve
que Carlos y David también lo han recibido (ya que salen en el CC), pero no se puede
ver a él mismo en ninguna lista, cosa que le extraña. Al final, supone que es
que Ana le incluyó en el campo CCO.

 Campo Reply-To (responder) Dirección dónde el emisor quiere que se le conteste.

Muy útil si el emisor dispone de varias cuentas.

 Campo Date (fecha, y hora, del mensaje) Fecha y hora de cuando se envío del
mensaje. Si el sistema que envía el mensaje tiene la fecha y/u hora equivocadas,
puede generar confusión.
Otros campos, menos importantes son:

 Sender: Sistema o persona que lo envía

 Received: Lista de los MTA que lo transportaron
 Message-Id: Número único para referencia
 In-Reply-to: Id. del mensaje que se contesta
 References: Otros Id del mensaje
 Keywords: Palabras claves de usuario
 X-Usuario: Definibles por el usuario

Encabezado de un correo electrónico.

La cabecera del mensaje normalmente, se muestra resumida. Para ver todos los detalles
bastará con expandir, mediante la opción oportuna, dicha cabecera.
Proceso de envío de correo electrónico[editar]
Si el usuario quiere, puede almacenar los mensajes que envía, bien de forma automática
(con la opción correspondiente), o bien sólo para los mensajes que desee. Estos mensajes
quedan guardados en un directorio o carpeta reservada para mensajes enviados en el
ordenador del usuario.

Recepción[editar]
Cuando una persona recibe un mensaje de correo electrónico puede verse en la
denominada bandeja de entrada un resumen de éste:

 Remitente (o De o De: o From o From:-en inglés-): este campo indica quién envía el
mensaje. Puede aparecer el nombre o apodo de la persona o entidad remitente. Si
quien envía el mensaje no ha configurado su programa o correo web al respecto
aparecerá su dirección de correo electrónico, solamente.
 Asunto: en este campo se ve el tema que trata el mensaje (o lo que el remitente de él
desee). Si quien envía el mensaje ha dejado esta casilla en blanco pudieran aparecer
textos como ninguno o sin asunto.
 Si el mensaje es una respuesta el asunto suele empezar por RE: o Re:
(abreviatura de responder o reply -en inglés-, seguida de dos puntos). Aunque
según de dónde proceda el mensaje pueden aparecer An: (del alemán antwort),
Sv: (del sueco svar), etc.
 Cuando el mensaje procede de un reenvío el asunto suele comenzar por RV:
(abreviatura de reenviar) o Fwd: (del inglés forward), aunque a veces empieza por
Rm: (abreviatura de remitir)
 Fecha: esta casilla indica cuándo fue enviado el mensaje o cuándo ha llegado a la
bandeja de entrada del receptor. Puede haber dos casillas que sustituyan a este
campo, una para indicar la fecha y hora de expedición del mensaje y otra para
expresar el momento de su recepción.
Además pueden aparecer otras campos como:

 Tamaño: indica el espacio que ocupa el mensaje y los fichero(s) adjunto(s) si existe(n).
 Destinatarios (o Para o Para: o To o To: -en inglés-): muestra a quiénes se envió el
mensaje.
 Datos adjuntos: si aparece una marca (habitualmente un clip) significa que el
mensaje viene con uno o varios ficheros anexos.
 Prioridad: expresa la importancia o urgencia del mensaje según el remitente (alta -se
suele indicar con un signo de exclamación-, normal -no suele llevar marca alguna- o
baja -suele indicarse con una flecha apuntando para abajo-)
 Marca (de seguimiento): si está activada (por ejemplo mostrando una bandera) indica
que hay que tener en cuenta este mensaje (previamente lo ha marcado la persona que
lo ha recibido).
 Inspeccionar u omitir: haciendo clic en este campo (o su equivalente) se puede marcar
el mensaje para inspeccionarlo (suelen aparecer el símbolo de unas gafas en la casilla
y ponerse de color llamativo -normalmente rojo- las letras de los demás campos). Al
hacer otro clic en este campo se puede marcar para omitirlo (suele aparecer el
símbolo de "prohibido el paso" en este campo y ponerse en un tono suave -
normalmente gris- las letras de las demás casillas). Pinchando una vez más volvemos
a dejar el mensaje sin ninguna de las dos marcas mencionadas
 Cuenta: Si utilizamos un cliente de correo electrónico configurado con varias cuentas
de correo, esta casilla indica a cuál de ellas ha llegado el mensaje en cuestión.
 Primeras palabras del (cuerpo del) mensaje.
Los mensajes recibidos pero sin haber sido leídos aún suelen mostrar su resumen en
negrillas. Después de su lectura figuran con letra normal. A veces si seleccionamos estos
mensajes sin abrirlos, puede observarse una previsualización de su contenido.
Si el destinatario desea leer el mensaje tiene que abrirlo (normalmente haciendo (doble)
clic sobre el contenido de su asunto con el puntero del ratón). Entonces el receptor puede
ver un encabezado arriba seguido por el cuerpo del mensaje. En la cabecera del mensaje
aparecen varias o todas las casillas arriba mencionadas (salvo las primeras palabras del
cuerpo del mensaje). Los ficheros adjuntos, si existen, pueden aparecer en el encabezado
o debajo del cuerpo del mensaje.
Una vez que el destinatario ha recibido (y, normalmente, leído) el mensaje puede hacer
varias cosas con él. Normalmente los sistemas de correo (tanto programas como correo
web) ofrecen opciones como:

 Responder: escribir un mensaje a la persona que ha mandado el correo (que es sólo

una). Existe la variante Responder a todos, que pone como destinatarios tanto al que
lo envía como a quienes estaban en el campo CC
 Reenviar (o remitir): pasar este correo a una tercera persona, que verá quién era el
origen y destinatario original, junto con el cuerpo del mensaje. De forma opcional se
puede añadir más texto al mensaje o borrar los encabezados e incluso el cuerpo (o
parte de él) de anteriores envíos del mensaje.
 Marcar como correo no deseado (spam): separar el correo y esconderlo para que
no moleste, de paso instruyendo al programa para que intente detectar mejor
mensajes parecidos a éste. Se usa para evitar la publicidad no solicitada.
 Archivar: guardar el mensaje en el ordenador, pero sin borrarlo, de forma que se
pueda consultar más adelante. Esta opción no está en forma explícita, ya que estos
programas guardan los mensajes automáticamente.
 Borrar: Se envía el mensaje a una carpeta Elementos eliminados que puede ser
vaciada posteriormente.
 Mover a carpeta o Añadir etiquetas: algunos sistemas permiten catalogar los
mensajes en distintos apartados según el tema del que traten. Otros permiten añadir
marcas definidas por el usuario (ej: "trabajo", "casa", etc.).

Problemas[editar]
Artículos principales: Spam y Antispam.

El principal problema actual es el correo no deseado, que se refiere a la recepción de

correos no solicitados, normalmente de publicidad engañosa, y en grandes cantidades,
promoviendo pornografía y otros productos y servicios de calidad sospechosa.18
Usualmente los mensajes indican como remitente del correo una dirección falsa. Por esta
razón, es más difícil localizar a los verdaderos remitentes, y no sirve de nada contestar a
los mensajes de correo no deseado: las respuestas serán recibidas por usuarios que nada
tienen que ver con ellos. Por ahora, el servicio de correo electrónico no puede identificar
los mensajes de forma que se pueda discriminar la verdadera dirección de correo
electrónico del remitente, de una falsa. Esta situación que puede resultar impactante en un
primer momento, es semejante por ejemplo a la que ocurre con el correo postal ordinario:
nada impide poner en una carta o postal una dirección de remitente aleatoria: el correo
llegará en cualquier caso. No obstante, hay tecnologías desarrolladas en esta dirección:
por ejemplo el remitente puede firmar sus mensajes mediante criptografía de clave pública.
Además del correo no deseado, existen otros problemas que afectan a la seguridad y
veracidad de este medio de comunicación:

 los virus informáticos, que se propagan mediante ficheros adjuntos infectando el

ordenador de quien los abre
 la suplantación de identidad, que es correo fraudulento que generalmente intenta
conseguir información bancaria
 los bulos (bromas, burlas, o hoax), que difunden noticias falsas masivamente
 las cadenas de correo electrónico, que consisten en reenviar un mensaje a mucha
gente; aunque parece inofensivo, la publicación de listas de direcciones de correo
contribuye a la propagación a gran escala del correo no deseado y de mensajes con
virus, suplantadores de identidad y engaños.
Pérdida progresiva de la privacidad[editar]
Desde 2014, los principales proveedores de correo web como Google19 o Yahoo20 exigen
como requisito proveer datos personales como un número de teléfono obligatorio o una
dirección de correo alternativa obligatoria para así impedir las altas anónimas o de
personas que no puedan tener acceso a la compra de un teléfono móvil.

Servicios de correo electrónico[editar]

Principales proveedores de servicios de correo electrónico gratuito:

 Gmail: webmail, POP3 e IMAP

 Outlook.com: webmail y POP3
 Yahoo! Mail: webmail y POP3 con publicidad
Los servicios de correo de pago los suelen dar las compañías de acceso a Internet o
los registradores de dominios.
También hay servicios especiales, como Mailinator, que ofrece cuentas de correo
temporales (caducan en poco tiempo) pero que no necesitan registro.

Programas para leer y organizar correo[editar]

Artículo principal: Lista de clientes de correo electrónico

 Windows Live Mail: Windows.

 Evolution: GNU/Linux.
 Mail: Mac OS X e iOS.
 Outlook Express: Windows.
 Thunderbird: Windows, GNU/Linux, Mac OS X.

Programas servidores de correo[editar]

Artículo principal: Servidor de correo

Son programas usados por un ordenador para proporcionar el servicio a los clientes (por lo
que se llama un servidor de correo), que podrán usarlo mediante un cliente de correo.

 Principales programas servidores:

 Mercury Mail Server: Windows, Unix, GNU/Linux.
 Microsoft Exchange Server: Windows.
 MailEnable: Windows.
 MDaemon: Windows.
 Exim: Unix.
 Sendmail: Unix.
 Qmail: Unix.
 Postfix: Unix.
 Zimbra: Unix, Windows.
 Lotus Domino: GNU/Linux, OS400, Windows.
  Windows Live Mail
 Windows Live Messenger
 Zentyal: Unix.
También existen otros programas para dar el servicio de correo web.

Protocolo de transferencia de hipertexto

El Protocolo de transferencia de hipertexto (en inglés: Hypertext Transfer
Protocol o HTTP) es el protocolo de comunicación que permite las transferencias de
información en la World Wide Web. HTTP fue desarrollado por el World Wide Web
Consortium y la Internet Engineering Task Force, colaboración que culminó en 1999 con la
publicación de una serie de RFC, el más importante de ellos es el RFC 2616 que
especifica la versión 1.1. HTTP define la sintaxis y la semántica que utilizan los elementos
de software de la arquitectura web (clientes, servidores, proxies) para comunicarse. HTTP
es un protocolo sin estado, es decir, no guarda ninguna información sobre conexiones
anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado.
Para esto se usan las cookies, que es información que un servidor puede almacenar en el
sistema cliente. Esto le permite a las aplicaciones web instituir la noción de sesión, y
también permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por
tiempo indeterminado.

Protocolo de transferencia de hipertexto

Familia Familia de protocolos de Internet

Función Transferencia de hipertexto

Última versión 2.0

Puertos 80/TCP

Ubicación en la pila de protocolos

Aplicación HTTP
Transporte TCP
Red IP

Estándares

RFC 1945 (HTTP/1.0, 1996)

RFC 2616 (HTTP/1.1, 1999)
 RFC 2774 (HTTP/1.2, 2000)
RFC 7540 (HTTP/2, 2015)

[editar datos en Wikidata]

Versiones[editar]
HTTP ha pasado por múltiples versiones del protocolo, muchas de las cuales son
compatibles con las anteriores. El RFC 2145 describe el uso de los números de versión de
HTTP. El cliente le dice al servidor al principio de la petición la versión que usa, y el
servidor usa la misma o una anterior en su respuesta.
0.9 (lanzada en 1991)
Obsoleta. Soporta sólo un comando, GET, y además no especifica el número de
versión HTTP. No soporta cabeceras. Como esta versión no soporta POST, el
cliente no puede enviarle mucha información al servidor.
HTTP/1.0 (mayo de 1996)
Esta es la primera revisión del protocolo que especifica su versión en las
comunicaciones, y todavía se usa ampliamente, sobre todo en servidores proxy.
Permite los métodos de petición GET, HEAD y POST.
HTTP/1.1 (junio de 1999)12
Versión más usada actualmente; Las conexiones persistentes están activadas por
defecto y funcionan bien con los proxies. También permite al cliente enviar
múltiples peticiones a la vez por la misma conexión (pipelining) lo que hace posible
eliminar el tiempo de Round-Trip delay por cada petición.
HTTP/1.2 (febrero de 2000)
Los primeros borradores de 1995 del documento PEP — an Extension Mechanism
for HTTP (el cual propone el Protocolo de Extensión de Protocolo, abreviado PEP)
los hizo el World Wide Web Consortium y se envió al Internet Engineering Task
Force. El PEP inicialmente estaba destinado a convertirse en un rango distintivo de
HTTP/1.2.3 En borradores posteriores, sin embargo, se eliminó la referencia a
HTTP/1.2. El RFC 2774 (experimental), HTTP Extension Framework, incluye en
gran medida a PEP. Se publicó en febrero de 2000.
HTTP/2 (mayo de 2015)
Artículo principal: HTTP/2
En el año 2012 aparecen los primeros borradores de la nueva versión de HTTP
(HTTP/2). Esta nueva versión no modifica la semántica de aplicación de http (todos
los conceptos básicos continúan sin cambios). Sus mejoras se enfocan en como se
empaquetan los datos y en el transporte. Por ejemplo, añade el uso de una única
conexión, la compresión de cabeceras o el servicio 'server push'. Los exploradores
más importantes solo soportan HTTP 2.0 sobre TLS usando la extensión ALPN4
que requiere TLSv1.2 o superior5.

Descripción[editar]
Es un protocolo orientado a transacciones y sigue el esquema
petición-respuesta entre un cliente y un servidor. El cliente (se le suele
llamar "agente de usuario", en inglés user agent) realiza una petición
enviando un mensaje, con cierto formato al servidor. El servidor (se le
suele llamar un servidor web) le envía un mensaje de respuesta.
Ejemplos de cliente son los navegadores web y las arañas
web (también conocidas por su término inglés, webcrawlers).

Mensajes[editar]
Los mensajes HTTP, son en texto plano lo que lo hace más legible y
fácil de depurar. Esto tiene el inconveniente de hacer los mensajes
más largos.
Los mensajes tienen la siguiente estructura:

 Línea inicial (termina con retorno de carro y un salto de línea) con

 Para las peticiones: la acción requerida por el servidor
(método de petición) seguido de la URL del recurso y la
versión HTTP que soporta el cliente.
 Para respuestas: La versión del HTTP usado seguido
del código de respuesta (que indica que ha pasado con la
petición seguido de la URL del recurso) y de la frase asociada
a dicho retorno.
 Las cabeceras del mensaje que terminan con una línea en blanco.
Son metadatos. Estas cabeceras le dan gran flexibilidad al
protocolo.
 Cuerpo del mensaje. Es opcional. Su presencia depende de la
línea anterior del mensaje y del tipo de recurso al que hace
referencia la URL. Típicamente tiene los datos que se
intercambian cliente y servidor. Por ejemplo para una petición
podría contener ciertos datos que se quieren enviar al servidor
para que los procese. Para una respuesta podría incluir los datos
que el cliente ha solicitado.
Métodos de petición[editar]

Un pedido HTTP usando telnet. El pedido (request), cabeceras de respuesta

(response headers) y el cuerpo de la respuesta (response body) están
resaltados.

HTTP define una serie predefinida de métodos de petición (algunas

veces referido como "verbos") que pueden utilizarse. El protocolo
tiene flexibilidad para ir añadiendo nuevos métodos y para así añadir
nuevas funcionalidades. El número de métodos de petición se han ido
aumentando según se avanzaban en las versiones.6 Cada método
indica la acción que desea que se efectúe sobre el recurso
identificado. Lo que este recurso representa depende de la aplicación
del servidor. Por ejemplo el recurso puede corresponderse con un
archivo que reside en el servidor.
HEAD[editar]
RFC 2616. Pide una respuesta idéntica a la que correspondería a una
petición GET, pero en la respuesta no se devuelve el cuerpo. Esto es
útil para poder recuperar los metadatos de los encabezados de
respuesta, sin tener que transportar todo el contenido.
 GET[editar]
RFC 2616. Pide una representación del recurso especificado. Por
seguridad no debería ser usado por aplicaciones que causen efectos
ya que transmite información a través de la URI agregando
parámetros a la URL. La petición puede ser simple, es decir en una
línea o compuesta de la manera que muestra el ejemplo. Ejemplo:
GET /images/logo.png HTTP/1.1 obtiene un recurso llamado logo.png
Ejemplo con parámetros:
/index.php?page=main&lang=es
POST[editar]
RFC 2616. Envía los datos para que sean procesados por el
recurso identificado. Los datos se incluirán en el cuerpo de la
petición. Esto puede resultar en la creación de un nuevo
recurso o de las actualizaciones de los recursos existentes o
ambas cosas.
PUT[editar]
RFC 2616. Sube, carga o realiza un upload de un recurso
especificado (archivo), es el camino más eficiente para subir
archivos a un servidor, esto es porque en POST utiliza
un mensaje multiparte y el mensaje es decodificado por el
servidor. En contraste, el método PUT te permite escribir un
archivo en una conexión socket establecida con el servidor.
La desventaja del método PUT es que los servidores de
hosting compartido no lo tienen habilitado. Ejemplo:
PUT /path/filename.html HTTP/1.1
DELETE[editar]
RFC 2616. Borra el recurso especificado.
TRACE[editar]
RFC 2616. Este método solicita al servidor que en la
respuesta meta todos los datos que reciba en el mensaje
de petición. Se utiliza con fines de depuración y
diagnóstico ya que el cliente puede ver lo que llega al
servidor y de esta forma ver lo que añaden al mensaje los
servidores intermedios
OPTIONS[editar]
RFC 2616. Devuelve los métodos HTTP que el servidor
soporta para un URL específico. Esto puede ser utilizado
para comprobar la funcionalidad de un servidor web
mediante petición en lugar de un recurso específico.
CONNECT[editar]
RFC 2616. Se utiliza para saber si se tiene acceso a un
host, no necesariamente la petición llega al servidor, este
método se utiliza principalmente para saber si un proxy
nos da acceso a un host bajo condiciones especiales,
como por ejemplo "corrientes" de datos bidireccionales
encriptadas (como lo requiere SSL).
PATCH[editar]
Su función es la misma que PUT, Se utiliza para
actualizar, pero la diferencia es que aqui puedes escoger
parcialmente una o varias partes.
[2]
SEARCH[editar]
[3]
COPY[editar]
RFC 2518
LOCK[editar]
RFC 2323
UNLOCK[editar]
RFC 2518
MOVE[editar]
RFC 2518
MKCOL[editar]
RFC 2518
PROPFIND[editar]
RFC 2518
PROPPATCH[editar]
RFC 2518
MERGE[editar]
RFC 3253
UPDATE[editar]
RFC 3253
LABEL[editar]
RFC 3253

Códigos de respuesta[editar]
Artículo principal: Anexo:Códigos de estado HTTP

El código de respuesta o retorno es un número que indica

que ha pasado con la petición. El resto del contenido de
la respuesta dependerá del valor de este código. El
sistema es flexible y de hecho la lista de códigos ha ido
aumentando para así adaptarse a los cambios e
identificar nuevas situaciones. Cada código tiene un
significado concreto. Sin embargo el número de los
códigos están elegidos de tal forma que según si
pertenece a una centena u otra se pueda identificar el tipo
de respuesta que ha dado el servidor:
 Códigos con formato 1xx: Respuestas informativas.
Indica que la petición ha sido recibida y se está
procesando.
 Códigos con formato 2xx: Respuestas correctas.
Indica que la petición ha sido procesada
correctamente.
 Códigos con formato 3xx: Respuestas de redirección.
Indica que el cliente necesita realizar más acciones
para finalizar la petición.
 Códigos con formato 4xx: Errores causados por el
cliente. Indica que ha habido un error en el procesado
de la petición a causa de que el cliente ha hecho algo
mal.
 Códigos con formato 5xx: Errores causados por el
servidor. Indica que ha habido un error en el
procesado de la petición a causa de un fallo en el
servidor.
Cabeceras[editar]
Artículo principal: Cabeceras HTTP

Son los metadatos que se envían en las peticiones o

respuesta HTTP para proporcionar información esencial
sobre la transacción en curso. Cada cabecera es
especificada por un nombre de cabecera seguido por dos
puntos, un espacio en blanco y el valor de dicha cabecera
seguida por un retorno de carro seguido por un salto de
línea. Se usa una línea en blanco para indicar el final de
las cabeceras. Si no hay cabeceras la línea en blanco
debe permanecer.
Las cabeceras le dan gran flexibilidad al protocolo
permitiendo añadir nuevas funcionalidades sin tener que
cambiar la base. Por eso según han ido sucediendo las
versiones de HTTP se han ido añadiendo más y más
cabeceras permitidas.
Las cabeceras pueden tener metadatos que tienen que
ser procesados por el cliente (ej. en respuesta a petición
se puede indicar el tipo del contenido que contiene), por
el servidor (ej. tipos de representaciones aceptables por
el cliente del contenido que pide) o por los intermediarios
(ej. como gestionar el cacheo por parte de los proxys)
Dependiendo del tipo de mensaje en el que puede ir una
cabecera las podemos clasificar en cabeceras de
petición, cabeceras de respuesta y cabeceras que
pueden ir tanto en un petición como en una respuesta.
Podemos clasificar las cabeceras según su función. Por
ejemplo:

 Cabeceras que indican las capacidades aceptadas

por el que envía el mensaje: Accept (indica
el MIME aceptado), Accept-Charset (indica el código
de caracteres aceptado), Accept-Encoding (indica el
método de compresión aceptado), Accept-
Language (indica el idioma aceptado), User-
Agent (para describir al cliente), Server (indica el tipo
 de servidor), Allow (métodos permitidos para el
recurso)
 Cabeceras que describen el contenido: Content-
Type (indica el MIME del contenido), Content-
Length (longitud del mensaje), Content-
Range, Content-Encoding, Content-
Language, Content-Location.
 Cabeceras que hacen referencias a
URIs: Location (indica donde está el
contenido), Referer (Indica el origen de la petición).
 Cabeceras que permiten ahorrar
transmisiones: Date (fecha de creación), If-Modified-
Since, If-Unmodified-Since, If-Match, If-None-
Match, If-Range, Expires, Last-Modified, Cache-
Control, Via, Pragma, Etag, Age, Retry-After.
 Cabeceras para control de cookies: Set-
Cookie, Cookie
 Cabeceras para autentificación: Authorization, WW-
Authenticate
 Cabeceras para describir la
comunicación: Host (indica máquina destino del
mensaje), Connection (indica como establecer la
conexión)
 Otras: Range (para descargar sólo partes del
recurso), Max-Forward (límite de cabeceras
añadidas en TRACE).
Ejemplo de diálogo HTTP[editar]
Para obtener un recurso con
el URL http://www.example.com/index.html

1. Se abre una conexión en el puerto 80 del host

www.example.com .El puerto 80 es el puerto
predefinido para HTTP. Si se quisiera utilizar el
puerto XXXX habría que codificarlo en la URL de
la forma
http://www.example.com:XXXX/index.html
2. Se envía un mensaje en el estilo siguiente:

GET /index.html HTTP/1.1

Host: www.example.com
Referer: www.google.com
User-Agent: Mozilla/5.0 (X11; Linux
x86_64; rv:45.0) Gecko/20100101
Firefox/45.0
Connection: keep-alive
[Línea en blanco]

La respuesta del servidor está formada por encabezados

seguidos del recurso solicitado, en el caso de una página
web:
 HTTP/1.1 200 OK
Date: Fri, 31 Dec 2003 23:59:59 GMT
Content-Type: text/html
Content-Length: 1221

<html lang="eo">
<head>
<meta charset="utf-8">
<title>Título del sitio</title>
</head>
<body>
<h1>Página principal de tuHost</h1>
(Contenido)
.
.
.
</body>
</html>

Protocolo seguro de transferencia de

hipertexto
(Redirigido desde «HTTPS»)

Protocolo seguro de transferencia de hipertexto

Familia Familia de protocolos de Internet

Función Transferencia segura de hipertexto

Puertos 443/TCP

Ubicación en la pila de protocolos

Aplicación HTTPS

Transporte SSL/TLS

TCP
 Red IP

Estándares

RFC 2818 – HTTP sobre TLS

[editar datos en Wikidata]

El Protocolo seguro de transferencia de hipertexto (en inglés: Hypertext Transport

Protocol Secure o HTTPS), es un protocolo de aplicación basado en el protocolo HTTP,
destinado a la transferencia segura de datos de Hipertexto, es decir, es la versión segura
de HTTP.

Características técnicas[editar]

Muchos navegadores, incluyendo Firefox (en la imagen), usa un aviso en la barra de

direcciones para indicar al usuario de quedar su conexión es segura, coloreando el fondo y con el
nombre del dueño del sitio web.
Cuando se accede a un sitio web con un certificado común, en la barra de direcciones no se observa
el dueño del sitio. En algunos navegadores, puede aparecer un símbolo de candado.

El sistema HTTPS utiliza un cifrado basado en SSL/TLS para crear un canal cifrado (cuyo
nivel de cifrado depende del servidor remoto y del navegador utilizado por el cliente) más
apropiado para el tráfico de información sensible que el protocolo HTTP. De este modo se
consigue que la información sensible (usuario y claves de paso normalmente) no pueda
ser usada por un atacante que haya conseguido interceptar la transferencia de datos de la
conexión, ya que lo único que obtendrá será un flujo de datos cifrados que le resultará
imposible de descifrar.
El puerto estándar para este protocolo es el 443.

Historia[editar]
Netscape Communications creó HTTPS en 1992 para su navegador Netscape Navigator.1
Originalmente, HTTPS era usado solamente para guardar cosas en la casa cifrado SSL,
pero esto se volvió obsoleto ante TLS. HTTPS fue adoptado como un estándar web con la
publicación de RFC 2818 en mayo del 2000.2

Diferencias con HTTP[editar]

En el protocolo HTTP las URLs comienzan con "http://" y utilizan por omisión el puerto 80,
las URLs de HTTPS comienzan con "https://" y utilizan el puerto 443 por omisión.
HTTP es inseguro y está sujeto a ataques man-in-the-middle y eavesdropping que pueden
permitir al atacante obtener acceso a cuentas de un sitio web e información confidencial.
HTTPS está diseñado para resistir esos ataques y ser más seguro.

Capas de red[editar]
HTTP opera en la capa más alta del modelo OSI, la capa de aplicación; pero el protocolo
de seguridad opera en una subcapa más baja, cifrando un mensaje HTTP previo a la
transmisión y descifrando un mensaje una vez recibido. Estrictamente hablando, HTTPS
no es un protocolo separado, pero refiere el uso del HTTP ordinario sobre una Capa de
Conexión Segura cifrada Secure Sockets Layer (SSL) o una conexión con Seguridad de la
Capa de Transporte (TLS).

Configuración del servidor[editar]

Para preparar un servidor web que acepte conexiones HTTPS, el administrador debe crear
un certificado de clave pública para el servidor web. Este certificado debe estar firmado por
una autoridad de certificación para que el navegador web lo acepte. La autoridad certifica
que el titular del certificado es quien dice ser. Los navegadores web generalmente son
distribuidos con los certificados raíz firmados por la mayoría de las autoridades de
certificación por lo que estos pueden verificar certificados firmados por ellos.
Adquisición de certificados[editar]
Adquirir certificados puede ser gratuito34 o costar entre US$135 y US$15006 por año.
Las organizaciones pueden también ser su propia autoridad de certificación,
particularmente si son responsables de establecer acceso a navegadores de sus propios
sitios (por ejemplo, sitios en la intranet de una empresa, o grandes universidades). Estas
pueden fácilmente agregar copias de su propio certificado firmado a los certificados de
confianza distribuidos con el navegador.
También existen autoridades de certificación peer-to-peer.
Usar un control de acceso[editar]
El sistema puede también ser usado para la autenticación de clientes con el objetivo de
limitar el acceso a un servidor web a usuarios autorizados. Para hacer esto el
administrador del sitio típicamente crea un certificado para cada usuario, un certificado que
es guardado dentro de su navegador. Normalmente, este contiene el nombre y la dirección
de correo del usuario autorizado y es revisado automáticamente en cada reconexión para
verificar la identidad del usuario, potencialmente sin que cada vez tenga que ingresar una
contraseña.
En caso de claves privadas comprometidas[editar]
Un certificado puede ser revocado si este ya ha expirado, por ejemplo cuando el secreto
de la llave privada ha sido comprometido. Los navegadores más nuevos como
son Firefox,7 Opera,8 e Internet Explorer sobre Windows Vista9 implementan el Protocolo
de Estado de Certificado Online (OCSP) para verificar que ese no es el caso. El navegador
envía el número de serie del certificado a la autoridad de certificación o, es delegado vía
OCSP y la autoridad responde, diciéndole al navegador si debe o no considerar el
certificado como válido.10

Adopción de HTTPS[editar]
En febrero de 2017, la adopción HTTPS fue:
Argentina: 9,77% del total de dominios.11
España: 5,11% del total de dominios.12
México: 13.31% del total de dominios.13
Chile: 18,71% del total de dominios.14
Colombia: 4,85% del total de dominios.15
Desde Google están intentando incentivar el uso de https para mejorar la seguridad de
transferencia de información en internet. Actualmente, desde su navegador Chrome
marcan como "no seguras" las urls bajo http y según las comunicaciones de la
compañía en un futuro marcarán como "no seguras" todas las webs que no estén bajo
https. Esto está aumentando la tasa de implementación de certificados SSL y cada vez
más webs están bajo https.

Limitaciones[editar]
El nivel de protección depende de la exactitud de la implementación del navegador web, el
software del servidor y los algoritmos de cifrado actualmente soportados. Vea la lista
en Idea Principal.
También, HTTPS es vulnerable cuando se aplica a contenido estático de publicación
disponible. El sitio entero puede ser indexado usando una araña web, y la URI del recurso
cifrado puede ser adivinada conociendo solamente el tamaño de la petición/respuesta.16
Esto permite a un atacante tener acceso al texto plano (contenido estático de publicación),
y al texto cifrado (La versión cifrada del contenido estático), permitiendo un ataque
criptográfico.
Debido a que SSL opera bajo HTTP y no tiene conocimiento de protocolos de nivel más
alto, los servidores SSL solo pueden presentar estrictamente un certificado para una
combinación de puerto/IP en particular17 Esto quiere decir, que en la mayoría de los casos,
no es recomendable usar Hosting virtual name-based con HTTPS. Existe una solución
llamada Server Name Indication (SNI) que envía el hostname al servidor antes de que la
conexión sea cifrada, sin embargo muchos navegadores antiguos no soportan esta
extensión. El soporte para SNI está disponible desde Firefox 2, Opera 8, e Internet
Explorer 7 sobre Windows Vista.
 Dominio de Internet
(Redirigido desde «Dominio de internet»)

Este artículo o sección necesita ser wikificado, por favor, edítalo para que
las cumpla con las convenciones de estilo.
Este aviso fue puesto el 12 de enero de 2016.

Calle dedicada al dominio "Punto Net", en el Parque Científico Tecnológico de la Universidad de

Alcalá.

Extensión o dominio de Internet es un nombre único que identifica a un sitio web

en Internet.
El propósito principal de los nombres de dominio en Internet y del sistema de nombres de
dominio (DNS), es traducir las direcciones IP de cad activo en la red, a términos
memorizables y fáciles de encontrar. Esta abstracción hace posible que cualquier servicio
(de red) pueda moverse de un lugar geográfico a otro en la Internet, aun cuando el cambio
implique que tendrá una dirección IP diferente.1
Sin la ayuda del sistema de nombres de dominio, los usuarios de Internet tendrían que
acceder a cada servicio web utilizando la dirección IP del nodo (por ejemplo, sería
necesario utilizar http://172.217.10.110/ en vez de http://google.com). Además, reduciría el
número de webs posibles, ya que actualmente es habitual que una misma dirección IP sea
compartida por varios dominios.

Índice
[ocultar]

 1URL frente a nombre de dominio

 2Dominios de nivel superior
o 2.1Dominios ccTLD asignados
o 2.2Ejemplos de nombres de dominio de nivel superior
o 2.3Nombres de dominio internacionalizado
 3Organizaciones relacionadas con los dominios de Internet
o 3.1IANA
o 3.2ICANN y la asignación oficial
o 3.3INTERNIC
o 3.4LACNIC
o 3.5LACTLD
 4Véase también
 5Referencias

URL frente a nombre de dominio[editar]

El siguiente ejemplo ilustra la diferencia entre una URL (uniform resource locator o
«localizador de recurso uniforme») y un nombre de dominio2:
 Nombre de dominio: wikipedia.org
 URL: https://www.wikipedia.org

Dominios de nivel superior[editar]

Cuando se creó el Sistema de Nombres de Dominio en los años 1980, el espacio de
nombres se dividió en dos grupos. El primero incluye los dominios territoriales, basados en
los dos caracteres de identificación de cada territorio de acuerdo a las abreviaciones del
ISO-3166 (ej. *.do, *.mx), denominados ccTLD (country code top level domain o «dominio
de nivel superior geográfico»). El segundo grupo incluye dominios de nivel superior
genéricos (gTLD), que representan una serie de nombres y multiorganizaciones.
Inicialmente, estos dominios fueron: COM, NET, ORG, EDU, GOB y MIL, a los que
posteriormente se unieron otros.
Los dominios basados en ccTLD son administrados por organizaciones sin fines de lucro
en cada país, delegada por la IANA y o ICANN para la administración de los dominios
territoriales3.
El crecimiento de Internet ha implicado la creación de nuevos dominios gTLD. A mayo de
2012, existen 22 gTLD y 293 ccTLD.4
Dominios ccTLD asignados[editar]
La lista de dominios de nivel superior pueden encontrarse en el anexo.
Ejemplos de nombres de dominio de nivel superior[editar]

 .ac, para servicios de Isla Ascensión, pero usado también para personas con título
profesional o académico, o que estén acreditados por un instituto u organización
comercial o instituciones académicas.
 .ar, para servicios de Argentina
 .at, para servicios de Austria
 .asia, la región de Asia
 .au, para servicios de Australia
 .be, para servicios de Bélgica
 .biz previsto para ser usado en negocios.
 .bo, para servicios de Bolivia
 .br, para servicios de Brasil
 .bg, para servicios de Bulgaria
 .ca, para servicios de Canadá
 .cat, para páginas relacionadas con la cultura e idioma catalán
 .cc, para servicios Islas Cocos
 .ch, para servicios de Suiza
 .cl, para servicios de Chile
 .co, para servicios de Colombia
 .cn, para servicios de República Popular de China
 .com, son los dominios más extendidos en el mundo. Sirven para cualquier tipo
de página web, temática
 .cr, para servicios de Costa Rica
 .cu, para servicios de Cuba
 .de, para servicios de Alemania
 .dk, para servicios de Dinamarca
 .do, para servicios de República Dominicana
 .ec, para servicios de Ecuador
 .edu, para servicios de Educación
 .es, para servicios de España
 .eu, para países de Unión Europea
 .eus, para páginas relacionadas con la cultura e idioma euskaldun.
 .fi, para servicios de Finlandia
 .fm, para páginas de Micronesia, pero usado también para estaciones de radio
de frecuencia modulada
 .fr, para servicios de Francia
 .fo, para servicios de Islas Feroe
 .gal, para páginas relacionadas con la cultura y lengua (Gallegos).
 .gov y .gob, para gobierno y entidades públicas
 .gr, para servicios de Grecia
 .gt, para servicios de Guatemala
 .hn, para servicios de Honduras
 .hr, para servicios de Croacia
 .info, para información
 .int, para entidades internacionales, organizaciones como la Organización de las
Naciones Unidas
 .il, para servicios de Israel
 .it, para servicios de Italia
 .jobs, para departamentos de empleo y recursos humanos en empresas
 .jp, para servicios de Japón
 .kp, para servicios de Corea del Norte
 .kr, para servicios de Corea del Sur
 .lat, la región de Latinoamérica
 .lu, para servicios de Luxemburgo
 .ma, para servicios de Marruecos
 .me, para servicios de Montenegro
 .mil, para el Departamento de Defensa de los Estados Unidos (Único país con dominio
de primer nivel para el ejército)
 .mobi, para empresas de telefonía móvil o servicios para móvil.
 .museum, para los museos
 .mx, para servicios de México
 .ni, para compañías y servicios de Nicaragua
 .no, para compañías y servicios de Noruega
 .name, para nombres de personas
 .net, para infraestructura de red
 .nl, para páginas de Países Bajos
 .nz, para páginas de Nueva Zelanda
 .org, para organizaciones
 .pa, para páginas de Panamá
 .pe, para páginas de Perú
 .pl, para páginas de Polonia
 .pro, para profesionales con una titulación universitaria.
 .pt, para servicios de Portugal
 .py, para servicios de Paraguay
 .ro, para servicios de Rumania
 .rs, para servicios de Serbia
 .ru, para servicios de Rusia
 .sa para páginas de Arabia Saudita
 .se, para servicios de Suecia
 .si, para servicios de Eslovenia
 .sv, para servicios de El Salvador
 .tel, para servicios de comunicación por internet
 .tk, para páginas del país Tokelau; sin embargo se usan también como dominio y
servidor propio ( "Autónomas" ). Actualmente pueden obtenerse de forma gratuita.
 .travel, para páginas de la industria de viajes y turismo.
 .tv, para páginas del país Tuvalu, pero usado también para estaciones de
televisión.
 .ua, para páginas de Ucrania
 .uk, para páginas de Reino Unido
 .uy, para servicios de Uruguay
 .va, para servicios de Ciudad del Vaticano
 .ve, para servicios de Venezuela
 .web es un dominio de internet de nivel superior, no oficial, que lleva propuesto desde
1995.
 .ws para páginas de Samoa
 .xxx, para Industria pornográfica
 .za para páginas de Sudáfrica
 .рф, para páginas de Rusia con nombres en cirilico
Nombres de dominio internacionalizado[editar]
Artículo principal: Nombre de dominio internacionalizado

El juego de caracteres permitidos en el sistema de nombres de dominio se basa en ASCII

y no permite la representación de nombres y palabras de muchos idiomas nativos en sus
guiones o alfabetos. ICANN aprobó el nombre de dominio internacionalizado (IDNA), el
cual asigna las cadenas Unicode utilizados en las interfaces de usuario en el conjunto de
caracteres DNS válido por una codificación llamado Punycode. Por ejemplo, københavn.eu
se asigna a xn - kbenhavn-54a.eu. Muchos registros han adoptado IDNA.

Organizaciones relacionadas con los dominios de

Internet[editar]
IANA[editar]
IANA es la Autoridad para la Asignación de Letras de Internet (del inglés: Internet Assigned
Numbers Authority), responsable de la coordinación global de los dominios Raíz de DNSy
de los dominios .int y .arpa, del direccionamiento IP y otros recursos del protocolo de
Internet.5
ICANN y la asignación oficial[editar]
La Corporación de Internet para la Asignación de nombres y números de Dominios (del
inglés: Internet Corporation for Assigned Names and Numbers) es una organización sin
fines de lucro que opera a nivel de asignar espacio de direcciones numéricas de protocolo
de Internet (IP), identificadores de protocolo y de las administración del sistema de
servidores raíz. Aunque en un principio estos servicios los desempeñaba Internet Assigned
Numbers Authority (IANA) y otras entidades bajo contrato con el gobierno de EE. UU.,
actualmente son responsabilidad de ICANN.6
INTERNIC[editar]
InterNIC es un servicio y marca registrada del Ministerio de Comercio de los Estados
Unidos y licenciado a IANA para la gestión de disputas públicas relacionadas con el
registro de nombres de dominios.
LACNIC[editar]
LACNIC es la organización para el Registro de Direcciones de Internet para América
Latina y el Caribe. Su objetivo es la construcción y articulación de esfuerzos colaborativos
para el desarrollo y estabilidad de Internet en América Latina y el Caribe. [1]. Si bien no
tiene relación directa con los dominios, sí es la organización regional a cargo de los
recursos de Internet como direcciones IP y ASNs.
LACTLD[editar]
LACTLD es una organización sin fines de lucro que busca agrupar a los administradores
de los ccTLDs de América Latina y el Caribe, con el objeto de Coordinar políticas en
conjunto, así como estrategias de desarrollo de los nombres de dominio a nivel regional;
representar los intereses conjuntos de sus miembros ante organismos pertinentes;
promover el desarrollo de los ccTLDs de la región; fomentar la cooperación y el
intercambio de experiencia entre sus miembros, en todos los aspectos necesarios para el
adecuado funcionamiento de los ccTLDs y establecer lazos de colaboración con las
organizaciones análogas de otras regiones del mundo.