bind 9.10..0-P1 rndc: 'retransfer' failed: not found; other rndc commands are ok

[grantk...@operamail.com]

I have bind 9.10.0-P1 installed, and running in a chroot.

which named
/usr/local/bind9/sbin/named
which rndc
/usr/local/bind9/sbin/rndc

named -v
BIND 9.10.0-P1

ps ax | grep named
7110 ? Ssl 0:18 /usr/local/bind9/sbin/named -t
/var/chroot/named -n 4 -S 1024 -u named -c /etc/named.conf -d 90

/usr/local/bind9/sbin/named-checkconf -t /var/chroot/named
/etc/named.conf
(empty)


All lookups are working. Transfers to slaves work as expected when I
increment zone serials and restart the server. But when I try to
initiate a retransfer using rndc, the 'retransfer' command isn't found:

rndc status
version: 9.10.0-P1 (not disclosed) <id:e94d8db1>
boot time: Fri, 23 May 2014 01:10:39 GMT
last configured: Fri, 23 May 2014 01:48:35 GMT
CPUs found: 4
worker threads: 4
UDP listeners per interface: 2
number of zones: 235
debug level: 90
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running

rndc -V reload my.localzone.net in external
create memory context
create socket manager
create task manager
create task
create logging context
setting log tag
creating log channel
enabling log channel
create parser
get default key
get config key list
decode base64 secret
reload
post event
using server 127.0.0.1 (127.0.0.1#953)
create socket
bind socket
connect
create message
render message
schedule recv
send message
parse message
create message
render message
schedule recv
send message
parse message
zone reload up-to-date

rndc -V retransfer my.localzone.net in external
create memory context
create socket manager
create task manager
create task
create logging context
setting log tag
creating log channel
enabling log channel
create parser
get default key
get config key list
decode base64 secret
retransfer
post event
using server 127.0.0.1 (127.0.0.1#953)
create socket
bind socket
connect
create message
render message
schedule recv
send message
parse message
create message
render message
schedule recv
send message
parse message
rndc: 'retransfer' failed: not found

I've looked around online, and 'retransfer' seems to still be a valid
command.

What's wrong with my usage of retransfer?

Grant

[Mark Andrews]

In message <1400811069.27931....@webmail.messagingengine.com>, g

rantks...@operamail.com writes:
> I have bind 9.10.0-P1 installed, and running in a chroot.
>
> which named
> /usr/local/bind9/sbin/named
> which rndc
> /usr/local/bind9/sbin/rndc
>
> named -v
> BIND 9.10.0-P1
>
> ps ax | grep named
> 7110 ? Ssl 0:18 /usr/local/bind9/sbin/named -t
> /var/chroot/named -n 4 -S 1024 -u named -c /etc/named.conf -d 90
>
> /usr/local/bind9/sbin/named-checkconf -t /var/chroot/named
> /etc/named.conf
> (empty)
>
>
> All lookups are working. Transfers to slaves work as expected when I
> increment zone serials and restart the server. But when I try to
> initiate a retransfer using rndc, the 'retransfer' command isn't found:

No it isn't. It is saying the zone isn't found. "unknown command" is
returned for unknown commands.

rndc: 'xxxxx' failed: unknown command

Mark

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

[grantk...@operamail.com]

> No it isn't. It is saying the zone isn't found. "unknown command" is
> returned for unknown commands.
>
> rndc: 'xxxxx' failed: unknown command

Ok, but the zone IS there.

It's found by other rndc commands.

It's loaded by bind on start.

It's transferred to slaves, again on (re)start.

Why isn't it finding the zone?

[Mark Andrews]

In message <1400812816.1479.1...@webmail.messagingengine.com>, gr

Presumably it is not a slave or a stub. retransfer is only applicable to
slave and stub zones.

[Teerapatr Kittiratanachai]

Sorry for jumping in, so from your information I understand that when I have updated zone file at the master I should use `rndc reload <zone-name>` instead `rndc retransfer <zone-name>` to transfer the new zone file to other slaves, is it right ?

Regards,

T. Kittiratanachai (Te)

[Doug Barton]

On 05/22/2014 09:33 PM, Teerapatr Kittiratanachai wrote:
> Sorry for jumping in, so from your information I understand that when I
> have updated zone file at the master I should use `rndc reload
> <zone-name>` instead `rndc retransfer <zone-name>` to transfer the new
> zone file to other slaves, is it right ?

Yes, you reload the zone on the master which should cause the master to
send notifies to the slaves which cause them to retransfer the zone.

The 'rndc retransfer <zone>' command is something you run on the slave
if it doesn't transfer.

hope this helps,

Doug

[Chris Thompson]

Note that "rndc retransfer <zone>" is fairly brutal. It tells the slave
to forget everything about its current copy of the zone, including its
SOA serial, and attempt a full zone transfer from the master(s).

In normal circumstances, a missed notify would be better dealt with by
"rndc refresh <zone>", which just expedites what would normally happen
when the refresh interval expires. That is, it will do an SOA query
against the master(s), and if the serial has increased attempt an
(if possible incremental) zone transfer.

--
Chris Thompson
Email: ce...@cam.ac.uk