chroot, Solaris and zone transfers

Jim Reid jim at rfc1035.com
Tue May 9 22:47:00 UTC 2000


>>>>> "James" == James Hall-Kenney <James.Hall-Kenney at sytec.co.nz> writes:

    James> The master zones all load fine and give authorative answers
    James> to SOA queries.  However, a zone, "sytecsecure.co.nz" is
    James> defined on the dmz instance as a slave from the master on
    James> the public instance.  When a zone transfer occurs I get the
    James> following log entry: 

    James> 09-May-2000 19:30:18.001 xfer-in: info: Err/TO getting serial# for "sytecsecure.co.nz" 

    James> and the zone transfer fails.

This usually means the server is unable to get an answer from the
master server it's trying. The normal cause of that is a dead or
broken name server at the other end or else some problem routing
packets. I think you might get this error if the fork() and exec() of
named-xfer fails in some way too.

    James> In addition, I get errors on the system console "ld.so.1 internal: malloc failed".

This suggests that there's something missing from the chroot jail.
Consult your local man pages for ftpd and check the section on setting
up an anonymous ftp daemon. This will run chroot'ed to ~ftp. The man
page should tell you what files are needed in the chroot jail.
Typically there's a bunch of stuff from /dev, /etc and/or /usr/lib
that have to be present. What's needed depends on the OS and whether
the executables are statically or dynamically linked.

    James> I am able to perform the zone transfers manually when not
    James> chrooted using named-xfer.

Well that more or less confirms the problem lies in your chroot
environment. Maybe there's no /usr/lib/named-xfer (or whatever) in
that chroot jail. Or perhaps some library or device file is missing
from that directory and this prevents named-xfer from executing.

Your observation that statically linking named-xfer fails "with
duplicate references in nslookup" doesn't make sense. named-xfer
doesn't go anywhere near nslookup. The only things they should share
are the routines in libbind.a. Perhaps you're giving the wrong
arguments to the compiler and this is confusing things at link time?



More information about the bind-users mailing list