You are on page 1of 14

Servidor web

Un servidor web o servidor HTTP es un programa informtico que procesa una aplicacin del lado del servidor realizando conexiones bidireccionales y/o unidireccionales y sncronas o asncronas con el cliente generando o cediendo una respuesta en cualquier lenguaje o Aplicacin del lado del cliente. El cdigo recibido por el cliente suele ser compilado y ejecutado por un navegador. Para la transmisin de todos estos datos suele utilizarse algn protocolo. Generalmente se utiliza el protocolo HTTP para estas comunicaciones, perteneciente a la capa de aplicacin del modelo OSI. El trmino tambin se emplea para referirse al ordenador que ejecuta el programa.

Arquitectura
Peticin GET
Un servidor web opera mediante el protocolo HTTP, de la capa de aplicacin del Modelo OSI. Al protocolo HTTP se le asigna habitualmente el puerto TCP 80. Las peticiones al servidor suelen realizarse mediante HTTP utilizando el mtodo de peticin GET en el que el recurso se solicita a travs de la url al servidor web. GET /index.html HTTP/1.1 HOST: www.host.com En la barra de URL de un navegador cualquiera la peticin anterior sera anloga a la siguiente direccin Web: www.host.com/index.html

Esquema de una peticin GET


Peticin Web
El navegador por medio de la interfaz de usuario permite al usuario realizar una o varias peticiones web. La interfaz de usuario o entorno de usuario es el conjunto de elementos del navegador que permiten realizar la peticin de forma activa. Una peticin Web no slo puede ser realizada mediante un navegador sino con cualquier herramienta habilitada para tal fin, como una consola de comandos Telnet. Elementos del entorno de usuario ms comunes en navegadores Web visuales:

Nombre

Descripcin

Hipervnculo enlace o link

Es una porcin de contenido Web, texto, imagen y otros elementos, que enlaza con una direccin Web. Al pulsar un hipervnculo el navegador genera una peticin GET automtica a la direccin URL de dicho link.

Formulario web

Al realizar el envo satisfactorio de los datos de un formulario, el navegador Web genera una peticin GET o POST (comnmente POST) automtica a la par que enva los datos al servidor.

Barra de

Todos los navegadores incluyen una barra de direcciones mediante la cual

direcciones

puede accederse manualmente a cualquier direccin URL, de modo que el navegador generar una peticin GET automtica a dicha URL cada vez que el usuario lo desee.

Script activo o pasivo

Cualquier aplicacin Javascript tiene acceso al estado del navegador, cmo puede modificar los datos que describen tal estado, de forma pasiva (sin medio de la intervencin del usuario) o de forma activa (mediante alguna accin del usuario).

1.1 Socket a direccin DNS


Se produce una socket con un servidor dado en direccin IP mediante TCP. Por lo general las direcciones que el navegador posee inicialmente son direcciones DNS (direcciones alfanumricas) que deber convertir a direcciones numricas.

1.2 Resolucin de DNS a IP


Si la direccin dada es DNS y no existe una regla en la base de datos DNS, el Host Resolver Request solicita al servidor DNS la o las direcciones IPs correspondientes. El navegador crea una nueva regla y almacena la direccin IP junto a la direccin DNS en su base de datos de reglas DNS.

1.3 Recuperacin de la regla DNS


Una vez almacenada la regla se realiza una peticin a la base de datos DNS para recuperar los valores de la regla.

1.4 Socket a direccin IP


Se produce una socket con la direccin IP mediante TCP. La direccin IP puede haberse recuperado en el paso anterior.
SOCKET 192.168.0.1

1.5 Preparacin de la peticin


Se crea la peticin GET estableciendo la url, un flag, la priority de la peticin y el method (implcitamente GET).

1.6 Apertura Cach


Se abre y/o se crea una entrada en el http cache

1.7 Efectuacin de la peticin


Se realiza la peticin GET. Se leen las cabeceras HTTP de la http transaction y ms tarde el cuerpo de la http transaction.
GET /index.html HTTP/1.1

1.8 Consulta en Cach


Se consulta en el cach de disco si existe una entrada en el cach asociada al recurso que se ha solicitado. Los valores son created (true o false) y key (la url del recurso).

1.9 Retribucin boleana existencialista del recurso solicitado


Si la entrada no existe (si el valor de created es false) se escriben los datos en el cach de disco. Si no, se lee directamente.

2.0 Presentacin visual del recurso


Se concluye la operacin y se muestra en pantalla (si es preciso) la informacin.

Peticin GET pasiva


Javascript permite realizar modificaciones en el estado del navegador. El estado del navegador viene definido por el array de objetos location del objeto global Window. Se referencia a tal objeto con window.location. En concreto window.location.href contiene la direccin actual del navegador Web. Si una parte del script ejecuta tal sentencia: window.location.href='http://www.google.com.pe'; El navegador har tal peticin Web sin que el usuario haya mediado en tal circunstancia o sus efectos. Del mismo modo se producir una nueva peticin GET si se altera el valor de window.location.search o window.location.protocol.

Procedimiento del navegador


La tarea del navegador Web es crear la peticin a partir de los datos recogidos en el entorno de usuario de elementos del mismo, como enlaces, el valor del texto de la barra de bsqueda, los metatags. <a href="http://www.google.com.pe">Entrar</a>

Al pulsar en el enlace, el navegador crea automticamente la peticin GET y las cabeceras de la peticin en base a los metatags (cabeceras definidas), los cookies y cabeceras automticas del navegador, para luego enviarlas junto a la peticin al Servidor.

Peticin POST
Es el segundo tipo de peticin HTTP ms utilizado. Los datos a enviar al servidor se incluyen en el cuerpo de la misma peticin con las cabeceras HTTP asignadas correspondientemente respecto al tipo de peticin. Generalmente se asocia con los formularios web en el que los datos suelen ser cifrados para enviarlos de manera segura al servidor. Por motivos de convencin se incluye en la peticin la cabecera application/x-www-formurlencoded que indica el formato o codificacin de los datos a enviar; esta es variable>valor en el formato: variable=valor separada cada par variable->valor por &. Esta cabecera, en los formularios HTML se enva automticamente, pero en otras tecnologas web tal como AJAX, si se desea hacer correctamente una peticin POST debe ser especificado o instanciado el objeto: setRequestHeader("Content-type:application/x-www-formurlencode");ajax.send(data); Si se utilizase el mtodo GET los datos deberan de ser aadidos a la URL, lo que los expondra a ser vistos de forma directa.

Estructura de una peticin POST

Estructura tpica de una peticin POST

Muestra

Petition type

POST url HTTP/1.1 POST comment.php HTTP/1.1

Referer

http-url-referer

index.php

ContentLength

contentlenght-int 63

Origin

http-url-origin

http://www.google.com.pe Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) ...

User-Agent

useragent-string

ContentType

content-typestring mimetypes-

application/x-www-form-urlencoded

Accept

accepted-string languageaccepted-string charset-acceptedstring phpsessid-string accept-encodingstring Content-string

application/xml,application/xhtml+xml ...

AcceptLanguage

es-ES,es;q=0.8

AcceptCharset

ISO-8859-1,utf-8;q=0.7,*;q=0.3

Cookie

PHPSESSID=gm0ugf96iojuldio8i51u92716

AcceptEncoding

gzip,deflate,sdch

Content

&data=4&lang=es+es

Composicin de una peticin POST


Las cabeceras ms comunes que se envan en una peticin POST:

Petition type: Especifica el tipo de peticin HTTP. (Esta cabecera no tiene nombre, se enva tal cual) Referer: Especifica la url desde la cual se hizo la peticin POST. Content-Length: Especifica la longitud en bytes de los datos enviados en el cuerpo de la peticin. Origin: Especifica la url principal del sitio. User-Agent:Especifica el identificador del navegador Web desde el cual se hizo la peticin. Content-Type: Especifica el formato o MIME de los datos enviados en el cuerpo de la peticin. Accept: Especifica el MIME que se espera en la respuesta. Accept-Language: Especifica el cdigo del lenguaje esperado en la respuesta. Accept-Charset: Especifica la codificacin que se espera en la respuesta. Cookie: Especifica un identificador de sesin en la peticin derivado de un cookie. Accept-Encoding: Especifica el tipo de codificacin (generalmente compresin) que se espera de la respuesta. (No todos los navegadores envan esta cabecera)

Estructura de una respuesta POST

Estructura tpica de una respuesta POST Muestra

HTTP version & state HTTP-version-state HTTP/1.1 200 OK

Date

date-string

Tue, 07 Jun 2011 05:52:31 GMT

Server

server-string

Apache/2.2.17 (Win32) mod_ssl/2.2.17...

Expires

expire-date-string

Thu, 19 Nov 1981 08:52:00 GMT

Cache-Control

Cache-control-string no-store, no-cache, must-revalidate...

Pragma

pragma-string

no-cache

Content-Length

Content-length-int

297

Content-Type

Content-type-string

text/html

Keep-Alive

Keep-alive-string

timeout=5, max=98

Connection

Connection-string

Keep-Alive

X-Powered-By

X-powered-by-string PHP/5.3.5

Codificacin del mensaje del cuerpo de la peticin


Los datos que se envan en el cuerpo de la peticin POST deben tener algn formato que permita manipularlos en un futuro procesamiento. Por ello la peticin debe tener asignada la cabecera Content-Type cuyo valor ser la codificacin de los datos. De este modo el sistema podr diferenciar entre variables aisladas, datos binarios, texto plano, o cualquier otro tipo de formato. El formato de una cadena de datos se denomina MIME y es el valor que deber ser incluido en esta cabecera. En HTML la cabecera Content-Type se especifica automticamente y su valor es application/xwww-form-urlencoded, no obstante pueden especificarse por estndar otros dos valores:multipart/form-data y text/plain utilizando el atributo enctype del elemento form de la siguiente manera

<form enctype="multipart/form-data">...</form>

<form enctype="text/plain">...</form>

<form enctype="application/x-www-form-urlencoded">...</form> O cualquier otro valor MIME. El multipart/form-data se utiliza para enviar grandes cadenas binarias que suponen cualquier otro tipo de documento que no sea texto plano, como imgenes, vdeos o ejecutables. Para varios valores, separar por comas. El application/x-www-form-urlencoded codifica de forma automtica los valores de todos los elementos del formulario del modo variable=valor, separados por &. El atributo name de un input suele ser el nombre de la variable y su value el valor. Los espacios se reemplazan por + y los caracteres no alfanumricos por $HH donde HH representa el nmero hexadecimal del carcter ASCII.

id=valor+de+la+variable&tama%A4o=4

que representado de otra forma es:

id: valor de la variable

tamao: 4

Procedimiento del navegador


El navegador recopila la informacin del formulario para crear la peticin y enviarla. Las cabeceras las enva junto a la peticin POST, y se recopilan en base a los metatags definidos en el cdigo, los automticos del navegador y los Cookies. Es el navegador, tambin, el que codifica los datos si es necesario.

Funcionamiento

Servidor

El Servidor web se ejecuta en un ordenador mantenindose a la espera de peticiones por parte de un cliente (un navegador web) y que responde a estas peticiones adecuadamente, mediante una pgina web que se exhibir en el navegador o mostrando el respectivo mensaje si se detect algn error. A modo de ejemplo, al teclear www.google.com en nuestro navegador, ste realiza una peticin HTTP al servidor de dicha direccin. El servidor responde al cliente enviando el cdigo HTML de la pgina; el cliente, una vez recibido el cdigo, lo interpreta y lo exhibe en pantalla. Como vemos con este ejemplo, el cliente es el encargado de interpretar el cdigo HTML, es decir, de mostrar las fuentes, los colores y la disposicin de los textos y objetos de la pgina; el servidor tan slo se limita a transferir el cdigo de la pgina sin llevar a cabo ninguna interpretacin de la misma. Adems de la transferencia de cdigo HTML, los Servidores web pueden entregar aplicaciones web. stas son porciones de cdigo que se ejecutan cuando se realizan ciertas peticiones o respuestas HTTP. Hay que distinguir entre: Aplicaciones en el lado del cliente: el cliente web es el encargado de ejecutarlas en la mquina del usuario. Son las aplicaciones tipo Java "applets" o Javascript: el servidor proporciona el cdigo de las aplicaciones al cliente y ste, mediante el navegador, las ejecuta. Es necesario, por tanto, que el cliente disponga de un navegador con capacidad para ejecutar aplicaciones (tambin llamadas scripts). Comnmente, los navegadores permiten ejecutar aplicaciones escritas en lenguaje javascript y java, aunque pueden aadirse ms lenguajes mediante el uso de plugins. Aplicaciones en el lado del servidor: el servidor web ejecuta la aplicacin; sta, una vez ejecutada, genera cierto cdigo HTML; el servidor toma este cdigo recin creado y lo enva al cliente por medio del protocolo HTTP.

Las aplicaciones de servidor muchas veces suelen ser la mejor opcin para realizar aplicaciones web. La razn es que, al ejecutarse sta en el servidor y no en la mquina del cliente, ste no necesita ninguna capacidad aadida, como s ocurre en el caso de querer ejecutar aplicaciones javascript o java. As pues, cualquier cliente dotado de un navegador web bsico puede utilizar este tipo de aplicaciones. El hecho de que HTTP y HTML estn ntimamente ligados no debe dar lugar a confundir ambos trminos. HTML es un lenguaje de marcas y HTTP es un "protocolo".

Aplicacin del lado del Servidor


Una aplicacin del lado del servidor es cualquier programa o conjunto de instrucciones diseadas con la finalidad de que un Servidor Web las procese para realizar alguna accin. Las aplicaciones del lado del servidor estn escritas mediante algn lenguaje de programacin, entre los que destacan: Lenguaje Fecha de primera versin estable 1995 Sistema operativo ltima versin estable 5.3.5

PHP

Multiplataforma Windows (Algunas versiones) Multiplataforma Multiplataforma Multiplataforma

ASP.Net

1998

4.0

Perl Python Ruby

1987 1991 1995

5.12.3 3.2.0 1.9.3-p125

El 75% de las aplicaciones del lado del servidor estn escritas en PHP, seguido de ASP y las dems opciones usadas de forma alternativa y muy casual. En 2009 Node.js fue creado por Ryan Dahl, abriendo pblicamente la oportunidad de usar javascript del lado del servidor. Evento que revoluciona la web, y da inicio a una nueva era del desarrollo en internet. Node.js, dado a sus usuarios, programadores web de todo el mundo, est creciendo como la mejor opcin para desarrollo de aplicaciones del lado del servidor, desplazando lenguajes tradicionales en esta tarea. Node.js trabaja sobre el rpido motor V8 que usa Google Chrome para la interpretacin de javascript.

Procesamiento del lado del servidor


Un servidor web tiene la funcin de procesar los scripts del lado del servidor para dar una salida en HTML y otros lenguajes del lado del cliente al Navegador Web del cliente. La informacin a procesar podr ser cedida por el cliente al script mediante cualquier aplicacin en el entorno del Navegador. Para ello pueden utilizarse formularios web, enlaces con los valores implcitos en la cadena o cualquier otro mtodo.

Rack con servidores

Servidor Web Local


Un Servidor Web Local es aquel Servidor Web que reside en una red local al equipo de referencia. El Servidor web Local puede estar instalado en cualquiera de los equipos que forman parte de una red local. Es por tanto obvio, que todos los Servidores Web, son locales a la red local en la que se encuentran, o como mnimo, locales al sistema en el que estn instalados. Cuando un servidor Web se encuentra instalado en el mismo equipo desde el cual se desea acceder puede utilizarse la direccin de Loopback, 127.0.0.1 en Ipv4 y ::1 en Ipv6. El puerto TCP80 se obvia. Los archivos se almacenan en un directorio determinado por la configuracin, generalmente modificable. Existen numerosas aplicaciones que facilitan la instalacin automtica de servidores web Apache y aplicaciones adicionales como Mysql y PHP (entre otros), de forma conjunta, como XAMPP, JAMP o EasyPHP. Estas aplicaciones reciben el nombre de LAMP cuando se instalan en plataformas Linux, WAMP en sistemas Windows y MAMP en sistemas Apple Macintosh.

Domain Name System


Domain Name System o DNS (en espaol: sistema de nombres de dominio) es un sistema de nomenclatura jerrquica para computadoras, servicios o cualquier recurso conectado a Internet o a una red privada. Este sistema asocia informacin variada con nombres de dominios asignado a cada uno de los participantes. Su funcin ms importante, es traducir (resolver) nombres inteligibles para las personas en identificadores binarios asociados con los equipos conectados a la red, esto con el propsito de poder localizar y direccionar estos equipos mundialmente. El servidor DNS utiliza una base de datos distribuida y jerrquica que almacena informacin asociada a nombres de dominio en redes como Internet. Aunque como base de datos el DNS es capaz de asociar diferentes tipos de informacin a cada nombre, los usos ms comunes son la asignacin de nombres de dominio a direcciones IP y la localizacin de los servidores de correo electrnico de cada dominio. La asignacin de nombres a direcciones IP es ciertamente la funcin ms conocida de los protocolos DNS. Por ejemplo, si la direccin IP del sitio FTP de prox.mx es 200.64.128.4, la mayora de la gente llega a este equipo especificando ftp.prox.mx y no la direccin IP. Adems de ser ms fcil de recordar, el nombre es ms fiable. La direccin numrica podra cambiar por muchas razones, sin que tenga que cambiar el nombre. Inicialmente, el DNS naci de la necesidad de recordar fcilmente los nombres de todos los servidores conectados a Internet. En un inicio, SRI (ahora SRI International) alojaba un archivo llamado HOSTS que contena todos los nombres de dominio conocidos. El crecimiento explosivo de la red caus que el sistema de nombres centralizado en el archivo hosts no resultara prctico y en 1983, Paul V. Mockapetris public los RFC 882 y RFC 883 definiendo lo que hoy en da ha evolucionado hacia el DNS moderno. (Estos RFCs han quedado obsoletos por la publicacin en 1987 de los RFCs 1034 y RFC 1035).

Componentes
Para la operacin prctica del sistema DNS se utilizan tres componentes principales: Los Clientes fase 1: Un programa cliente DNS que se ejecuta en la computadora del usuario y que genera peticiones DNS de resolucin de nombres a un servidor DNS (Por ejemplo: Qu direccin IP corresponde a nombre de dominio?); Los Servidores DNS: Que contestan las peticiones de los clientes. Los servidores recursivos tienen la capacidad de reenviar la peticin a otro servidor si no disponen de la direccin solicitada. Y las Zonas de autoridad, porciones del espacio de nombres raros de dominio que almacenan los datos. Cada zona de autoridad abarca al menos un dominio y posiblemente sus subdominios, si estos ltimos no son delegados a otras zonas de autoridad

Entendiendo las partes de un nombre de dominio


Un nombre de dominio usualmente consiste en dos o ms partes (tcnicamente etiquetas), separadas por puntos cuando se las escribe en forma de texto. Por ejemplo, www.example.com owww.wikipedia.es A la etiqueta ubicada ms a la derecha se le llama dominio de nivel superior (en ingls top level domain). Como org en www.ejemplo.org o es en www.wikipedia.es Cada etiqueta a la izquierda especifica una subdivisin o subdominio. Ntese que "subdominio" expresa dependencia relativa, no dependencia absoluta. En teora, esta subdivisin puede tener hasta 127 niveles, y cada etiqueta puede contener hasta 63 caracteres, pero restringidos a que la longitud total del nombre del dominio no exceda los 255 caracteres, aunque en la prctica los dominios son casi siempre mucho ms cortos. Finalmente, la parte ms a la izquierda del dominio suele expresar el nombre de la mquina (en ingls hostname). El resto del nombre de dominio simplemente especifica la manera de crear una ruta lgica a la informacin requerida. Por ejemplo, el dominio es.wikipedia.org tendra el nombre de la mquina "es", aunque en este caso no se refiere a una mquina fsica en particular. El DNS consiste en un conjunto jerrquico de servidores DNS. Cada dominio o subdominio tiene una o ms zonas de autoridad que publican la informacin acerca del dominio y los nombres de servicios de cualquier dominio incluido. La jerarqua de las zonas de autoridad coincide con la jerarqua de los dominios. Al inicio de esa jerarqua se encuentra los servidores raz: los servidores que responden cuando se busca resolver un dominio de primer y segundo nivel.

DNS en el mundo real


Los usuarios generalmente no se comunican directamente con el servidor DNS: la resolucin de nombres se hace de forma transparente por las aplicaciones del cliente (por ejemplo, navegadores, clientes de correo y otras aplicaciones que usan Internet). Al realizar una peticin que requiere una bsqueda de DNS, la peticin se enva al servidor DNS local del sistema operativo. El sistema operativo, antes de establecer alguna comunicacin, comprueba si la respuesta se encuentra en la memoria cach. En el caso de que no se encuentre, la peticin se enviar a uno o ms servidores DNS. La mayora de usuarios domsticos utilizan como servidor DNS el proporcionado por el proveedor de servicios de Internet. La direccin de estos servidores puede ser configurada de forma manual o automtica mediante DHCP. En otros casos, los administradores de red tienen configurados sus propios servidores DNS.

En cualquier caso, los servidores DNS que reciben la peticin, buscan en primer lugar si disponen de la respuesta en la memoria cach. Si es as, sirven la respuesta; en caso contrario, iniciaran la bsqueda de manera recursiva. Una vez encontrada la respuesta, el servidor DNS guardar el resultado en su memoria cach para futuros usos y devuelve el resultado.

Jerarqua DNS

El espacio de nombres de dominio tiene una estructura arborescente. Las hojas y los nodos del rbol se utilizan como etiquetas de los medios. Un nombre de dominio completo de un objeto consiste en la concatenacin de todas las etiquetas de un camino. Las etiquetas son cadenas alfanumricas (con '-' como nico smbolo permitido), deben contar con al menos un carcter y un mximo de 63 caracteres de longitud, y deber comenzar con una letra (y no con '-') (ver la RFC 1035, seccin "2.3.1. Preferencia nombre de la sintaxis "). Las etiquetas individuales estn separadas por puntos. Un nombre de dominio termina con un punto (aunque este ltimo punto generalmente se omite, ya que es puramente formal). Un FQDN correcto (tambin llamado Fully Qualified Domain Name), es por ejemplo este: www.example.com. (Incluyendo el punto al final) Un nombre de dominio debe incluir todos los puntos y tiene una longitud mxima de 255 caracteres.

Un nombre de dominio se escribe siempre de derecha a izquierda. El punto en el extremo derecho de un nombre de dominio separa la etiqueta de la raz de la jerarqua (en ingls, root). Este primer nivel es tambin conocido como dominio de nivel superior (TLD - Top Level Domain). Los objetos de un dominio DNS (por ejemplo, el nombre del equipo) se registran en un archivo de zona, ubicado en uno o ms servidores de nombres.

Tipos de servidores DNS


Primarios o maestros: Guardan los datos de un espacio de nombres en sus ficheros Secundarios o esclavos: Obtienen los datos de los servidores primarios a travs de una transferencia de zona. Locales o cach: Funcionan con el mismo software, pero no contienen la base de datos para la resolucin de nombres. Cuando se les realiza una consulta, estos a su vez consultan a los servidores DNS correspondientes, almacenando la respuesta en su base de datos para agilizar la repeticin de estas peticiones en el futuro continuo o libre.

Tipos de resolucin de nombres de dominio


Existen dos tipos de consultas que un cliente puede hacer a un servidor DNS, la iterativa y la recursiva.

Resolucin iterativa
Las resoluciones iterativas consisten en la respuesta completa que el servidor de nombres pueda dar. El servidor de nombres consulta sus datos locales (incluyendo su cach) buscando los datos solicitados. El servidor encargado de hacer la resolucin realiza iterativamente preguntas a los diferentes DNS de la jerarqua asociada al nombre que se desea resolver, hasta descender en ella hasta la mquina que contiene la zona autoritativa para el nombre que se desea resolver.

Resolucin recursiva
En las resoluciones recursivas, el servidor no tiene la informacin en sus datos locales, por lo que busca y se pone en contacto con un servidor DNS raz, y en caso de ser necesario repite el mismo proceso bsico (consultar a un servidor remoto y seguir a la siguiente referencia) hasta que obtiene la mejor respuesta a la pregunta. Cuando existe ms de un servidor autoritario para una zona, Bind utiliza el menor valor en la mtrica RTT (round-trip time) para seleccionar el servidor. El RTT es una medida para determinar cunto tarda un servidor en responder una consulta. El proceso de resolucin normal se da de la siguiente manera: 1. El servidor A recibe una consulta recursiva desde el cliente DNS. 2. El servidor A enva una consulta recursiva a B. 3. El servidor B refiere a A otro servidor de nombres, incluyendo a C. 4. El servidor A enva una consulta recursiva a C. 5. El servidor C refiere a A otro servidor de nombres, incluyendo a D. 6. El servidor A enva una consulta recursiva a D. 7. El servidor D responde. 8. El servidor A regresa la respuesta al resolver.

9. El resolver entrega la resolucin al programa que solicit la informacin.

Tipos de registros DNS


A = Address (Direccin) Este registro se usa para traducir nombres de servidores de alojamiento a direcciones IPv4. AAAA = Address (Direccin) Este registro se usa en IPv6 para traducir nombres de hosts a direcciones IPv6. CNAME = Canonical Name (Nombre Cannico) Se usa para crear nombres de servidores de alojamiento adicionales, o alias, para los servidores de alojamiento de un dominio. Es usado cuando se estn corriendo mltiples servicios (como ftp y servidor web) en un servidor con una sola direccin ip. Cada servicio tiene su propia entrada de DNS (como ftp.ejemplo.com. y www.ejemplo.com.). esto tambin es usado cuando corres mltiples servidores http, con diferentes nombres, sobre el mismo host. Se escribe primero el alias y luego el nombre real. NS = Name Server (Servidor de Nombres) Define la asociacin que existe entre un nombre de dominio y los servidores de nombres que almacenan la informacin de dicho dominio. Cada dominio se puede asociar a una cantidad cualquiera de servidores de nombres. MX (registro) = Mail Exchange (Registro de Intercambio de Correo) Asocia un nombre de dominio a una lista de servidores de intercambio de correo para ese dominio. Tiene un balanceo de carga y prioridad para el uso de uno o ms servicios de correo. PTR = Pointer (Indicador) Tambin conocido como 'registro inverso', funciona a la inversa del registro A, traduciendo IPs en nombres de dominio. Se usa en el archivo de configuracin del Dns reversiva. SOA = Start of authority (Autoridad de la zona) Proporciona informacin sobre el servidor DNS primario de la zona. HINFO = Host INFOrmation (Informacin del sistema informtico) Descripcin del host, permite que la gente conozca el tipo de mquina y sistema operativo al que corresponde un dominio. TXT = TeXT - ( Informacin textual) Permite a los dominios identificarse de modos arbitrarios. LOC = LOCalizacin - Permite indicar las coordenadas del dominio. WKS - Generalizacin del registro MX para indicar los servicios que ofrece el dominio. Obsoleto en favor de SRV. SRV = SeRVicios - Permite indicar los servicios que ofrece el dominio. RFC 2782. Excepto Mx y Ns. Hay que incorporar el nombre del servicio, protocolo, dominio completo, prioridad del servicio, peso, puerto y el equipo completo. Esta es la sintaxis correspondiente:

Servicio.Protocolo.Dominio-completo IN SRV Prioridad.Peso.Puerto.Equipo-Completo SPF = Sender Policy Framework - Ayuda a combatir el Spam. En este registro se especifica cual o cuales hosts estn autorizados a enviar correo desde el dominio dado. El servidor que recibe, consulta el SPF para comparar la IP desde la cual le llega con los datos de este registro. ANY = Toda la informacin de todos los tipos que exista.

You might also like