Hola a todos.

Tengo el siguiente inconveniente con mi dns esclavo, es que las zonas no se actualizan, al reiniciar el servicio puedo percatarme en los logs;

starting BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 -u named -t /var/named/chroot
adjusted limit on open files from 1024 to 1048576
found 2 CPUs, using 2 worker threads
using up to 4096 sockets
loading configuration from '/etc/named.conf'
using default UDP/IPv4 port range: [1024, 65535]
using default UDP/IPv6 port range: [1024, 65535]
listening on IPv4 interface lo, 127.0.0.1#53
listening on IPv4 interface eth0, 190.121.160.2#53
command channel listening on 127.0.0.1#953
the working directory is not writable
zone 0.in-addr.arpa/IN: loaded serial 42
zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700

AQUI EMPIEZA A LEER TODAS MI ZONAS Y TODO BIEN HASTA QUE

: zone midominio.com.py/IN: Transfer started.
: transfer of '168.192.160.in-addr.arpa/IN' from 160.192.168.1#53: connected using 160.192.168.2#49357
: transfer of 'midominio.com.py/IN' from 160.192.168.1#53: connected using 160.192.168.2#58543
: dumping master file: tmp-3uuhS2Ln7N: open: permission denied
: transfer of '168.192.160.in-addr.arpa/IN' from 160.192.168.1#53: failed while receiving responses: permission denied
: transfer of '168.192.160.in-addr.arpa/IN' from 160.192.168.1#53: end of transfer

el primer inconveniente que veo es el tema que no se puede escribir en el directorio de trabajo, ahora a cual hace referencia /var/named o cual, si es ese lo he verificado y esta ok. El segundo inconveniente lo de dumping master file: de esto ni la mas minima idea, seria tan amables de hecharme una mano. Desde ya un monton de gracias

---

Oscar Cáceres

Que Distribucion usas?? intenta darle permisos de escritura al direcctorio donde estan las zonas puede ser /var/named/chroot/var/named/slaves/ pero cambia dependiendo de la distribucion y tienes que estar seguro que en la configuracion del maestro tengas una linea por cada zona:
allow-transfer {
ipserveresclavo;
};
A mi me paso un problema similar al actualizar pero cambiando los permisos en las carpetas se arreglo, ya sea dando permisos de escritura o cambiandolas de propietario

Hola

La distro que utilzo es centos5 y mis zonas estan en /var/named/chroot/var/named/

el cual tiene estos permisos

drwxr-x--- 4 root named 4096 feb 26 16:32 named

y el allow-transfer se encuentra en el maestro. Alguna otra idea?

---

Oscar Cáceres

ya intentaste darle un chmod 777 solo para ver si corrije el error.

¿Tienes activo SELinux???

Verifica políticas y también los contextos (ls -Z)

Si están incorrectos:

Hola a ambos;

moy te agradesco la ayuda pero no fue eso, el Sr. Barrios le dio en el ojo. Los inconvenientes anteriormente citados ya no aparecen en los log, pero en ves de ellos estan estos;


client 192.168.0.2#55346: received notify for zone '111.111.111.in-addr.arpa'
zone 111.111.111.in-addr.arpa/IN: refused notify from non-master: 192.168.0.2#55346

---

Oscar Cáceres

Este mensaje significa una de tres posibilidades:

a) El servidor maestro no está configurado para permitir transferir la zona al esclavo. Verifica que tengas allow-transfer { xx.xx.xx.xx; }; en la configuración del la zona maestra.

b) El archivo de zona del esclavo difiere del maestro. Reemplaza en el esclavo el archivo de zona por una copia idéntica del archivo de zona del maestro.

c) El archivo de zona tiene registros NS, pero falta uno que defina al servidor esclavo. Añade en el archivo de zona de ambos servidores un registro NS que defina al esclavo.

Como esta Sr. Barrios.

He analizado las 3 opsiones que me indico y efectivamente era la tercera (c). He definido un registro NS con el hostname del server esclavo en ambos servidores. Y ahora en mis log puedo percatarme do lo siguiente:

a) Al hacer estos cambios comentados y reiniciar el servicio en el servidor maestro, los errores mecionados anteriormente ya no aparecen y las zona es actualizada en el servidor esclavo, pero en comparasion con la zona del server maestro en el esclavo se encuentra desordenado.

b) Si lo que reinicio es el servicio en el servidor esclavo siguen apareciendo los errores anteriormente citados;

client 192.168.0.2#55346: received notify for zone '111.111.111.in-addr.arpa'
zone 111.111.111.in-addr.arpa/IN: refused notify from non-master: 192.168.0.2#55346

---

Oscar Cáceres

Solo sincroniza los archivos de zona en ambos servidores. El esclavo debe iniciar con una copia exacta del maestro para poder realizar operaciones de sincronización.

Sr. Barrios.

Las zonas se actualizan pero quedan de esta forma:

DNS MAESTRO

$TTL 57600
@ IN SOA ns1.midominio.com.py. ocaceres.midominio.com.py. (
2010031301 ; Serial
10800 ; Refresh
900 ; Retry
1209600 ; Expire
57600 ) ; Minimum

@ IN NS ns1.midominio.com.py.
@ IN NS ns2.midominio.com.py.

30 IN PTR mail.midominio.com.py.
162 IN PTR mail.otrodominio.com.py.
162 IN PTR cameras.midominio.com.py.
182 IN PTR mail.otrodominio.com.py.

DNS ESCLAVO

$ORIGIN .
$TTL 57600 ; 16 hours
161.121.190.in-addr.arpa IN SOA ns1.midominio.com.py. ocaceres.midominio.com.py. (
2010031301 ; serial
10800 ; refresh (3 hours)
900 ; retry (15 minutes)
1209600 ; expire (2 weeks)
57600 ; minimum (16 hours)
)
NS ns1.midominio.com.py.
NS ns2.midominio.com.py.
$ORIGIN 161.121.190.in-addr.arpa.
162 PTR mail.midominio.com.py.
PTR cameras.midominio.com.py.
182 PTR mail.otrodominio.com.py.
30 PTR mail.otrodominio.com.py.

Esto esta bien o abria algo que pulir?.

---

Oscar Cáceres

La zona de resolución inversa tiene poco o ningún sentido que la hagas porque esa se supone la debe de hacer el proveedor de servicio. Elimina la resolución inversa y solicita a tu proveedor la resolución inversa de las IP ue tienes asignadas.

Sr. Barrios.

Agredesco infinitamente su ayuda. Le comento que esas reslusiones inversas se debe a que esas clases estan asignadas a la empresa para la cual me encuentro prestando servicios el cual es un ISP rason por la cual se encuentra configurada alli.

Nuevamente un monton de gracias señor.

---

Oscar Cáceres

Verifica con whois dirección-IP que tengas asignado a ti los bloques de IPs.

whois xx.xx.xx.xx

Quien devuelva como autoridad de la zona, es quien debe hacer la resolución inversa. Si te asignó el bloque tu porveddor, coteja que haya sido así por completo. Si la ICAAN fuen quien asigno los bliues, segurametne te toca hacer las resoluciones inversa. Si te las asignó solo tu proveedor, es factible que tenga que hacerlas tu proveedor.

Muy agradecido una vez mas señor barrios, aqui poseemos un segmento de direcciones ip publicas /20 asignadas por LACNIC, nosotros hacemos el reverso de nuestras ip. Las zonas en el servidor esclavo se siguen actualizando de forma desordenada, creo, esta en el formato que he enviado. Anduve haciendo pruebas desde fuera de mi red y puedo percatarme que eso no es un inconveniente, aparentemente.

---

Oscar Cáceres