[opensuse-es] dns tratando de sobrevivir
Hola amigos, instale todo de nuevo, ahora a pedal, no ha habido ningun problema hasta ahora, de hecho hice una transferencia de zona con el master que es un guindous dns con pdc y una pizca de sal. la transferencia de la zona bav.com.ve me funciono a las mil maravillas, salvo por un global catalog que no se con que se come pero que no le gusto por el nombre del objeto, del resto todo bien. slave/bav.com.ve:105: gc._msdcs.bav.com.ve: bad owner name (check-names) el adm de guindous me autorizo tambien las transferencias de zonas reversas y estas fallaron.... el log de las fallas es siempre el siguiente: client 172.18.52.67#1036: received notify for zone '254.22.172.in-addr.arpa': not authorative client 172.18.52.67#1036: received notify for zone '52.18.172.in-addr.arpa': not authorative ahora esta es mi pregunta.... yo en mi named.conf no tengo incluidas estas zonas, de hecho en /var/lib/named/ nisiquiera tengo una carpeta que se llame reverse o nada parecido.... es esto lo que esta fallando?, como le incluyo el dns reverso para que me acepte estas zonas? -- Ciao, Javier linux counter #393724 GPG Key Fingerprint = 46B76CFEDB0161089D9ECB22FEFDE7EBA8C2007E I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) --Linus Torvalds --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2007/1/4, javier rojas:
el log de las fallas es siempre el siguiente:
client 172.18.52.67#1036: received notify for zone '254.22.172.in-addr.arpa': not authorative client 172.18.52.67#1036: received notify for zone '52.18.172.in-addr.arpa': not authorative
ahora esta es mi pregunta....
yo en mi named.conf no tengo incluidas estas zonas, de hecho en /var/lib/named/ nisiquiera tengo una carpeta que se llame reverse o nada parecido....
Revisa -sin Yast ;-)- el fichero de configuración y compáralo con algunos ejemplos de dns configurados como "forwarders", por ejemplo: http://www.zytrax.com/books/dns/ch6/index.html#forwarding Ese mensaje de "no authoritative" que te muestra más que un error parece un simple aviso ¿no? http://forums.dnsstuff.com/tool/post/dnsstuff/vpost?id=953100 Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola,
Revisa -sin Yast ;-)- el fichero de configuración y compáralo con algunos ejemplos de dns configurados como "forwarders", por ejemplo:
pero este no es forwarder, es un slave.... todas las zonas de dns y reverso en teoria deberian venir de mi master que en este caso es el guindous...
Ese mensaje de "no authoritative" que te muestra más que un error parece un simple aviso ¿no?
http://forums.dnsstuff.com/tool/post/dnsstuff/vpost?id=953100
a lo mejor es un error, pero en /var/lib/named no me aparecen nigun tipo de zona reversa, cuando busco la documentacion de novell me encuentro que deberia aparecer un archivo por cada zona reversa que es transferida http://www.novell.com/documentation/sles10/index.html?page=/documentation/sl... pero en micaso no aparece, no se si es que a mano tengo que incluir esas zonas que el guindous esta tratando de trasnferirme y darle el allow-trasnfer o si debo darle otro tipo de configuracion.... -- Ciao, Javier linux counter #393724 GPG Key Fingerprint = 46B76CFEDB0161089D9ECB22FEFDE7EBA8C2007E I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) --Linus Torvalds --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Viernes, 5 de Enero de 2007 13:42, javier rojas escribió:
pero en micaso no aparece, no se si es que a mano tengo que incluir esas zonas que el guindous esta tratando de trasnferirme y darle el allow-trasnfer o si debo darle otro tipo de configuracion....
* Las zonas inversas son unas zonas mas en /etc/named.conf, va un ejemplo: zone "0.26.172.in-addr.arpa" in { type slave; file "slave/172.26.0.zone"; allow-query { any; }; allow-transfer { ip.que.pueda.transferirla; otra.ip.que.pueda; }; masters { la.ip.del.maestro; }; }; * De todas maneras me ha parecido ver que era una zona con ip's locales, si el esclavo es un servidor remoto no tiene sentido transferir las zonas locales ni directas ni inversas. * Ejecuta SuSEconfig una vez modificado named.conf
perdon por mi ignorancia....
no entiendo pq no se le transfieren las zonas a un servidor esclavo si
es remoto...
al final la idea es no demorar el enlace para encontrar una ruta, mi
idea era saber que ruta tomar sin tener que ir a preguntar....
2007/1/5, jose maria
El Viernes, 5 de Enero de 2007 13:42, javier rojas escribió:
pero en micaso no aparece, no se si es que a mano tengo que incluir esas zonas que el guindous esta tratando de trasnferirme y darle el allow-trasnfer o si debo darle otro tipo de configuracion....
* Las zonas inversas son unas zonas mas en /etc/named.conf, va un ejemplo:
zone "0.26.172.in-addr.arpa" in { type slave; file "slave/172.26.0.zone"; allow-query { any; }; allow-transfer { ip.que.pueda.transferirla; otra.ip.que.pueda; }; masters { la.ip.del.maestro; }; };
* De todas maneras me ha parecido ver que era una zona con ip's locales, si el esclavo es un servidor remoto no tiene sentido transferir las zonas locales ni directas ni inversas.
* Ejecuta SuSEconfig una vez modificado named.conf
-- Ciao, Javier linux counter #393724 GPG Key Fingerprint = 46B76CFEDB0161089D9ECB22FEFDE7EBA8C2007E I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) --Linus Torvalds --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2007/1/5, javier rojas:
al final la idea es no demorar el enlace para encontrar una ruta, mi idea era saber que ruta tomar sin tener que ir a preguntar....
Como forwader yo tengo puesto un isp, es decir, el servidor dns está configurado como dns primario para resolver las direcciones "locales", de la red interna, del tipo "linux.site" y las externas. Sólo cuando no puede encontrar alguna dirección le pregunta al isp, en este caso, telefónica, que lo tengo como "forwarder". Si lo que quieres es que "todas las resoluciones de nombre" incluso las locales del tipo "linux.site" sean dirigidas al servidor dns primario (en este caso el equipo con Windows) entiendo que tu servidor dns no necesita tener zonas ni primarias ni secundarias sino que actúa como una especia de "caché" que no pregunta, sencillamente manda todo al otro servidor dns ¿no?. Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
exactamente, esa es la idea, el dns principal (win) esta orientado con el de nuestro isp, que a su vez esta conectado con el isp principal de Venezuela... mi pequenho servidor sles servira como cache de las zonas contenidas en el primario para la oficina donde quiero instalarlo, la idea es que como el enlace es muy pobre, no quiero utilizarlo para resolver las direcciones si no que pregunte localmente al sles y este le responda con las zonas transferidas desde el win... les pregunto...que les parece esta idea?, esta mal orientada o le hace falta algo mas?
Como forwader yo tengo puesto un isp, es decir, el servidor dns está configurado como dns primario para resolver las direcciones "locales", de la red interna, del tipo "linux.site" y las externas. Sólo cuando no puede encontrar alguna dirección le pregunta al isp, en este caso, telefónica, que lo tengo como "forwarder".
Si lo que quieres es que "todas las resoluciones de nombre" incluso las locales del tipo "linux.site" sean dirigidas al servidor dns primario (en este caso el equipo con Windows) entiendo que tu servidor dns no necesita tener zonas ni primarias ni secundarias sino que actúa como una especia de "caché" que no pregunta, sencillamente manda todo al otro servidor dns ¿no?.
Saludos,
-- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-- Ciao, Javier linux counter #393724 GPG Key Fingerprint = 46B76CFEDB0161089D9ECB22FEFDE7EBA8C2007E I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) --Linus Torvalds --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Viernes, 5 de Enero de 2007 17:29, javier rojas escribió:
perdon por mi ignorancia....
no entiendo pq no se le transfieren las zonas a un servidor esclavo si es remoto...
al final la idea es no demorar el enlace para encontrar una ruta, mi idea era saber que ruta tomar sin tener que ir a preguntar....
* Yo no he dicho que no se transfieran las "zonas" a los servidores esclavos, se transfieren todas las que esten correctamente configuradas) * Digo que si el servidor esclavo (uno) NO atiende las mismas redes locales que el primario (como seria el caso de infraestructuras locales de gran tamaño donde hay mas de un servidor por si falla el primario poder resolver los nombres locales, pero no parece ser el caso, aunque incluso en muchos de estos casos yo soy partidario de la configuracion estatica, por razones que no vienen a cuento), que utilidad le ves tu a tranferir unos nombres e ip's de unas redes de otra red remota (consultables via internet) a un dns que seguramente este atendiendo SUS propias redes locales, tendrias que poner vistas (ya que perderias ips y nombres coincidentes o te enfrentarias a un "lio" de resolucion y trabajo administrativo) y la vista externa que es adonde irian a parar las tranferencias de la red remota, en un momento dado "podrian" ser visibles al exterior ofreciendo datos interesantes.
bueno, te comprendo perfectamente y te comento a ver que te parece....
digamos que mi servidor sles se va a encargar de resolverle a los
clientes de la vlan 172.22.254.x, que realmente no son mas de 20
maquinas, estas maquinas no tienen acceso a Internet, estas maquinas
en el 70% de los casos hacen consultas de la red local, pero
actualmente las hacen a Caracas....
sumale tambien el 30% de los casos en que le hacen consultas al
servidor guindous que esta en Caracas por rutas de x cosa que esta en
otro segmento de la red de la organizacion...
pienso yo que es mejor cachear las zonas que tenga mi guindous una vez
al dia, resolver esas consultas que generan ese trafiquillo adicional
y mientras tanto puedo quitarle la funcion de dhcp al router y se la
doy al sles...
a ver que te parece....
2007/1/5, jose maria
El Viernes, 5 de Enero de 2007 17:29, javier rojas escribió:
perdon por mi ignorancia....
no entiendo pq no se le transfieren las zonas a un servidor esclavo si es remoto...
al final la idea es no demorar el enlace para encontrar una ruta, mi idea era saber que ruta tomar sin tener que ir a preguntar....
* Yo no he dicho que no se transfieran las "zonas" a los servidores esclavos, se transfieren todas las que esten correctamente configuradas)
* Digo que si el servidor esclavo (uno) NO atiende las mismas redes locales que el primario (como seria el caso de infraestructuras locales de gran tamaño donde hay mas de un servidor por si falla el primario poder resolver los nombres locales, pero no parece ser el caso, aunque incluso en muchos de estos casos yo soy partidario de la configuracion estatica, por razones que no vienen a cuento), que utilidad le ves tu a tranferir unos nombres e ip's de unas redes de otra red remota (consultables via internet) a un dns que seguramente este atendiendo SUS propias redes locales, tendrias que poner vistas (ya que perderias ips y nombres coincidentes o te enfrentarias a un "lio" de resolucion y trabajo administrativo) y la vista externa que es adonde irian a parar las tranferencias de la red remota, en un momento dado "podrian" ser visibles al exterior ofreciendo datos interesantes.
-- Ciao, Javier linux counter #393724 GPG Key Fingerprint = 46B76CFEDB0161089D9ECB22FEFDE7EBA8C2007E I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) --Linus Torvalds --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Viernes, 5 de Enero de 2007 23:03, javier rojas escribió:
bueno, te comprendo perfectamente y te comento a ver que te parece....
digamos que mi servidor sles se va a encargar de resolverle a los clientes de la vlan 172.22.254.x, que realmente no son mas de 20 maquinas, estas maquinas no tienen acceso a Internet, estas maquinas en el 70% de los casos hacen consultas de la red local, pero actualmente las hacen a Caracas....
sumale tambien el 30% de los casos en que le hacen consultas al servidor guindous que esta en Caracas por rutas de x cosa que esta en otro segmento de la red de la organizacion...
pienso yo que es mejor cachear las zonas que tenga mi guindous una vez al dia, resolver esas consultas que generan ese trafiquillo adicional y mientras tanto puedo quitarle la funcion de dhcp al router y se la doy al sles...
a ver que te parece....
* A mi no me parece mal, por que con la aclaracion echa estamos en el caso de que ambos servidores estan en "LA" red local (esten enlazadas por vpn o por lo que sea es red local), en este caso yo configuraria un servidor con zonas maestras para la red 172.22.254.x, con vistas, cuya vista interna resuelva todo para la vlan (las zonas 172.22.254.x) y los ficheros correspondientes a la red remota, configurados en la misma view se leerian de ../slave/ que le habra tranferido el windows, asi como que ejerza de servidor secundario de las peticiones desde internet (para la resolucion de dominios de la empresa) * El wilson deberia estar configurado de la misma manera, es decir deberia ser esclavo de las zonas que controla el linux. * En los clientes de uno y otro lado, el primario seria el de su propia red y el secundario el accesible a traves del enlace vlan. * Se que puede parecer mas lioso a priori, pero una vez hecho, hecho esta, a la hora de gestionar a mi me gusta meterle mano al que resuelve (como primario) cada red, nada mas, de hecho como ya te he comentado no me gusta transferir las zonas "conocidas", algunas de las razones fundamentales es el acotamiento de fallos de configuracion o caida y las migraciones de versiones incompatibles, esta ultima en una gran organizacion es critica, conozco administradores que arrastran a base de parcheo versiones antidiluvianas por verse en la obligacion de migrar "todos" de golpe (por la configuracion y transferencias, que en principio ahorran trabajo pero ........).
participants (3)
-
Camaleón
-
javier rojas
-
jose maria