Usuario anónimo ¿Quieres tener tu propio blog?
Crear blog gratis en OboLog

Prueba

por gamonal
jueves, 10 de julio del 2008 a las 18:50
guardado en

Estos son los 3 archivos para configurar dns. Aqui se han configurado 2
pcs, 1 con dns que sera gateway de la red y otro que no tiene nada.
la red configurada es la 192.168.2.0/24, un pc es el .1 (pc1, GW) y el
otro es el .10(pc2)
también el en el pc1 se levanto apache y se puso una pagina en el
directorio html para probar la resolución de nombre. Los archivos estan
probados asi que no deberian tener problemas.
No olviden configurar iptables. Aprovechen el laboratorio mañana que no
hay clases para estudiar, la prueba estará larga y dificil.
#########################################
#Archivo clase.cl.zone
$TTL 86400
@ IN SOA clase.cl root(
624
3H
15M
1W
1D
)
IN NS pc1.clase.cl.
clase.cl IN A 192.168.2.1
pc1 IN A 192.168.2.1
pc2 IN A 192.168.2.10
www IN A 192.168.2.1
# fin de archivo
########################################
#archivo 2.168.192.in-addr.arpa.zone
$TTL 86400
@ IN SOA clase.cl. root(
60
3H
15M
1W
1D
)
NS clase.cl.
1 PTR clase.cl.
1 PTR pc1.clase.cl.
10 PTR pc2.clase.cl.
1 PTR www.clase.cl.
# fin de archivo
########################################
#archivo named.conf
options{
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
};

zone "." IN{
type hint;
file "named.ca";
};

zone "clase.cl" IN{
type master;
file "clase.cl.zone";
allow-update{
none;
};
};

zone "2.168.192.in-addr.arpa" IN{
type master;
file "2.168.192.in-addr.arpa.zone";
};
# fin de archivo
#####################################

Paola

implementado servidor DNS con BIND en CENTOS5 2

por gamonal
jueves, 10 de julio del 2008 a las 18:48
guardado en

Aquí se resuelve el Canonical Name para peticiones tanta si estas vengan para FTP, web o
DNS. Y se enlaza nuestra IP al dominio.
Ahora creamos el archivo para la resolución inversa de nuestra ip:
# /var/named/10.110.200.in-addr.arpa.zone
Dentro tendría lo siguiente:
$TTL 86400
@ IN SOA ejemplo.com. administrador (
200706246 ; Serial
28800 ; Refresh
7200 ; Retry
604800 ; Expire
86400) ; Minimum TTL
NS ejemplo.com.
NS .ejemplo.com.
;
; Servers
;
10 PTR ejemplo.com.
10 PTR .ejemplo.com.
10 PTR www.ejemplo.com.
10 PTR ftp.ejemplo.com.
En la linea "10 PTR ....", no olvide reemplazar el 10 por el ultimo numero ip.
Con esto el servidor DNS ya debería trabajar, pero aun falta algunos detalles, como cambiarle
el nombre al servidor y también la ip.
Para cambiar el nombre al servidor editamos el archivo "network":
# /etc/sysconfig/network
Y ponemos:
NETWORKING=yes
NETWORKING_IPV6=yes
HOSTNAME=.ejemplo.com
, va ser el nombre que deseemos, el cual se va reemplazar en los archivos
de zona.
Ahora cambiamos la ip del servidor DNS, editando "resolv.conf"
# vi /etc/resolv.conf
Y ponemos
nameserver 200.110.10.10
Solo nos falta levantar el servicio:
# service named start
Y para que este inicie al arranque del sistema:
# chkconfig named -level 345 on

implementado servidor DNS con BIND en CENTOS5

por gamonal
jueves, 10 de julio del 2008 a las 18:44
guardado en

Implantación básica de BIND en Centos5
Instalando paquetes necesarios
Los paquetes que se necesitan para instalar BIND son:
• bind
• bind-utils
• bind-libs
• bind-chroot
• caching-nameserver
Los instalamos con nuestro manejador de paquetes:
# yum install bind bind-utils bind-libs bind-chroot caching-nameserver
Configuración:
Para esto necesitaremos un dominio y una ip publica.
El dominio referencial sera: "ejemplo.com"
Nuestra ip referencial: 200.110.10.10
Rutas:
Los archivos de configuración se encuentran en dos rutas que se complementan, estas son:
/etc y /var/name
En etc se va encontrar el archivo "named.conf", el archivo mas importante, y en /var/name se
van a encontrar el archivo ".zone" y el de resolucion inversa ".in-addr.arpa.zone", los cuales van
a ser llamados por "named.conf".
Conociendo esto ya podemos modificar el archivo named.conf (respaldar el original)
En esta configuración solo se hace referencia a los archivos que ya existen en /var/name. El
contenido que vamos a agregar para nuestro propósito es el siguiente:(antes de la última linea)


# Configuración para ejemplo.com
zone "ejemplo.com." {
type master;
file "ejemplo.com.zone";
allow-update { none; };
};
zone "10.110.200.in-addr.arpa" {
type master;
file "10.110.200.in-addr.arpa.zone";
};


Aquí se define la zona para nuestro dominio y también la resolución inversa para nuestra ip.
Ahora pasemos a crear los archivos a los que estamos llamando en nuestro named.conf,
creamos la zona del dominio:
# /var/named/ejemplo.com.zone
Dentro tendría lo siguiente:


$TTL 86400
@ IN SOA administrador (
42 ; Serial formato: yyyymmddn donde n es un número cualquiera
10800 ; Refresh después de tres horas
3600 ; Reintentar después de una hora
604800 ; Expirar después de una semana
86400 ) ; TTL(Time to Live) mínimo de un día
IN NS
ejemplo.com. IN A 200.110.10.10
IN CNAME ejemplo.com.
www IN CNAME ejemplo.com
ftp IN CNAME ejemplo.com

dns pagina 5

por gamonal
jueves, 10 de julio del 2008 a las 18:39
guardado en

tienen bajo su control una o más redes o subredes IP, se da una situación de mapeo uno-avarios
entre zonas DNS y redes IP. El Departamento de Física, por ejemplo, comprende las
subredes 149.76.8.0, 149.76.12.0 y 149.76.14.0.
En consecuencia, deben crearse nuevas zonas en el dominio in-addr.arpa para la zona de
Física, delegándose a ésta las siguientes: 8.76.149.in-addr.arpa, 12.76.149.in-addr.arpa, y
14.76.149.in-addr.arpa. De otro modo, cada vez que instalásemos un nuevo nodo en el
laboratorio Collider, habría que contactar con el que gestiona la red padre para que actualizase
su fichero de zona in-addr.arpa.
En el ejemplo siguiente se muestra la base de datos para la subred 12. Los registros glue
correspondientes a la base de datos de la zona padre se muestran en el ejemplo
Extracto del fichero named.rev de la subred 12
# dominio 12.76.149.in‐addr.arpa
@ IN SOA niels.physics.groucho.edu. janet.niels.physics.groucho.edu. {
200806091300 360000 3600 3600000 3600
}
2 IN PTR otto.physics.groucho.edu.
4 IN PTR quark.physics.groucho.edu.
5 IN PTR down.physics.groucho.edu.
6 IN PTR strange.physics.groucho.edu.
Extracto del fichero named.rev de la Red 149.76
# dominio 76.149.in‐addr.arpa
@ IN SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. {
1999070100 360000 3600 3600000 3600
}
#...
# subnet 4: Mathematics Dept.
1.4 IN PTR sophus.maths.groucho.edu.
17.4 IN PTR erdos.maths.groucho.edu.
23.4 IN PTR gauss.maths.groucho.edu.
...
# subnet 12: Physics Dept, separate zone
12 IN NS niels.physics.groucho.edu.
IN NS gauss.maths.groucho.edu.
niels.physics.groucho.edu. IN A 149.76.12.1
gauss.maths.groucho.edu. IN A 149.76.4.23
#...
Las zonas de in-addr.arpa sólo pueden ser creadas por superconjuntos de redes IP. Hay una
restricción más severa: las máscaras de estas redes deben contener los octetos completos.
Es decir, podemos crear una zona para una red con máscara 255.255.255.0 pero no para una
del tipo 255.255.255.128. El motivo es que para especificar la red delegada 149.76.4.0
tenemos el dominio 4.76.149.in-addr.arpa, pero para la red 149.76.4.128 no tenemos forma de
nombrar el dominio in-addr correspondiente.

dns pagina 4

por gamonal
jueves, 10 de julio del 2008 a las 18:37
guardado en

otto IN A 149.76.12.2
quark IN A 149.76.12.4
down IN A 149.76.12.5
strange IN A 149.76.12.6
#...
# Laboratorio (subred 14)
boson IN A 149.76.14.1
muon IN A 149.76.14.7
bogon IN A 149.76.14.12
#...
Aparte de los registros A y CNAME, vemos al principio un registro especial, de varias líneas. Es
el registro SOA, que señaliza el inicio de autoridad, que almacena diversos parámetros de la
zona de la que es autoritativo el servidor. El registro SOA incluye, por ejemplo, el tiempo de
vida predeterminado de los registros (TTL).
Nótese que todos los nombres del fichero de ejemplo que no finalizan en un punto deben
interpretarse relativos al dominio physics.groucho.edu. El nombre especial (@) utilizado en el
registro SOA representa al propio nombre del dominio.
Hemos visto antes que los servidores de nombres para el dominio groucho.edu tienen que
saber acerca de la zona physics para poder realizar peticiones a sus servidores de nombres.
Esto normalmente se realiza mediante dos registros: los registros DNS que proporcionan el
FQDN del servidor de nombres, y el registro A que asocia ese FQDN con una dirección IP.
Puesto que estos registros son los que mantienen el espacio de nombres, se conocen
frecuentemente como registros glue. Sólo son instancias de registros para los que una zona
padre mantiene información sobre nodos de la zona subordinada. Los registros glue apuntando
a los servidores de nombres de physics.groucho.edu se muestran en el siguiente ejemplo.
# Zona de datos para la zona groucho.edu
@ IN SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. {
200806091300 ; serie no
360000 ; refresco
3600 ; reintento
3600000 ; expiración
3600 ; ttl por omisión
}
#....
#
# Registros glue para la zona physics.groucho.edu
physics IN NS niels.physics.groucho.edu.
IN NS gauss.maths.groucho.edu.
niels.physics IN A 149.76.12.1
gauss.maths IN A 149.76.4.23
#...
Resolución inversa
La operación más habitual con el DNS es obtener la dirección IP correspondiente a un nombre
de nodo. Sin embargo, a veces queremos hacer la operación opuesta: encontrar el nombre
a partir de la dirección IP. Esto se conoce como resolución inversa, y la usan diversas
aplicaciones para comprobación de identidad del cliente. Cuando se utiliza el fichero hosts, la
resolución se realiza mediante una búsqueda simple en el fichero. Con el DNS, una búsqueda
exhaustiva en el espacio de nombres carece de sentido. En su lugar, existe un dominio
especial, el in-addr.arpa, que contiene las direcciones IP de todos los sistemas en una
notación de puntos invertida. Por ejemplo, a la dirección 1.2.3.4 le corresponde el nombre
4.3.2.1.in-addr.arpa. El registro de recurso (RR) que define esto se llama registro PTR.
Cuando se crea una zona de autoridad, ello suele significar que sus administradores tienen
control total sobre cómo se asignan los nombres a las direcciones. Puesto que normalmente

dns pagina 3

por gamonal
jueves, 10 de julio del 2008 a las 18:36
guardado en

Los servidores de nombres que mantienen oficialmente la información de una zona se conocen
como autorizados de la zona, y a veces se conocen como servidores principales o
maestros. Cualquier petición de nodos de esa zona irá a parar a uno de estos servidores
principales.
Los servidores principales deben estar bien sincronizados. Es decir, uno de ellos será llamado
primario, que carga su información de un fichero, y hacer a los demás secundarios, que
obtienen su información pidiéndosela periódicamente al primario.
El objetivo de tener varios servidores principales es distribuir la carga y dar cierta tolerancia
a fallos. Cuando uno de los servidores principales falla, todas las peticiones acabarán en los
demás. Por supuesto, este esquema no nos protege de fallos del servidor que produzcan
errores en todas las peticiones DNS, como podrían ser errores del software.
También podemos instalar un servidor de nombres que no es maestro de ninguna zona. Esto
es útil, para dar servicio de nombres a una red local aprovechando sus características de
ahorro de ancho de banda gracias a su caché. Estos servidores se conocen como de sólocaché
.
La base de datos DNS
Hemos visto que el DNS no sólo sabe de direcciones IP de máquinas, sino que también
almacena otras informaciones.
Cada unidad de información del DNS se llama Registro de Recurso (RR). Cada registro tiene
un tipo asociado que describe el dato que contiene, y una clase que especifica el tipo de red al
que se aplica. Esto último se adapta a diferentes esquemas de dirección, como direcciones IP
(la clase IN), direcciones Hesiod (utilizadas por el sistema Kerberos del MIT) y algunas más. El
RR típico es el registro A, que asocia un nombre completamente cualificado con una dirección
IP.
Un nodo puede ser conocido por más de un nombre. Por ejemplo, podemos tener un servidor
que proporciona tanto servicio FTP como WWW, y tendrá dos nombres: ftp.maquinas.org y
www.maquinas.org. Sin embargo, uno de estos nombres debe ser identificado como oficial o
canónico. La diferencia es que el canónico es el único registro A que debe existir apuntando a
esa dirección IP, mientras que el resto de los nombres deben ser alias (registros CNAME), que
apuntan al nombre canónico.
No vamos a revisar todos los tipos de RR aquí, pero veremos algún ejemplo más amplio.
Veremos una parte de la base de datos DNS que está cargada en los servidores de nombres
para la zona physics.groucho.edu.
# Informacion autoritativa physics.groucho.edu.
@ IN SOA niels.physics.groucho.edu. janet.niels.physics.groucho.edu. {
200806091300 # numero de serie
360000 # refresco
3600 # reintento
3600000 # caducidad
3600 # TTL predeterminado
}
#
# Servidores de nombres
IN NS niels
IN NS gauss.maths.groucho.edu.
gauss.maths.groucho.edu. IN A 149.76.4.23
#
# Fisica Teorica (subred 12)
niels IN A 149.76.12.1
IN A 149.76.1.12
nameserver IN CNAME niels

dns pagina 2

por gamonal
jueves, 10 de julio del 2008 a las 18:33
guardado en

Por supuesto, el hecho de que un nombre está en uno de estos dominios nacionales, no
implica que la máquina esté realmente en ese país; significa simplemente que ha sido
registrada en el NIC de ese país. Un fabricante sueco puede tener oficinas en Australia y tener
sus ordenadores de allá registrados en el dominio .se.
La organización del espacio de nombres en una jerarquía de nombres de dominio sirve para
resolver fácilmente el problema de la unicidad de los nombres; además muchos nombres
completamente cualificados son fáciles de recordar. Bajo esta premisa es conveniente dividir
un dominio con gran número de máquinas en subdominios.
El sistema DNS hace más cosas. Permite delegar la autoridad de un subdominio a sus
administradores. Por ejemplo, los responsables del Centro de Cálculo Groucho pueden crear
un subdominio para cada departamento, y delegar su control a éstos. Así, cada departamento
puede definir libremente todos los nodos que quiera dentro de su subdominio e incluso crear
nuevos subdominios y delegarlos.
Para esto, el espacio de nombres se divide en zonas, cada una asignada a un dominio. Hay
que ver la diferencia entre zona y dominio: por ejemplo, el dominio groucho.edu incluye todas
las máquinas y subdominios de éste. Mientras que la zona groucho.edu solo incluye las
máquinas del dominio, no los subdominios delegados. Es decir, los nodos del subdominio
physics.groucho.edu pertenecen a una zona diferente. En la figura, el inicio de la zona se
marca con un pequeño círculo a la derecha del nombre de dominio.
Búsquedas con DNS
Veremos ahora la parte más ingeniosa del DNS. La idea es que si queremos buscar la
dirección IP del sistema erdos, DNS pensará, "Preguntemos a la gente que lo maneja, y nos lo
dirá."
De hecho, el DNS es como una gigantesca base de datos distribuida. Está realizada a
través de los llamados servidores de nombres, que proporcionan la información de uno o
varios dominios. Para cada zona, debe haber dos o más servidores de nombres capaces de
responder por ella. Para obtener la dirección IP de erdos, todo lo que necesitamos es contactar
con el servidor de nombres de la zona groucho.edu y obtendremos los datos solicitados.
Cuando nuestra aplicación quiere buscar la información de erdos, contactará con un servidor
de nombres local, quien lleva a cabo una secuencia de peticiones. En primer lugar pregunta al
servidor de nombres raíz, preguntando por erdos.maths.groucho.edu. El servidor raíz reconoce
que el nombre no pertenece a ninguna de sus zonas de autoridad pero sí sabe qué hacer con
la zona edu. Esto es, devuelve a nuestro servidor más información sobre los servidores de
nombres que pueden servir la zona edu. Ahora nuestro servidor preguntará por este nombre a
uno de esos servidores. Ellos nos enviarán a uno que tenga información autorizada del dominio
groucho.edu. Ahora nuestro servidor interrogará a éste y finalmente obtendrá la dirección de
erdos.
Aparentemente la búsqueda de una dirección IP supone mucho tráfico, sin embargo es
minúsculo si lo comparamos con la consulta de un gigantesco fichero HOSTS.TXT. Aun así hay
técnicas para mejorar el rendimiento.
Para acelerar futuras peticiones de nombres, el servidor almacena la información obtenida en
la búsqueda anterior en su caché local. Así, la próxima vez que busquemos algún nodo de
groucho.edu, ya no habrá que ir a los servidores raíz o los de la zona edu.
Por supuesto, el servidor de nombres no almacenará para siempre la información en la caché;
la limpiará cada cierto tiempo. El tiempo de vida se llama TTL (del inglés time to live). En cada
zona DNS el administrador asigna un valor de TTL.
Tipos de servidores de nombres

dns pagina 1

por gamonal
jueves, 10 de julio del 2008 a las 18:31
guardado en

El DNS organiza los nombres de máquina (hostname) en una jerarquía de dominios. Un
dominio es una colección de nodos relacionados de alguna forma-porque están en la misma
red, tal como los nodos de una universidad-. Por ejemplo, las universidades americanas se
agrupan en el dominio edu. Cada universidad tiene allí un subdominio, tal como la universidad
Groucho Marx, que posee el subdominio groucho.edu. A su vez, podemos encontrar nuevos
subdominios dentro, como el Departamento de Matemáticas (maths). Finalmente, un nodo de
ese departamento llamado erdos tendrá un nombre completo (conocido como totalmente
cualificado) tal como erdos.maths.groucho.edu. Este nombre totalmente cualificado también
se conoce por las siglas FQDN.
En En la figura vemos una parte del espacio de nombres. La raíz del árbol, que se identifica con
un punto sencillo, es lo que se denomina dominio raíz y es el origen de todos los dominios.
Para indicar que un nombre es FQDN, a veces se termina su escritura en un punto. Este punto
significa que el último componente del nombre es el dominio raíz.
Dependiendo de su localización en la jerarquía, un dominio puede ser de primer nivel (toplevel),
segundo nivel o tercer nivel. Se pueden añadir todos los niveles que queramos, pero no
son habituales. Los que siguen son los dominios de primer nivel que veremos con frecuencia:
Dominio Descripción
edu Instituciones universitarias.
com Organizaciones comerciales.
org Organizaciones no comerciales. Las redes privadas UUCP suelen estar en
este dominio.
net Pasarelas y otras redes administrativas.
mil El ejercito norteamericano.
gov De gobierno.
uucp Dominio para redes UUCP.
Fuera de los Estados Unidos, cada país suele tener su propio dominio de primer nivel
codificado con las dos letras del país definidas en la tabla ISO-3166. Finlandia, por ejemplo,
usa el dominio fi; en España se usa el dominio es; en México se usa mx; en Argentina, ar, etc.
Por debajo de cada dominio de primer nivel, cada país organiza los dominios a su manera.
Algunos crean a segundo nivel una serie de dominios similares a los gTLD. Por ejemplo, en
Argentina encontramos los dominios com.ar para las empresas, y org.ar para las
organizaciones sin ánimo de lucro. Otros países, ponen directamente como nombres de
segundo nivel las instituciones o empresas que los solicitan. Por ejemplo, tenemos los
dominios chilenos .cl

Sobre el blog

El blog de gamonal

El blog de gamonal

Ver ficha del blog en OboLog

Login

Comentarios

implementado servidor DNS con BIND en CENTOS5 (eulogio)
hola estoy configurando un dns de prueba entre dos maquinas que deberia tomas en cuenta al momenot ......(20 may)

Más comentados

implementado servidor DNS con BIND en CENTOS5 (1)
Implantación básica de BIND en Centos5Instalando paquetes necesariosLos paquetes que se necesitan ...
2.168.192.in-addr.arpa.zone (0)
$TTL 86400@ IN SOA laboratorio.cl root (            200706247 ; Serial             28800 ; Refresh ...
named.conf (0)
options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file ...
dns pagina 1 (0)
El DNS organiza los nombres de máquina (hostname) en una jerarquía de dominios. Undominio es una ...
dns pagina 2 (0)
Por supuesto, el hecho de que un nombre está en uno de estos dominios nacionales, noimplica que la ...

Suscripción

Suscríbete al Feed RSS XML

También puedes suscribirte directamente con alguno de los siguientes enlaces:

  • Suscríbete en Bloglines
  • Suscríbete en Google