<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hola Manuel</p>
<p>Como dijo Jorge, si el problema está en los root servers. Además
en el fichero "<i><b>named.conf.options</b></i>" debes especificar
tanto para la zona directa como para la inversa que ip o redes van
a hacer uso de ella, en este caso todos los bloques /29 que
definiste para los estudiantes. Así podrán cada uno revisar ambas
zonas y actualizarse una vez que se realicen cambios en el padre.
<br>
</p>
<p>S, P<br>
</p>
<br>
<div class="moz-cite-prefix">On 11/03/2016 10:06 PM, Jorge Villa
wrote:<br>
</div>
<blockquote
cite="mid:E0DD9F6E-2562-4B6C-94D4-EA1767F4A445@reduniv.edu.cu"
type="cite">
<pre wrap="">Hola Manuel, como estas?
El problema que tienes (tanto en la resolución directa como inversa) me parece que esta en que tus clientes están haciendo (o intentando hacer) el proceso de resolución consultando los root servers reales, y por eso no tienes resolución en las zonas modificadas. Te recomiendo revisar el trabajo Esclavizando la zona raíz, que presento Carlos Martinez en el LACNOG de Costa Rica (<a class="moz-txt-link-freetext" href="https://www.dropbox.com/s/cjghha9z66kcuep/slaving-the-root-zone-00.pdf?dl=0">https://www.dropbox.com/s/cjghha9z66kcuep/slaving-the-root-zone-00.pdf?dl=0</a>). Por ahí te puedes guiar para completar tu diseño.
Saludos,
Jorge Villa
El 11/3/16 7:48 PM, "LACNOG en nombre de Manuel José Linares Alvaro" <a class="moz-txt-link-rfc2396E" href="mailto:lacnog-bounces@lacnic.netennombredecheche@udg.co.cu"><lacnog-bounces@lacnic.net en nombre de cheche@udg.co.cu></a> escribió:
Duda sobre resolución inversa en servidores DNS y delegación del control de
zonas.
Hola amigos.
En estos momentos un grupo de profesores estamos preparando un curso sobre
DNS, y para ello hemos creado una estructura virtual donde cada estudiante
tiene una red con
prefijo /29, un router que es la puerta de enlace de esa red y 2 VMs con
linux Ubuntu 14.04.4. todo eso funciona de maravillas.
La idea es que en cada estudiante tenga sus propias estaciones de trabajo
para implementar el BIND y probar diferentes configuraciones.
Pretendo que cada estudiante tenga además su propia zona de dominio y la
controle con sus DNS.
Mas o menos como se muestra en la figura adjunta.
En un DNS externo, delegué el control de zonas de dominio, tanto de
resolución directa como inversa, a las IPs de cada uno de los futuros DNS de
los estudiantes.
Para probar, instalé un DNS en una de las máquinas virtuales destinadas a
los estudiantes.
Logro delegar, sin problemas, el control de zonas para la resolución directa
e inversa, pero falla algo:
La resolución directa funciona de maravillas, tanto en el DNS externo o
real, como en el interno o virtual.
Ahora bien, aquí viene el problema.
La resolución inversa de una solicitud a alguna de las IP de la red virtual
donde se encuentran los DNS virtuales, funciona bien desde el DNS externo o
real, es decir, si desde el DNS externo que delega el control de zonas
inversas a los DNS internos, hago una consulta, funcioina bien, por ejemplo:
[root@mediaserver internal]# nslookup
> 10.62.0.41
Server: 200.14.53.4
Address: 200.14.53.4#53
41.0.62.10.in-addr.arpa canonical name = 41.40/29.0.62.10.in-addr.arpa.
41.40/29.0.62.10.in-addr.arpa name = cisco.g0.udg.co.cu.
>
>
.. y pude comprobar sin lugar a dudas que el DNS externo hace una consulta
recursiva al DNS interno que es el que tiene delegado el control de zonas.
Ahora, si desde el servidor DNS que controla esa zona, es decir, desde la
10.62.0.42, que es una VM, hago una consulta similar, lo que obtengo es lo
siguiente:
root@1404:/home/reduniv# nslookup
> 10.62.0.42
Server: 10.62.0.42
Address: 10.62.0.42#53
** server can't find 42.0.62.10.in-addr.arpa: NXDOMAIN
>
les muestro los archivos de configuración de la zona para documentar mejor
mis dudas:
en el DNS real:
zona: 0.62.10.in-addr.arpa
Declaración de la zona:
zone "0.62.10.in-addr.arpa" IN {
type master;
file "data/internal/0.62.10.in-addr.arpa";
allow-update { none; };
};
Archivo de datos de la zona
$ORIGIN 0.62.10.in-addr.arpa.
$TTL 86400
@<----->IN<---->SOA<--->mediaserver.udg.co.cu. root.udg.co.cu. (
<------><------><------>2010062401 <--->; serial
<------><------><------>21600 <><------>; actualiza después de 6 horas
<------><------><------>3600 <-><------>; reintenta después de 1 hora
<------><------><------>604800 ><------>; expira en 1 semana
<------><------><------>86400 <><------>; TTL mínimo de 1 dia
<------><------><------>)
<------>IN<---->NS<---->mediaserver.udg.co.cu.
40/29<->IN<---->NS<---->vm1.g0.udg.co.cu.
41<---->IN<---->CNAME<->41.40/29.0.62.10.in-addr.arpa.
42<---->IN<---->CNAME<->42.40/29.0.62.10.in-addr.arpa.
43<---->IN<---->CNAME<->43.40/29.0.62.10.in-addr.arpa.
44<---->IN<---->CNAME<->44.40/29.0.62.10.in-addr.arpa.
45<---->IN<---->CNAME<->45.40/29.0.62.10.in-addr.arpa.
46<---->IN<---->CNAME<->46.40/29.0.62.10.in-addr.arpa.
En los DNS virtuales:
Zona: 40/29.0.62.10.in-addr.arpa
Declaración de la zona:
zone "40/29.0.62.10.in-addr.arpa" {
type master;
file "/etc/bind/zones/db.10.62.0.40"; # 10.62.0.40/29 subnet
};
;
; BIND reverse data file for local loopback interface
;
$ORIGIN 40/29.0.62.10.in-addr.arpa.
$TTL<-->604800
@<----->IN<---->SOA<--->vm1.g0.udg.co.cu. root.g0.udg.co.cu. (
<------><------><------> 3><------>; Serial
<------><------><------> 604800><------>; Refresh
<------><------><------> 86400><------>; Retry
<------><------><------>2419200><------>; Expire
<------><------><------> 604800 )<----->; Negative Cache TTL
IN NS vm1.g0.udg.co.cu.
41<---->IN<---->PTR<--->cisco.g0.udg.co.cu.
42<---->IN<---->PTR<--->vm1.g0.udg.co.cu.
43<---->IN<---->PTR<--->vm2.g0.udg.co.cu.
Agradecería mucho la ayuda de alguien. He revisado los libros de DNS de
Orreily y todo parece estar bien. he probado otras variantes sin éxito,
incluso los registros de los DNS no muestran errores de ninguna clase.
Como los DNSs internos, no tienen salida a redes públicas, declaré el DNS
externo como un servidor raíz de los primeros, de manera tal que las
consultas que éstos no pudieran resolver, las enviaran al externo.
Saludos,
Manuel Linares,
Universidad de Granma
* * * * *
Universidad de Granma
<a class="moz-txt-link-freetext" href="http://www.udg.co.cu">http://www.udg.co.cu</a>
Participe en el VI Congreso Cubano de Desarrollo Local,
Hotel Sierra Maestra, Bayamo, Granma, Cuba, del 28 al
30 de marzo de 2017.
_______________________________________________
Cubanog mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cubanog@reduniv.edu.cu">Cubanog@reduniv.edu.cu</a>
<a class="moz-txt-link-freetext" href="http://listas.6ip.cu/mailman/listinfo/cubanog">http://listas.6ip.cu/mailman/listinfo/cubanog</a>
_______________________________________________
LACNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
_______________________________________________
LACNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
Ing. Pedro V. Navarrete Alejo <br>
Especialista B en Ciencias Informáticas <br>
telf: (537) 683-2814 <br>
<b><i>LACETEL</i></b>, Instituto de Investigación y Desarrollo de
Telecomunicaciones <br>
<a href="http://www.lacetel.cu">www.lacetel.cu</a><br>
<p> Twitter: @LACETEL_Pedro </p>
</div>
</body>
</html>