IMPLEMENTACION DE UN SERVIDOR DNS PARA EL MEJORAMIENTO DE LAS REDES EMPRESARIALES Y LOS PROYECTOS DE TERRITORIOS DIGITALES A NIVEL NACIONAL

KRISTIAN JOS OROZCO ARROYO

FUNDACIN UNIVERSITARIA SAN MARTN FACULTAD DE EDUCACION ABIERTA Y A DISTANCIA PROGRAMA DE INGENIERIA DE SISTEMAS SINCELEJO SUCRE 2011

IMPLEMENTACION DE UN SERVIDOR DNS PARA EL MEJORAMIENTO DE LAS REDES EMPRESARIALES Y LOS PROYECTOS DE TERRITORIOS DIGITALES A NIVEL NACIONAL

KRISTIAN JOS OROZCO ARROYO

Trabajo de grado presentado como requisito para optar el ttulo de Ingeniero de Sistemas.

Director: Ing. ngel Daro Pinto Mangones

FUNDACIN UNIVERSITARIA SAN MARTN FACULTAD DE EDUCACION ABIERTA Y A DISTANCIA PROGRAMA DE INGENIERIA DE SISTEMAS SINCELEJO SUCRE 2011

NOTA DE ACEPTACIN

-------------------------------------

-------------------------------------

-------------------------------------

---------------------------------------Presidente del Jurado

-----------------------------------Jurado

----------------------------------Jurado

DEDICATORIA

A Dios padre que todo lo que hoy tengo me lo ha regalado por su amor, gracia y poder.

A mis padres que me dieron la oportunidad de mantener mi lnea de conocimiento con los estudios que continuar realizando.

Y como dedicatoria muy especial en memoria al Ingeniero Argemiro Martnez quien en mi trayecto bajo sus enseanzas hizo de mi una persona diferente, el cual con su gran sabidura me encamino por la sendas del conocimiento y del poder del estudio disciplinado.

KRISTIAN JOS OROZCO ARROYO

AGRADECIMIENTOS

Expreso mis agradecimientos sinceros a:

Yenny Luz Arroyo Oviedo, Madre

Jos Regino Orozco Banda, Padre

ngel Daro Pinto Mangones, Director del curso de profundizacin.

Argemiro Martnez, Q.E.P.D., Maestro, Amigo y gran persona.

A todas las personas e instituciones que brindaron su valioso aporte para hacer de ste proyecto una realidad.

KRISTIAN JOS OROZCO ARROYO

TABLA DE CONTENIDO

INTRODUCCIN 1. CAPITULO 1 UN POCO DE HISTORIA Y ALGO MS DE CONCEPTOS BASICOS 1.1. SERVIDOR DNS, SUS INICIOS Y SU HISTORIA 1.2. QU ES UN SERVIDOR DNS? 2. CAPITULO 2 CARACTERISTICAS Y FUNCIONAMIENTO DE UN SERVIDOR DNS 2.1. CMO FUNCIONA UN SERVIDOR DNS? 2.2. ARQUITECTURA DEL SERVIDOR DNS 2.2.1. SERVIDOR DE NOMBRE DE RAIZ 2.2.2. SERVIDOR DE NOMBRE DE ALTO NIVEL 2.2.3. SERVIDORES DE NOMBRES AUTORIZADOS 3. CAPITULO 3 SERVIDOR DNS COMO SOLUCION PARA GRANDES EMPRESAS Y LOS TERRITORIOS DIGITALES 3.1. ES LA MEJOR SOLUCIN? 3.2. SERVIDOR DNS, EFICIENCIA Y CALIDAD EN TODO UNA RED CONCLUSION BIBLIOGRAFIA ANEXOS

INTRODUCCIN

Desde el momento en que las redes se consideran cada vez ms una parte importante y estratgica de las empresas, industrias u otros tipos de instituciones y como resultado de los avances tecnolgicos, resulta ms importante su control y gestin con el fin de obtener la mejor calidad de servicio.

Tradicionalmente, en la gestin de las redes se ha partido de soluciones propietarias y cerradas con un mbito de actuacin limitado a la propia empresa o dominio de la institucin. Con el tiempo, la evolucin tecnolgica ha permitido la entrada de mltiples fabricantes de equipos, de la misma forma que otros fabricantes de reputado nombre han desaparecido y, en consecuencia, tambin el apoyo que prestaban a sus soluciones de red. Por tanto, bien sea porque ha ocurrido la absorcin de empresas o bien por diversificacin de las fuentes de los equipos, las redes actuales son cada vez ms heterogneas en equipos.

Actualmente las redes se han diversificado y multiplicado a nivel mundial, esto ha trado aumentos en los niveles de aprendizaje tecnolgico a nivel nacional tanto al punto que han creado los ministerios pertinentes proyectos que impulsan el uso de las nuevas tecnologas, es el caso de los proyectos de territorios digitales que benefician a la ciudadana brindndoles zonas WIFI de acceso gratuito, esto sin contar las mltiples herramientas entregadas en las instituciones educativas con el fin de habituar a los jvenes a la gama de utilidades que trae consigo las nuevas tecnologas pero si bien es cierto no todo puede ser color de rosas, con ello viene el inconveniente al que hacemos nfasis y es el mismo acceso a INTERNET, ya que con el paso del tiempo ms gente y empresas se unen a este proyecto haciendo cada vez ms difcil la administracin de las salidas a INTERNET.

Se contemplaron soluciones como aumentar el canal de salida de INTERNET pero como muchas personas lo saben el recurso econmico entregado en los proyectos del estado se ajustan a un presupuesto y si sobrepasan ese presupuesto no habr

cabida para las dems actividades contempladas en este, por tanto esto acarrea costos que no pueden ser suplidos y por lo tanto hacen inviable tal solucin, de esa investigacin surge la solucin que en este proyecto se propone.

Resaltar y enaltecer los capacidades de diferentes sistemas para el mejoramiento de la velocidad en una red empresarial y/o proyecto de territorios digitales que ayude a una comunidad cerrada o abierta se ha convertido en uno de los retos ms grandes ya que es una lucha constante entre economa y eficiencia, el problema general es que cuando nos enfrentamos a estos dos trminos vemos el termino TIEMPO en alto riesgo, esto nos lleva a sacrificar siempre una clave importante dentro del Top de servicio que espera entregar y recibir una empresa o proyecto.

Por otra parte las redes corporativas con su demanda de un INTERNET veloz y mejor funcionamiento de su Red Interna (LAN), ha hecho cada da ms complicada la bsqueda de soluciones efectivas, los cortos plazos, el presupuesto bajo y el mal manejo de recursos internos de una empresa hacen an ms difcil esta labor, por esta razn la bsqueda de soluciones se centra en la infraestructura interna de una empresa, empezando por su RED INTERNA para luego salir al mundo exterior.

CAPITULO 1

UN POCO DE HISTORIA Y ALGO MS DE CONCEPTOS BASICOS

1.1.

SERVIDOR DNS, SUS INICIOS Y SU HISTORIA

En Internet, la comunicacin entre los equipos y los humanos se facilita por el hecho de que los primeros tienen asignado un nombre, de esta forma, recordamos ms el nombre de una mquina ya que podemos asociar este a la organizacin o lugar en el que se encuentra, sin tener que memorizar la direccin de IP del equipo. Por ejemplo, pocos de nosotros sabemos que la mquina www.cnn.com tiene las direcciones de IP 207.25.71.22 (una de ellas).

Este concepto se conoce como Sistema de Nombres de Dominio, (DNS por sus siglas en ingls, Domain Name System), el cul naci en la dcada de los 80s. Creado por Paul Mockapetris en colaboracin con Jon Postel de la Universidad del Sur de California y posteriormente, Paul Vixie. Juntos desarrollaron lo que hasta ahora conocemos como el DNS (BIND, Barkeley Internet Name Domain), un sistema cliente/servidor, distribuido y jerrquico, caractersticas que se describen a detalle en los RFC2 1033, 1034 y 1035 y que son muy parecidas a un sistema de archivos de UNIX pero distribuido.

Originalmente, el uso del DNS involucr solamente instituciones acadmicas, de investigacin y por supuesto, la milicia de los EEUU. Eran los tiempos en que las universidades empezaban a realizar su conexin a las mltiples redes, entre ellas BitNet. Algo empezaba a trascender y era importante establecer un orden en cuanto a los equipos que ingresaban a la red.

Se crearon entonces los nombres de dominio genricos de primer nivel (Gtld, generic Top-level Domain), .com, .net y .org, es decir, se haban creado estas tres clasificaciones con el fin de ubicar el tipo de entidades que buscaban tener

presencia en Internet. Adems de estos Gtld se empez por delegar los sufijos nacionales (Ntld, national Top-level Domain) a los pases que se fueran conectando a la red. De esta forma, a Mxico se le asigno el .mx a finales de 1988 cuando el ITESM, Campus Monterrey se conecta de manera dedicada al Internet, este Ntld empieza a operar desde 1ro. De Febrero de 1989. As cada pas obtuvo su propio Ntld, incluso EEUU, el cual tiene el .us. Tambin existen unos nombres de dominio especiales, Stld, que son slo para los EEUU: .mil, .edu y .gov3.

Las organizaciones que administran los Ntld por lo general son instituciones acadmicas, como es el caso del .mx y el ITESM, sin embargo el caso de los Gtld es diferente, estos originalmente fueron administrados por el Stanford Research Institute Network Information Center (SRI-NIC), de la Universidad de Stanford en Menlo Park, California, pero pronto cambiara a InterNIC.

En 1992, la Fundacin Nacional de Ciencias de los EEUU (NSF, National Science Foundation) quien administraba el backbone de Internet (en ese entonces NSFNET) decide licitar la operacin del InterNIC y en 1993, a travs de un convenio de cooperacin, le otorga esta funcin a la empresa Network Solutions Inc.(NSI), posteriormente, esta empresa sera adquirida por el grupo Science Application International Corporation, (SAIC), originario de San Diego y que se distingue por sus multimillonarios contratos federales (Agencia de Seguridad Nacional, CIA, Marina de los EEUU)

Cuando NSI obtuvo el contrato, se estableci un apoyo de cuatro millones USD por parte de la NSF a NSI, para realizar la funcin del registro de los Gtld. No obstante, en 1994, el grupo SAIC compra esta empresa y su experiencia en contratos federales le ayuda a re-negociar el contrato previo. De esta forma, logra que se empiece a cobrar $50 USD anuales por cada nombre de dominio, estableciendo que el 30% de estas cuotas se iran a un fondo de infraestructura administrado por la NSF.

Aqu empezaron los problemas, aunque la operacin de NSI fue buena, en mi opinin, muchos consideraban que el servicio deba mejorarse, tomando en cuenta las utilidades que esta empresa perciba por la operacin de InterNIC. De hecho, este margen de utilidad le permiti a NSI empezar a cotizarse en la bolsa (NASDAQ: NSOL).

Para mediados de 1996, Jon Postel, el director del Internet Assignet Numbers Authority (IANA), y organismo administrador de las direcciones de IP y nombres de dominio, realiz una propuesta en la que contemplaba la creacin de 150 nuevos nombres de dominios genricos, Gtld, as como el .com, .net y .org. Esta propuesta pronto tuvo efectos importantes y finaliz en la formacin de un grupo que se encargara de discutir el re-diseo de los Gtld.

De esta forma, en Noviembre de 1996 naci el Internet-International Ad Hoc Committee (IAHC) impulsado por la Internet Society (ISOC), a los tres meses de haberse creado se gener el reporte final, en donde se planteaban las recomendaciones y requerimientos para un nuevo esquema de Gtld, este documento recibira el nombre de Memorando de Entendimiento para los Nombres de Dominio genricos de Nivel Superior.

El IAHC se disolvi en Mayo del 97 para dar paso al generic Top level Domain Memorndum of Understanding (Gtld-MoU), documento respaldado por

organizaciones de todo el mundo, entre ellas la Organizacin Mundial de la Propiedad Industrial (WIPO), Unin Internacional de Telecomunicaciones (ITU), Internet Society , MCI y por Latino Amrica slo NIC-Mxico. En este documento se plasman los acuerdos alcanzados durante esos ocho meses de discusin y consenso, en los que por cierto no estuvo ningn representante del gobierno de pas alguno.

Todo marchaba sobre ruedas, el Gtld-MoU contemplaba nuevos Gtld (.firm, .shop, .web, .arts, .rec, .info, .nom, una administracin mltiple y distribuida de los Gtld, por ejemplo, que ms de una organizacin pudiera registrar nombres de dominio bajo .com, la organizacin de un consejo central (CORE, Council of Registrars) formada por las organizaciones que fungiran como nuevos InterNICs, y dos cuerpos ms de soporte al nuevo esquema, Policy Advisory Group (PAB) y el Policy Oversigt Committee (POC). As mismo, se contemplaba en esta propuesta un esquema que permitiera cambiar de registro, es decir, portabilidad de los nombres de dominio, esto aseguraba, segn el Gtld-MoU, que todos los registros dieran un servicio de calidad.

As, el nuevo esquema requera de una inversin para el complejo sistema que debera consolidar la informacin de los 89 registros aceptados. Para esto CORE estableci una contrato con Emergent Corp para el desarrollo del nuevo esquema distribuido de DNS (new DNS Shared Registry System). Todo estaba listo pues, para que en Marzo de 1998 empezaran a operar los 89 registros en todo el mundo, aceptando as solicitudes de dominio bajo los siete nuevos nombres de dominio genricos.

El 30 de Enero, menos de dos meses antes de la fecha de inicio de operaciones del Gtld-MoU, el Gobierno de los Estados Unidos hace acto de presencia, en algo que 12rganiz no apto para polticos. A travs del Departamento de Comercio (DoC) publica un documento, conocido como Green Paper, en el cual, Ira Magaziner, asesor de Bill Clinton establece la postura de la Casa Blanca en materia de nombres de dominio. No pasaron muchas horas para que los principales actores de la industria enviaran sus comentarios al DoC expresando su desacuerdo.

En resumen, este documento desconoca la autoridad y el consenso del Gtld-MoU y por lo tanto de las organizaciones que lo representaban, a pesar de que el CORE ya estaba listo para iniciar operaciones. Su propuesta era esperar y

planear mejor las cosas, como si veinte meses no hubieran sido suficientes en un medio ambiente tan dinmico como es Internet, y se concretaba a proponer una nueva organizacin que supliera al IANA en la coordinacin de los Gtld y direcciones de IP para empezar funciones el 30 de Septiembre de 1998.

Este hecho provoc una cantidad impresionante de comentarios en contra del Green Paper, los cuales segn el DoC, se tomaran en cuenta para generar una iniciativa global. As, el 5 de Junio de 1998, el Gobierno de los EEUU, a travs del DoC emiti un documento conocido como White Paper, en el cual, 13rganiz se retractaban de algunos aspectos que haban planteado originalmente en el Green Paper.

Aunque no tan polmico como el anterior, este documento era de alguna forma los planteamientos finales del Gobierno de los EEUU para realizar la transicin en la administracin de Internet. A grandes rasgos, se limitaba a buscar una nueva organizacin central que supliera al IANA, de hecho se buscaba que fuera privatizada (sin fondos del gobierno) pero que fuera sin fines de lucro. Los aspectos en la generacin de nuevos nombres de dominio genricos, Gtld, se dejaban a consideracin de esta nueva organizacin, conocida ahora como el Nuevo IANA (Niana).

El tiempo cada vez era ms corto, por lo que surgieron organizaciones que buscaban acelerar las decisiones necesarias para el lanzamiento del Niana. Entre ellas, una Organizacin con las siglas GIAW, que posteriormente fue IFWP, (International Forum for the White Paper). Fue esta organizacin quien se encargo de realizar la primer consulta para discutir puntos esenciales en el cumplimiento del White Paper, y le llam la consulta de las Amricas, la cual tuvo lugar en Reston VA, EEUU. A pesar del enfoque continental que se intent darle, slo hubo tres representantes de Amrica Latina, CABASE de Argentina y NIC-Mxico.

A esta reunin le siguieron otras convocadas por la Asociacin de ISP en Europa (EuroISPA) y por la Comission Europea en Bruselas Blgica, teniendo como resultado un consenso ms global, representativo del continente europeo.

Es un hecho que el actual staff del IANA se mantendr de manera operativa en el Niana, sin embargo esto no es materia de discusin. Lo que se pretende definir es la estructura del Niana. Se ha hablado de tres cuerpos que se encargaran de las direcciones de IP, los nombres de dominio de primer nivel TLD y los protocolos, respectivamente, adems de un cuarto, en el que estaran representados los intereses de los primeros tres, as como de los principales grupos de inters (stakeholders) de Internet (usuarios, ISPs, etc.).

La segunda reunin convocada por el IFWP fue sostenida en Ginebra, Suiza, en el marco del INET98, una serie de eventos que realiza la ISOC anualmente. De todas las reuniones, esta ha sido sin duda la ms representativa, con participantes latinos y africanos, inclusive. Se busca que haya una tercera reunin en Singapur, para escuchar las propuestas de Asia-Pacfico.

El resultado de estas reuniones de trabajo dar la pauta en el establecimiento de las reglas que aplicarn a Internet en los prximos aos. Es imperativo que los stakeholders se involucren de manera activa en estos procesos y colaboren en la definicin de lo que hoy da es su negocio.

1.2.

QUE ES UN SERVIDOR DNS?

Todos hablamos de las DNS, pero qu son realmente, o ms bien, qu es un Servidor DNS?

Bien, una DNS no es ms que una direccin IP que nos facilita la comunicacin con un Servidor DNS, por lo que lo realmente importante es qu es un Servidor DNS.

Un Servidor DNS es, como su nombre indica, un servidor donde est alojada la DNS (Domain Name System) de un determinado proveedor de servicios ISP.

La Domain Name System (DNS) es una base de datos distribuida y jerrquica que almacena la informacin de los nombres de dominio, en este caso de Internet.

Vamos a tratar de explicar su funcin (y funcionamiento) de la forma ms clara y comprensible que podamos.

Como todos saben, al navegar lo que buscamos (o sea, lo que ponemos en la barra de direcciones del navegador) es un nombre de dominio (en nuestro caso, www.configurarequipos.com), pero Internet (como cualquier red) no funciona por nombres de dominio, sino por direcciones IP.

Fig. 1.2.1. Ejemplo: Funcionamiento Servidor DNS.

Pues bien, en ese caso nosotros no hacemos la peticin de comunicacin directamente con ese dominio en cuestin, sino que hacemos la peticin de comunicacin a un servidor DNS (el que tengamos establecido), que es el encargado de devolver la IP correspondiente al dominio con el que queremos conectar y transforma el nombre de dominio (www.configurarequipos.com) en su correspondiente IP, con la que s que podemos establecer una comunicacin.

Este sistema tiene entre otras la gran ventaja de que en cualquier momento puede cambiar la IP de un determinado dominio, pero eso no tiene la menor importancia siempre y cuando este dato est actualizado (que lo est normalmente) en el correspondiente servidor de DNS, ya que nosotros seguimos buscando por el nombre del dominio.

En base a esto nos puede surgir la pregunta es posible acceder a un dominio (o a una pgina web) sin valernos de un servidor de DNS? Pues la respuesta es que s que es posible siempre y cuando, claro est, sepamos la IP de dicho dominio o pgina, pero sera un sistema bastante engorroso y problemtico con los subdominios.

Otra pregunta que nos puede surgir es si todos los programas que acceden a Internet utilizan el sistema de DNS, y en este caso la respuesta sera que no necesariamente, ya que un determinado programa puede apuntar a una IP ya establecida o usar un sistema interno de direccionamiento, como ocurre con el Messenger, por ejemplo, o algunos antivirus en sus conexiones para actualizarse. Este es uno de los motivos por los que a veces no podemos navegar y s que podemos conectar con MSN (o WLM) y tambin de por qu a veces tenemos una perfecta conexin a Internet y Messenger no puede establecer conexin.

Fig. 1.2.2. Ejemplo: Peticin y Respuesta de un Servidor DNS

CAPITULO 2

CARACTERISTICAS Y FUNCIONAMIENTO DE UN SERVIDOR DNS

2.1.

CMO FUNCIONA UN SERVIDOR DNS?

El DNS se utiliza principalmente para la resolucin de nombres, esto es, decidir qu direccin IP pertenece a determinado nombre completo de host.

El DNS se utiliza para distintos propsitos. Los ms comunes son:

Resolucin de nombres: Dado el nombre completo de un host (por ejemplo blog.smaldone.com.co), obtener su direccin IP (en este caso, 208.97.175.41).

Resolucin inversa de direcciones: Es el mecanismo inverso al anterior. Consiste en, dada una direccin IP, obtener el nombre asociado a la misma.

Resolucin de servidores de correo: Dado un nombre de dominio (por ejemplo gmail.com) obtener el servidor a travs del cual debe realizarse la entrega del correo electrnico (en este caso, gmail-smtp-

in.l.google.com).

Por tratarse de un sistema muy flexible, es utilizado tambin para muchas otras funciones, tales como la obtencin de claves pblicas de cifrado asimtrico y la validacin de envo de e-mails (a travs de mecanismos como SPF).

Es necesario introducir algunos trminos bsicos para evitar confusiones y ambigedades. Otros trminos ms complejos sern tratados ms adelante.

 Host Name: El nombre de un host es una sola palabra (formada por letras, nmeros y guiones). Ejemplos de nombres de host son www, blog y obelix. Fully Qualified Host Name (FQHN): Es el nombre completo de un host. Est formado por el Hostname, seguido de un punto y su correspondiente nombre de dominio. Por ejemplo, blog.smaldone.com.co. Domain Name: El nombre de dominio es una sucesin de nombres concatenados por puntos. Algunos ejemplos son smaldone.com.co, com.co y co. Top Level Domains (TLD): Los dominios de nivel superior son aquellos que no pertenecen a otro dominio. Ejemplos de este tipo son com, org, co y es.

Cuando una aplicacin (cliente) necesita resolver un FQHN enva un requerimiento al servidor de nombres configurado en el sistema (normalmente, el provisto por el ISP). A partir de entonces se desencadena el proceso de resolucin del nombre:

1. El servidor de nombres inicial consulta a uno de los servidores raz (cuya direccin IP debe conocer previamente).

2. Este devuelve el nombre del servidor a quien se le ha delegado la subzona.

3. El servidor inicial interroga al nuevo servidor.

4. El proceso se repite nuevamente a partir del punto 2 si es que se trata de una sub-zona delegada.

5. Al obtener el nombre del servidor con autoridad sobre la zona en cuestin, el servidor inicial lo interroga.

6. El servidor resuelve el nombre correspondiente, si este existe.

7. El servidor inicial informa al cliente el nombre resuelto.

Ilustremos esto con un ejemplo concreto. Supongamos que el navegador necesita resolver el nombre blog.smaldone.com.co.

1. El sistema tiene configurado el servidor de nombres 200.49.156.3 (perteneciente al proveedor argentino Fibertel). Por lo tanto enva a ste el requerimiento de resolver blog.smaldone.com.co.

2. El servidor de 200.49.156.3 enva la consulta root server 198.41.0.4. 3. 198.41.0.4 le informa que el servidor con autoridad sobre co es athea.co, cuya direccin IP es 200.16.98.2. (En realidad, informa la lista de todos los servidores con tal autoridad, pero para simplificar el ejemplo tomaremos solamente uno.)

4. 200.49.156.3 enva nuevamente el requerimiento a athea.ar (el cual, recordemos, tambin tiene autoridad sobre com.co).

5. athea.ar responde que la autoridad sobre smaldone.com.co la tiene ns1.mydomain.com cuya direccin IP es 64.94.117.213.

6. 200.49.156.3 enva ahora la consulta a ns1.mydomain.com.

7. ns1.mydomain.com informa que la direccin IP de blog.smaldone.com.co es 208.97.175.41.

8. Finalmente, 200.49.156.3 devuelve este resultado a la aplicacin que origin la consulta.

Fig. 2.1.1. Ejemplo: Peticiones DNS y SERVIDOR WEB

Cada vez que un servidor de nombres enva una respuesta, lo hace adjuntando el tiempo de validez de la misma (TTL o tiempo de vida). Esto posibilita que el receptor, antes la necesidad de volver a resolver la misma consulta, pueda utilizar la informacin previamente obtenida en vez de realizar un nuevo requerimiento.

Esta es la razn por la cual los cambios realizados en el DNS no se propagan instantneamente a travs del sistema. Dependiendo de la naturaleza de los mismos (y de la configuracin de cada servidor), la propagacin puede tardar desde algunos minutos hasta varios das.

2.2.

ARQUITECTURA DE UN SERVIDOR DNS

El sistema DNS funciona principalmente en base al protocolo UDP. Los requerimientos se realizan a travs del puerto 53. El sistema est estructurado en forma de rbol. Cada nodo del rbol est compuesto por un grupo de servidores que se encargan de resolver un conjunto de dominios (zona de autoridad). Un servidor puede delegar en otro (u otros) la autoridad sobre alguna de sus sub-zonas (esto es, algn subdominio de la zona sobre la que l tiene autoridad). Un subdominio puede verse como una especializacin de un dominio de nivel anterior. Por ejemplo, smaldone.com.ar es un subdominio de com.co, que a su vez lo es del TLD co.

Fig. 2.2.1. Ejemplo: Zonas DNS, bsqueda de dominio.

El DNS es un sistema cliente-servidor, donde la aplicacin servidora est distribuida. Si esto no fuera as el sistema no escalara porque: Existira un nico punto de fallo. Sera un cuello de botella.

 La base de datos con los registros DNS estara alejada de la mayora de los host de Internet. Una base de datos enorme, en continuo cambio, recaera en una sola mquina y su mantenimiento sera muy costoso.

El tiempo de respuesta es ilimitado, aunque generalmente es pequeo (dcimas de segundo). Esto tiene mucho que ver con que el DNS se base en el UDP.

Los servidores de nombres se organizan jerrquicamente. Dependiendo del nivel en que se encuentran hablamos de tres tipos: (1) servidores autorizados (authoritative), (2) servidores de dominio del alto nivel (top-level Domain) y (3) servidores raz (root).

Para aumentar la resistencia a errores, en cada dominio suelen existir varios servidores de nombres.

Fig. 2.2.2. Lugares de hospedaje de SERVIDORES DNS PUBLICOS por todo el mundo.

2.2.1. SERVIDORES DE NOMBRES RAZ

Hasta la fecha de marzo del 2008, en Internet existen 13 servidores (generalmente muy potentes debido a la alta carga que deben soportar) de nombres raz (http://www.root-servers.org).

2.2.2. SERVIDORES DE NOMBRES DE ALTO NIVEL

Son responsables de los dominios de alto nivel: com, org, edu, gov, es, etc. La definicin del servidor de nombres de alto nivel (TLD) es un poco ambigua porque la altura es una medida relativa con respecto a otros servidores de nombres subordinados.

Ejemplo 2.2.2.: Cada departamento de una universidad podra tener su propio servidor de nombres para los hosts de ese departamento. Por ejemplo, el departamento de arquitectura de computadores y electrnica de la universidad de Almera podra tener un servidor para el dominio ace.ual.es. Adems, la universidad podra tener un servidor de nombres para el dominio ual.es. En este caso, el servidor de la universidad es un servidor de ms alto nivel que l del departamento. Sin embargo, por encima al menos hay dos servidores de mayor nivel: el que atiende al dominio es y los servidores de nombres raz.

2.2.3 SERVIDORES DE NOMBRES AUTORIZADOS

Cada organizacin con hosts pblicos (universidades, empresas, etc.) debe poseer al menos un servidor de nombre autorizado.

Por definicin, un servidor de nombre autorizado para el dominio Y debe de mantener los registros de resolucin de todos los hosts xxx.Y.

La fuente original de los registros de resolucin (tambin llamados registros de recursos) est en los servidores de nombres autorizados.

Ejemplo 2.2.3.: Continuado con el ejemplo anterior, el servidor de nombres del departamento de arquitectura de computadores y electrnica sera el nico servidor que debe mantener los registros de las mquinas del departamento. De hecho, cuando se instalase una nueva mquina, el proceso de alta de dicho host en el DNS consistira en crear un nuevo registro slo en dicho servidor.

CAPITULO 3

SERVIDOR DNS COMO SOLUCION PARA GRANDES EMPRESAS Y LOS TERRITORIOS DIGITALES

3.1.

ES LA MEJOR SOLUCIN?

Los servidores DNS, con toda su trayectoria en la red mundial han demostrado que pueden llegar a ser los artfices del mejoramiento en el trfico de datos ya que una resolucin ms rpida permite a los usuarios encontrar la ruta ms rpida para llegar al servidor que tiene el contenido pedido.

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.

Por esta razn en muchos casos la resolucin de nombres es lenta y otros casos es agobiante, entonces una solucin cercana seria la manera ms fcil de tener un rpido acceso a esa resolucin de nombres, pero no solo eso, sino un servidor que mantenga en el cache de pginas web visitadas para que sean haladas de manera local teniendo todo el ancho de la red para ingresar a las pginas de forma rpida.

Fig. 3.2.1. RED LOCAL y RED WAN con su VELOCIDAD Mxima de transmisin

3.3.

SERVIDOR DNS, EFICIENCIA Y CALIDAD EN TODO UNA RED

Un servicio de internet puede ser definido al momento de la navegacin ya que me dir que tan rpido es, as tambin podemos darnos cuenta como nos movemos en la red de manera que no solo usamos una lnea de salida sino tambin una red local que puede estar siendo subutilizada sin sacarle el mayor provecho posible.

Por esta razn se hace el SERVIDOR DNS una parte importante en el mejoramiento del manejo de estas herramientas que no estn siendo aprovechadas al mximo, si bien sabemos que solo disponemos de la salida que hayamos comprado al proveedor de internet, debemos tener en cuenta que tenemos una RED LOCAL abierta para el uso que nosotros deseemos.

En una red local cableada (Cable UTP CAT. 5e) tenemos una taza de transferencia de alrededor de 100 Mbps (Megabits por Segundo) y una salida a internet comprada a un proveedor X de 1 Mbps, esto nos dice que solo podemos navegar en la red mundial a una velocidad de 1 Mbps, esto indica que nuestra velocidad se ve atenuada cuando mas equipos o usuarios intentan navegar bajo el mismo canal.

Fig. 3.3.1. Red Local, con salida directa a WAN, Cuellos de botellas.

Esta conexin tiende a ser sumamente lenta y muy difcil de trabajar sobre ella, por tanto la solucin en la cual se piensa primero es aumentar el canal de salida a internet contratado con su proveedor, esto aparte de ser una solucin no tan viable

econmicamente para la empresa sera algo momentneo ya que solo se estara remediando algo inmediato pero no algo que dure.

A sabiendas que un canal ms grande es muchsimo ms costoso, implementar un servidor DNS conllevara a tener menos gastos econmicamente hablando y una solucin duradera, la cual solo habra que darle un mantenimiento casual preventivo, haciendo de la navegacin en internet una tarea ms cmoda y ms interesante. Explicado de esta manera tendramos una velocidad de respuesta en transmisin de datos alrededor de 100 Mbps, esto se debe a que la resolucin de nombres de dominio se hace de manera local, guardando un cache cada vez que se haga la peticin para ms adelante poder acceder a la pagina que se pidi de forma local, es decir, usaramos el canal comprado a el proveedor de internet y estaramos haciendo un uso completo de nuestra RED LOCAL, hacindola as una red totalmente til y eficaz en su desempeo.

Fig. 3.3.2. Ejemplo de Peticin a un SERVIDOR DNS LOCAL.

Esta solucin tambin contempla la posibilidad de poder tener un control de acceso a pginas que el administrador no permita dependiendo al tipo de red a la que se le implementa, as podemos evitar el ingreso a pginas pornogrficas, de entretenimiento y ocio, esto ms que todo se ve en las grandes y medianas empresas que requieren un control en el acceso a pginas.

Fig. 3.3.3. RED MAN, Implementacin DNS en su funcionamiento

Los resultados de esta implementacin se ven a corto plazo, ya que el servidor al implementar un cach vaco al iniciar, debe comenzar a llenar sus bases de datos con las pginas y dominios visitados, teniendo en cuenta que el servidor DNS no solo recoge nombres de dominio, por tanto en el momento de la implementacin estaramos recogiendo informacin actualizada constantemente en los recursos WEB.

Las implementaciones de este tipo varan en su tiempo de accin y puesta en marcha dependiendo de la velocidad inicial en el canal de salida a INTERNET y de la cantidad de usuarios iniciales del proyecto, en este caso contamos con una lista de sitios autorizados por la mayora de empresas y el Ministerio de Educacin Nacional.

CONCLUSION

Al realizar el presente el estudio concluyo que un servidor DNS mejora:

La velocidad de resolucin de nombres. La velocidad en navegacin de pginas. Un control de acceso a pginas no autorizadas. Control de aplicaciones ejecutadas online.

Tambin as una gran variedad de servicios que nos puede proveer, por tanto es una de las soluciones para medias y grandes empresas ms viables y eficientes a la hora de realizar la implementacin, por tanto tenemos que un servidor DNS no solo resolvera nombres de servidores web sino que tambin se convertira en un servidor web que aumentara la velocidad de navegacin en la red local.

Enfocndonos en los aspectos ms importantes es tambin la infraestructura necesaria para su funcionamiento, ya que hacen mnimo los gastos de instalacin y puesta en marcha, puesto que solo necesitaramos un servidor, los instaladores del sistema operativo (UBUNTU SERVER) y la configuracin de nuestro servidor DNS (BIND), las cuales hacen de este sistema algo sumamente viable para cualquier empresa.

Si bien es cierto, en la historia los servidores DNS han sido la mano derecha de los servidores WEB ya que con ellos es ms fcil saber la ubicacin de un servidor WEB la cual con nuestra peticin lleva una pgina hacia nosotros resolviendo su IP como un nombre de dominio.

De acuerdo a esto recomiendo tener en cuenta los siguientes aspectos en particular:

Sistema Operativo: Sistema que usa los recursos del hardware para brindar diferentes servicios, particularmente recomiendo usar Ubuntu server ya que es un sistema operativo de libre distribucin y fcil de instalar y configurar para los servicios que estamos utilizando

Servidor DNS: Resuelve IP a nombres de Dominio, haciendo ms fcil llegar de una pgina a nuestro ordenador. Este servidor preferiblemente debe ser usado un software libre llamada BIND, el cual es un software que te brinda el servicio de DNS local de muy fcil configuracin.

Servidor WEB: Aloja las pginas WEB dentro de su disco para luego ser mostradas en nuestro ordenador. Este servicio es montado bajo APACHE que es un servidor WEB muy popular el cual aloja gran cantidad de contenido web en su cach.

BIBLIOGRAFA

http://es.wikipedia.org/wiki/Domain_Name_System

http://wiki.xtech.com.ar/index.php/Como_funciona_el_DNS

http://www.hpca.ual.es/~vruiz/docencia/redes/teoria/html/texputse63.html

http://acsblog.es/articulos/trunk/LinuxActual/DNS/html/DNS.html

http://blog.smaldone.com.ar/2006/12/05/como-funciona-el-dns/

http://www.taringa.net/posts/info/1086409/Instalar-y-configurar-Servidor-DNS.html

http://hospedaje-web.com/como-funciona-el-sistema-dns-domain-name-server/

http://www.adslayuda.com/dns.html

ANEXOS

UBUNTU, EL SISTEMA OPERATIVO PARA MANTENER TU RED A TODO VAPOR Una vez insertado el CD o la memoria USB en el equipo arrancamos con l.

Seleccionamos el idioma de la instalacin En la siguiente pantalla nos encontramos con un men grfico en el que tenemos varias opciones. Si vas a instalar Ubuntu Server 10.04 desde un CD te recomiendo que primero Compruebes los defectos en el disco. En cualquier caso, como queremos instalar Ubuntu Server, lgicamente pulsamos Intro sobre Instalar Ubuntu Server.

Pulsamos Intro sobre Instalar Ubuntu Server

A continuacin comenzar el instalador de Ubuntu Server que, a diferencia de Ubuntu Desktop, est basado en texto. Aunque es muy recomendable leer el tutorial completo, sobre todo si es la primera vez que lo vas a instalar, aqu tienes enlaces directos a cada una de las partes en las que se divide la instalacin:

Seleccionar el idioma Configurar el teclado Configurar la red Configurar el reloj Particionado de discos Configurar usuarios y contraseas Configurar el gestor de paquetes Seleccionar e instalar programas Configuracin de grub-pc

Lo primero que debemos hacer es seleccionar el pas o regin en la que nos encontramos. En mi caso Espaa y pulsamos Intro.

Seleccionamos el pas

En la siguiente pantalla el instalado nos pregunta si queremos que l detecte automticamente la distribucin del teclado que tenemos. A m me gusta seleccionarlo manualmente por lo que contesto No.

Sin deteccin automtica del teclado

Como es lgico, ahora nos toca indicar el origen del teclado. Por lo que seleccionamos COLOMBIA y pulsamos Intro.

Elegimos el origen del teclado

Y despus la distribucin especfica. De nuevo para nosotros es COLOMBIA.

Seleccionamos la distribucin del teclado Al configurar la red, lo primero que hace es comprobar si tiene acceso a un servidor DHCP. Si detecta algn servidor DHCP en la red, se configura automticamente y continuaramos indicando el nombre de nuestro servidor.

Red configurada correctamente con DHCP Lo siguiente es indicarle el nombre de nuestro servidor. En este caso le he puesto servidor (poco original verdad?).

Escribimos el nombre del equipo Automticamente y basndose en nuestra ubicacin fsica el instalador nos dir nuestra zona horaria. Si es correcta, seleccionamos S. Si no lo es, despus de seleccionar No veremos un listado de zonas para elegir la nuestra.

Confirmamos la zona horaria El particionado de discos es nico proceso algo ms complicado de toda la instalacin. En general tenemos dos opciones: el particionado clsico y el LVM (Logical Volume Manager); siendo mucho ms verstil el LVM. El asistente de la instalacin nos proporciona las siguientes alternativas:

Guiado utilizar todo el disco: el asistente crear dos particiones (raz y swap). Guiado utilizar el disco completo y configurar LVM: se crea una particin de arranque (boot) y un volumen fsico que contendr dos volmenes lgicos (raz y swap).

Guiado utilizar todo el disco y configurar LVM cifrado: igual que el anterior pero en este caso se cifra el volumen lgico que contiene la particin raz.

Manual: nos permite particionar como queramos. Con o sin LVM, cifrando o sin cifrar y creando el nmero de particiones que necesitemos.

Si tienes prisa, utiliza cualquiera de los particionados guiados y ve al siguiente paso. Te recomiendo especialmente que elijas uno de los que use LVM. Pero si por casualidad puedes seguir leyendo con tranquilidad, vamos a ver como particionar el disco manualmente sin usar LVM (sobre el que espero escribir otro tutorial). Al igual que en un equipo domstico es recomendable tener tres particiones (raz, home y swap), en un servidor se suelen usar tambin tres particiones (como mnimo) pero para fines distintos y que son las siguientes:

/ (raz): contiene el sistema en s, las aplicaciones que se instalen, los archivos de configuracin y el home (si no creamos la particin aparte).

/var: alberga las pginas web, directorios de ftp, cach de un proxy-cach, buzones de correo electrnico

swap: el rea de intercambio.

En cualquier caso, lo ms recomendable siempre es hacer un particionado manual para tener todo el control sobre nuestras particiones.

Elegimos el mtodo de particionado En el siguiente paso vemos un resumen de los discos duros y las particiones que tenemos, en principio slo tenemos el disco duro sin ninguna particin. Lo seleccionamos y pulsamos Intro.

Creamos la tabla de particiones Los pasos vamos a hacer para hacer las particiones estn basados en un disco duro nuevo, sin tabla de particiones anterior. Por lo que lo primero que deberemos hacer ser crear la tabla de particiones. As que nos posicionamos sobre S y pulsamos Intro.

Creamos la tabla de particiones El asistente nos lleva de nuevo al resumen de las particiones, cosa que ocurrir cada vez que creemos una nueva particin. Sin embargo, en este caso ya tenemos una particin libre tan grande como nuestro disco duro. La seleccionamos porque en ella vamos a crear las particiones y pulsamos Intro.

Seleccionamos la particin libre A continuacin, elegimos Crear una particin nueva y pulsamos Intro.

Creamos una particin nueva La primera particin que vamos a crear es la particin raz (/). Esta particin contendr en nuestro caso los programas y servicios que instalemos y los homes de los usuarios que creemos porque no lo vamos a hacer en una particin aparte. Como nuestro disco duro es de 250 GB, para estar completamente tranquilos le voy a asignar 20 GB para esta particin (tiene espacio de sobra). Por supuesto, cambia esta tamao segn tus necesidades o capacidad de almacenamiento.

Escribimos el tamao de la particin raz Despus tenemos que indicar el tipo: primaria o lgica. En este caso, seleccionamos primaria.

Elegimos el tipo de particin: primaria La particin que estamos creando la podemos poner al principio o al final del espacio disponible. Le indicamos que al principio y pulsamos Intro.

Creamos la particin al principio En la siguiente pantalla tenemos que seleccionar el punto de montaje: / sistema de ficheros raz. Y despus, bajamos hasta Se ha terminado de definir la particin y pulsamos Intro.

Definimos el punto de montaje de la particin: / Una vez que tenemos nuestra primera particin creada, que nos aparecer en el resumen de particiones, seleccionamos el espacio libre y pulsamos Intro para definir la siguiente particin.

Seleccionamos el espacio libre para crear la siguiente particin En el nuevo espacio libre elegimos crear una particin nueva y pulsamos Intro.

Seleccionamos crear una particin nueva La particin que vamos a crear ahora es /var. Esta particin contendr todos los archivos de los servicios que ofrezca nuestro servidor como pueden ser las pginas web para un servidor HTTP, los archivos del FTP, la cach de un proxycach, etc. El tamao de esta particin depende del uso que vayamos a darle pero yo he decidido darle el resto del espacio libre menos 2 GB para el rea de intercambio (swap). Por lo tanto, como el espacio libre que me queda es de 248,4 GB si le resto 2 GB para el rea de intercambio, el tamao para esta particin ser de 246,4 GB.

Escribimos el tamao de la particin raz

El tipo de particin para esta particin puede ser tanto primaria como lgica. Siempre que puedo prefiero usar particiones primarias antes que lgicas por lo que tambin la establezco como primaria.

Elegimos el tipo de particin: primaria La particin que estamos creando la podemos poner al principio o al final del espacio disponible. Le indicamos que al principio y pulsamos Intro.

Creamos la particin al principio En la siguiente pantalla tenemos que seleccionar el punto de montaje: /var datos variables. Y despus, bajamos hasta Se ha terminado de definir la particin y pulsamos Intro.

Definimos el punto de montaje de la particin: /var Una vez que tenemos nuestra segunda particin creada, vamos a por la tercera y ltima: el rea de intercambio. Por eso seleccionamos el espacio libre y pulsamos Intro.

Seleccionamos el espacio libre para crear la siguiente particin Despus seleccionamos crear una particin nueva y pulsamos Intro.

Elegimos crear una particin nueva La particin que vamos a crear ahora es el rea de intercambio (swap). Como ya hicimos los clculos en la particin anterior para dejarle a esta particin el tamao que queremos, simplemente pulsamos Intro con el espacio que nos indica (2 GB).

Escribimos el tamao de la particin de swap El tipo de particin para esta particin puede ser tanto primaria como lgica. Siempre que puedo, prefiero usar particiones primarias antes que lgicas por lo que tambin la establezco como primaria.

Elegimos el tipo de particin: primaria En la siguiente pantalla tenemos que indicar que se va a usar como rea de intercambio. Y despus, bajamos hasta Se ha terminado de definir la particin y pulsamos Intro.

Definimos el rea de intercambio Una vez finalizada la creacin de las 3 particiones que vamos a tener en nuestro servidor, nos movemos con las flechas de cursor hasta la opcin Finalizar el particionado y escribir los cambios en el disco y pulsamos Intro.

Finalizamos el particionado Por ltimo, debemos confirmar que se van a escribir los datos en el disco antes de continuar. Marcamos S y pulsamos Intro.

Confirmamos los cambios realizados Una vez que hemos terminado con las particiones es el momento de crear una cuenta de usuario con privilegios de administracin. Hay que recordar que en Ubuntu el usuario root no est habilitado por defecto, por lo que cuando tengamos que hacer alguna tarea administrativa, tendremos que usar el nombre de usuario y la contrasea del usuario que vamos a crear a continuacin.

Lo primero que tenemos que hacer es escribir el nombre real del usuario: Slice of Linux. Este nombre puede tener espacios en blanco o caracteres especiales.

Escribimos el nombre real del usuario Despus tenemos que escribir el nombre de usuario (el identificador). Este nombre tiene que empezar por una letra minscula y no puede contener ni espacios ni caracteres especiales.

Escribimos el nombre de usuario Lo siguiente que deberemos indicar es la contrasea para este usuario. Los consejos de que contenga letras, nmeros y signos de puntuacin que nos hace el instalador son una buena idea.

Escribimos la contrasea Para verificar que la contrasea tenemos que escribirla de nuevo.

Volvemos a escribir la contrasea Tambin tenemos que configurar si queremos que nuestra carpeta personal est cifrada. En mi caso no lo encuentro necesario porque apenas voy a hacer uso de esta carpeta. As que contesto que No.

Seleccionamos si cifrar o no nuestra carpeta personal La configuracin del gestor de paquetes no es necesaria en muchos casos ya que slo ser necesaria cuando para acceder a Internet estemos detrs de un proxy no transparente. Si fuera ese nuestro caso, tendramos que escribir esa informacin. Como mi servidor no est detrs de ningn proxy, lo dejo en blanco.

Escribimos la informacin del proxy En esta pantalla debemos decidir qu hacer con las actualizaciones. Tenemos tres opciones:

Sin actualizaciones automticas. Cuando queramos actualizar nuestro servidor, lo haremos manualmente. Por ejemplo, usando el siguiente comando:

sudo apt-get update && sudo apt-get upgrade

Instalar actualizaciones de seguridad automticamente. De esta forma nos podemos despreocupar de las actualizaciones ms importantes ya que nuestro servidor las actualizar de forma automtica. En mi caso es la que he decidido poner.

Administrar el sistema con Landscape. Landscape es un servicio de pago de Canonical para administrar a travs de la web nuestros servidores.

Establecemos el modo de actualizar el sistema Adems de la instalacin del sistema bsico, podemos instalar cmodamente una buena cantidad de servicios. El nico servicio que siempre instalo es el OpenSSH server porque una vez instalado siempre me conecto al servidor usando SSH. Por supuesto, que cada uno instale lo que necesite. Sin embargo, creo que es mejor instalar los servicios despus siguiendo los tutoriales que tenemos publicados nosotros o cualquier otro blog.

Marcamos los servicios a instalar El ltimo paso en la instalacin de Ubuntu 10.04 LTS Server consiste en la instalacin del cargador de arranque GRUB en el registro principal de arranque. En general no se suele instalar un Ubuntu Server junto con otros sistemas operativos (no tiene mucho sentido), por lo que no tendremos ningn tipo de problema. Marcaremos S y pulsaremos Intro para instalar el GRUB en nuestro sistema.

Seleccionamos instalar el GRUB Aqu se termina la instalacin de nuestro nuevo servidor basado en Ubuntu. El mensaje nos recuerda que debemos sacar el CD-ROM o memoria USB para que

cuando reinicie, el sistema arranque desde el disco duro. Cuando estemos listos, pulsamos Continuar.

Instalacin completada

BIND, UN SERVIDOR DNS PARA TODOS Los valores que debemos tener claros antes de comenzar son los siguientes:

Direccin IP del servidor: 192.168.2.1 Nombre del servidor: servidor Dominio que vamos a crear: sliceoflinux.lan

Estos valores deberemos sustituirlos por los que necesitemos en cada caso. Los pasos para instalar y configurar Bind en Ubuntu Server son los siguientes: 1. Actualizamos la informacin de los repositorios con el siguiente comando: sudo aptitude update 2. Instalamos el servidor DNS Bind9: sudo aptitude install bind9 3. Hacemos una copia de seguridad del archivo que vamos a modificar: sudo cp /etc/bind/named.conf.local{,.original} Este comando nos puede ahorrar mucho tiempo y est descrito en el artculo hacer copias de seguridad de archivos rpidamente. 4. Editamos el archivo /etc/bind/named.conf.local con el siguiente comando: sudo nano /etc/bind/named.conf.local y aadimos el siguiente contenido: zone "sliceoflinux.lan" { type master; file "db.sliceoflinux.lan";

};

zone "2.168.192.in-addr.arpa" { type master; file "db.192.168.2"; }; Esto se puede ver en la siguiente captura de pantalla:

Editamos el archivo /etc/bind/named.conf.local Para guardar el archivo debemos pulsar la combinacin de teclas Control + O y para salir Control + X. 5. Para comprobar la sintaxis de los archivos de configuracin ejecutamos el siguiente comando: Named - checkconf Si no aparece nada, la sintaxis de los archivos de configuracin es correcta. Ojo! Eso no significa que no haya ningn error, slo que no hay errores de sintaxis.

Ejecucin de named - checkconf sin errores Si hubisemos cometido un error de sintaxis, nos aparecera indicado junto a la lnea en la que ocurre. En el siguiente ejemplo puede verse que en el archivo /etc/bind/named.conf.local en la lnea 15 hay un error:

Ejecucin de named - checkconf con un error 6. Creamos el archivo /var/cache/bind/db.sliceoflinux.lan: sudo nano /var/cache/bind/db.sliceoflinux.lan e incluimos el siguiente contenido: $ORIGIN sliceoflinux.lan. $TTL 86400 ; 1 dia @ 1 IN SOA servidor postmaster (

; serie

6H ; refresco (6 horas) 1H ; reintentos (1 hora) 2W ; expira (2 semanas) 3H ; mnimo (3 horas) ) NS servidor A servidor 192.168.2.1

El contenido del archivo es bastante especial y no lo vamos a comentar pero para ms informacin se puede leer el RFC 1912 y el RFC 2308. Aqu deberamos aadir todos los equipos de nuestra red que quisiramos mantener identificados pero como es ms fcil hacerlo con DDNS (Dynamic DNS) ya lo veremos en otra ocasin.

7. Comprobamos la zona que acabamos de crear (sliceoflinux.lan): named-checkzone sliceoflinux.lan /var/cache/bind/db.sliceoflinux.lan En esta ocasin siempre nos aparecer una salida, ya sea para indicarnos que todo est bien (OK) o algn error.

Ejecucin de named-checkzone sin errores 8. A continuacin creamos el archivo /var/cache/bind/db.192.168.2 para la zona inversa: sudo nano /var/cache/bind/db.192.168.2 e incluimos el siguiente contenido: $ORIGIN 2.168.192.in-addr.arpa. $TTL 86400 @ 1 6H 1H 2W 3H ) NS 1 PTR servidor.sliceoflinux.lan. servidor.sliceoflinux.lan. IN ; 1 dia SOA ; serie ; refresco (6 horas) ; reintentos (1 hora) ; expire (2 semanas) ; mnimo (3 horas) servidor postmaster (

El nmero 1 se corresponde con el ltimo dgito de la direccin IP del servidor (192.168.2.1). 9. Comprobamos la zona inversa recin creada:

named-checkzone 2.168.192.in-addr.arpa /var/cache/bind/db.192.168.2 Al igual que antes obtendremos un mensaje para indicarnos tanto si la zona es correcta como si no lo es.

Ejecucin de named-checkzone sin errores 10. Reiniciamos el servicio: sudo service bind9 restart Si todo va bien, veremos que est OK.

Reiniciamos el servicio 11. Revisamos el log para comprobar que todo ha ido bien. Aunque se puede hacer con el comando tail, yo prefiero less porque me permite ver todo el contenido del mismo: less /var/log/syslog El resultado se puede ver en la siguiente captura:

Comprobamos que no hay errores en syslog, Para salir deberemos pulsar la tecla q. 12. Editamos el archivo /etc/resolv.conf para que nuestro servidor resuelva las peticiones DNS: sudo nano /etc/resolv.conf Cambiando el primero de los servidores DNS por la IP del nuestro: nameserver 192.168.2.1 nameserver 8.8.8.8 13. Probamos nuestro servidor de nombres: dig sliceoflinux.lan La respuesta ser muy parecida a la siguiente:

Ejecucin de dig sliceoflinux.lan 14. Probamos la resolucin inversa: dig -x 192.168.2.1 Esta sera la salida esperada del comando anterior:

Ejecucin de dig -x 192.168.2.1