Pregunta El servidor de nombres secundario sigue intentando transferir un dominio y tiene éxito cada vez


Estamos usando BIND 9.7.3 en la versión estable de Debian (actualizada semanalmente), y vemos un comportamiento muy extraño para un dominio en particular. Tenemos unos pocos cientos, pero este es nuestro.

Básicamente, el servidor DNS secundario está intentando transferir el dominio desde el maestro. De acuerdo con los registros, logra transferir el dominio cada vez, ¡pero siempre se equivoca en el número de serie! Como resultado, sigue re-haciendo la transferencia en cada oportunidad. Ni siquiera estoy seguro de dónde está obteniendo el número de serie, porque el servidor primario informa con el Correcto número de serie.

Aquí están los registros que obtenemos de la secundaria (la ip 192.168.0.130 es el servidor principal, 192.168.0.4 es la secundaria. Y, por supuesto, no son reales):

Aug 23 03:01:08 ns2 named[4242]: transfer of 'mydomain.ca/IN/external' from 192.168.0.130#53: connected using 192.168.0.4#60959
Aug 23 03:01:08 ns2 named[4242]: transfer of 'mydomain.ca/IN/external' from 192.168.0.130#53: Transfer completed: 0 messages, 1 records, 0 bytes, 0.001 secs (0 bytes/sec)

Esto parece bastante normal, aunque ambos hosts están configurados con direcciones IPv6 y técnicamente, deberían estar usándolos, pero eso es un problema para otro día (creo).

Así que consultemos el servidor primario del secundario y veamos lo que dice:

$ host -4 -t any mydomain.ca 192.168.0.130
Using domain server:
Name: 192.168.0.130
Address: 192.168.0.130#53
Aliases: 

mydomain.ca has IPv6 address fc00:::31
mydomain.ca has SOA record ns1.mydomain.bc.ca. hostmaster.mydomain.ca. 2011082201 900 3600 604800 86400
mydomain.ca name server ns2.mydomain.bc.ca.
mydomain.ca name server ns1.mydomain.bc.ca.
mydomain.ca mail is handled by 20 pop.mydomain.ca.
mydomain.ca has address 192.168.0.205
mydomain.ca descriptive text "v=spf1 mx ip4:192.168.0.4 ip4:192.168.0.193 ip6:fc00:::23 ip6:fc00:::12 ip6:fc00:::33 a:smtp.mydomain.ca a:webmail.mydomain.ca a:smtp2.mydomain.ca a:ns2.mydomain.ca ~all"

Y luego hagamos lo mismo para el servidor de nombres secundario:

$ host -4 -t any mydomain.ca 192.168.0.4  
Using domain server:
Name: 192.168.0.4
Address: 192.168.0.4#53
Aliases: 

mydomain.ca has SOA record ns1.mydomain.bc.ca. hostmaster.mydomain.ca. 2011011013 600 600 600 600
mydomain.ca descriptive text "v=spf1 mx ip4:192.168.0.4 ip4:192.168.0.193 ip6:fc00::23 ip6:fc00::12 ip6:fc00::33 a:smtp.mydomain.ca a:webmail.mydomain.ca a:smtp2.mydomain.ca a:ns2.mydomain.ca ~all"
mydomain.ca has address 192.168.0.205
mydomain.ca mail is handled by 20 pop.mydomain.ca.
mydomain.ca name server ns1.mydomain.bc.ca.
mydomain.ca name server ns2.mydomain.bc.ca.
mydomain.ca has IPv6 address fc00::31

Aquí puede ver que el número de serie es 2011011013 en el secundario, pero 2011082201 para el primario. He usado la fecha más un número de 2 dígitos, por lo que el secundario de alguna manera usa un número de serie de enero. He intentado buscar nuestra configuración en los servidores primario y secundario para este número de serie, pero no se encuentra en ninguna parte.

Hablando de configuración, aquí está la configuración para este dominio en /etc/bind/named.conf:

zone "mydomain.ca" { type slave; file "secondaries/mydomain.ca"; masters { 192.168.0.130; }; };

y la marca de tiempo en Secondaries / mydomain.ca es el momento de la actualización más reciente. La eliminación de este archivo aún resulta en un número de serie de 2011011013. El contenido de este archivo es muy largo, pero aquí están los encabezados en el servidor secundario:

$ORIGIN .
$TTL 3600   ; 1 hour
mydomain.ca     IN SOA  ns1.mydomain.bc.ca. hostmaster.mydomain.ca. (
            2011011013 ; serial
            600        ; refresh (10 minutes)
            600        ; retry (10 minutes)
            600        ; expire (10 minutes)
            600        ; minimum (10 minutes)
            )
        NS  ns1.mydomain.bc.ca.
        NS  ns2.mydomain.bc.ca.
        A   192.168.0.205
        MX  20 pop.mydomain.ca.
        TXT "v=spf1 mx ip4:192.168.0.4 ip4:192.168.0.193 ip6:fc00::23 ip6:fc00::12 ip6:fc00::33 a:smtp.mydomain.ca a:webmail.mydomain.ca a:smtp2.mydomain.ca a:ns2.mydomain.ca ~all"
        AAAA    fc00::31
$ORIGIN mydomain.ca.

y los encabezados del archivo equivalente en el primario:

$TTL 1d
@       IN      SOA     ns1.mydomain.bc.ca. hostmaster.mydomain.ca. (
                    2011082302 ; serial
                    15m        ; refresh after 15 minutes
                    1h         ; retry after 1 hour
                    1w         ; expire after 1 week
                    1d )       ; negative caching TTL of 1 day.

    IN      NS      ns1.mydomain.bc.ca.
    IN      NS      ns2.mydomain.bc.ca.
    IN MX   20      pop.mydomain.ca.


@               IN      A       192.168.0.205

;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; SPF TXT records
;;;;;;;;;;;;;;;;;;;;;;;;;;;

mydomain.ca. TXT "v=spf1 mx ip4:192.168.0.4 ip4:192.168.0.193 ip6:fc00::23 ip6:fc00::12 ip6:fc00::33 a:smtp.mydomain.ca a:webmail.mydomain.ca a:smtp2.mydomain.ca a:ns2.mydomain.ca ~all"

; this next bit is for the Sender Policy Framework, if it ever really matters.
pop             TXT     "v=spf1 a -all"
pop3            TXT     "v=spf1 a -all"
smtp            TXT     "v=spf1 a -all"
webmail         TXT     "v=spf1 a -all"
horde           TXT     "v=spf1 a -all"

7
2017-08-23 16:22


origen


Cuando intentó eliminar la copia secundaria de la zona, ¿detuvo el servidor secundario, lo eliminó y reinició? (Eso debería forzar una plena AXFR en lugar de sólo un IXFR) - voretaq7
Sí, repetidamente. - Ernie
Podría tener la tentación de iniciar tcpdump en el servidor DNS secundario, eliminar la zona y reiniciar el enlace. Cargue la captura y vea si obtiene la zona del lugar correcto y si tiene datos válidos. - Zoredache
He visto un comportamiento como este cuando hay archivos jnl relacionados con el dominio. ¿Ya has revisado para eso? isc.org/files/arm94_0.html#journal - polynomial
Parece extraño que el registro en el servidor secundario informe una transferencia exitosa de 0 bytes. Eso no suena exitoso en absoluto ... - NorbyTheGeek


Respuestas:


revise sus permisos en el directorio del servidor secundario para las zonas. ¿Puede el proceso nombrado escribir en esa carpeta? Intente eliminar esa zona secundaria y deje que la transferencia la vuelva a crear.


2
2017-11-16 23:12





Observe que su registro BIND en el primario indica

... Transfer completed: 0 messages, 1 records, 0 bytes, 0.001 secs (0 bytes/sec)

Eso no es una confirmación de éxito. ¿Hay algún mensaje que indique un error antes de esto?


0
2017-10-28 15:01



Eso podría ser un IXFR exitoso. - MikeyB