En la configuración de pdns.conf debes tener los parametros slave=yes y allow-axfr-ips= con las redes a las que aceptas hacer de secundario.

Debes “bautizar a cada primario” esto es condición sine qua no.

En pdns debes crear un SUPERZONA que referencia al primario en cuestión.

y listo, en tu plesk debes preocuparte que el en el SOA aparezca como primario el propio plesk, con la ip/FDQN con que lo bautizaste y el pdns debe aparecer en uno de los NS que hay en la zona.

Con esto ya lo tienes en marcha.

category “default” { “debug”; };
category “general” { “debug”; };
category “database” { “debug”; };
category “security” { “debug”; };
category “config” { “debug”; };
category “resolver” { “debug”; };
category “xfer-in” { “debug”; };
category “xfer-out” { “debug”; };
category “notify” { “debug”; };
category “client” { “debug”; };
category “unmatched” { “debug”; };
category “network” { “debug”; };
category “update” { “debug”; };
category “queries” { “debug”; };
category “dispatch” { “debug”; };
category “dnssec” { “debug”; };
category “lame-servers” { “debug”; };
channel “debug” {
file “data/nameddbg” versions 2 size 50m;
print-time yes;
print-category yes;
};

dentro del named.conf apartado logging y a continuación reiniciamos el servicio y hacemos algo parecido a: tail -f /var/named/chroot/var/named/data/nameddbg

Si es un named en producción te volverás loco, pero si no tienes información te volverás todavía mas loco así que tu mismo.

-bash-3.00# dig @a.root-servers.net. . ns

; < <>> DiG 9.2.4 < <>> @a.root-servers.net. . ns
; (2 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 40901
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14

;; QUESTION SECTION:
;. IN NS

;; ANSWER SECTION:
. 518400 IN NS I.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4
A.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:ba3e::2:30
B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201
C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12
D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90
E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10
F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241
F.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:2f::f
G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4
H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53
H.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:1::803f:235
I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17
J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30
J.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:c27::2:30

;; Query time: 122 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Mon Jun 2 10:03:11 2008
;; MSG SIZE rcvd: 500

-bash-3.00#

si queremos usarlo directamente pues hacemos un simple:

dig @a.root-servers.net. . ns >root.cache

example.com.  3600  SOA  dns.example.com. hostmaster.example.com. (
                         1999022301   ; serial YYYYMMDDnn
                         86400        ; refresh (  24 hours)
                         7200         ; retry   (   2 hours)
                         3600000      ; expire  (1000 hours)
                         172800 )     ; minimum TTL (   2 days)

Esto son los valores recomendables de forma genérica, excepcionalmente en aquellos casos en los que sea frecuente hacer cambios y queramos asegurarnos una rápida propagación podemos bajar el TTL a valores de 1hora. Si he de fijar una recomendación diría lo siguiente:

• Cambios previstos: Poner el TTL a 3600 (1hora) 2 días antes y 1 días después del cambio volver a subir el TTL a 172800
• Casos de cambios frecuentes de forma poco planificada: 14400 (4horas) este seria un valor razonable.
• 2 días te parece mucho: 1 días también puede ser razonable.

¿cuando haga un cambio cuanto tardara?¿que hace el TTL?

El TTL es el tiempo en que el registro tiene plena validez, por lo que cuando alguien consulta el DNS, se guarda ese valor y en ningún caso vuelve a verificarlo hasta pasado ese tiempo. Es por ello que estadísticamente el tiempo medio en el que TODO Internet se da cuenta de un cambio es aproximadamente la mitad del valor de TTL. Pero evidentemente si quieres curarte en salud di a tus usuarios que tardara lo que indica el TTL.

Es importante hacer crecer el serial al hacer un cambio, porque pasado el tiempo del TTL es servidor de DNS remoto verifica el Serial y si este sigue igual considerar que nada a cambiado y no reverificará de forma efectiva hasta que pase el EXPIRE.