Port 53 Idle.

[SilentRage]

While I would tend to agree with ya Jim, I do know of a case where zone transfers just aren't feasible.  I know a domain hosting company that recently set up a second server.  Nearly all the domains are "shared" and people can create subdomains on other people's domains.  For this reason, the zone files get extremely large (one zone file being 900k), and have a tendancy to be updated rather often.  He's also got thousands of zones on the server, I don't know precisely how many.  So definately the possibility of frequent full zone transfers by multiple zones can lag the servers.  I told him that Incremental Transfer would cut down on bandwidth needs, but since he modifies the zones via scripts manually, he'd have to use the BIND 9.3.0-only feature "ixfr-from-differences" which would create a huge amount of load for the CPU and memory at the master, which are already heavily used as it is.  His best solution is using an automated means of compressing the zone files and transfer
 ing them via whatever secure interface he chooses.

My only point to this comment is that sometimes Zone Transfers aren't the answer.

Dave

--- Reply to: Jim Reid <jim at rfc1035.com> ---
> 
> >>>>> "Alexandre" == Alexandre Carante <acarante at bmf.com.br> writes:
> 
>     Alexandre> Hi, I Have 11 DNS servers down here, using Bind 9 and
>     Alexandre> solaris 9, and they use to work properly, but,
>     Alexandre> suddenly, about one week ago, they're not doing "zone
>     Alexandre> transfer" alone anymore, I've write a script to
>     Alexandre> "recycle" the masters, and this Script sends the slaves
>     Alexandre> a RSHELL with, rndc stop, /usr/sbin/in.named and it use
>     Alexandre> to works just fine too, but now when someone X the
>     Alexandre> script, the zone transfers stops working, and if I run
>     Alexandre> a netstat it shows me that the IP stack port 53 is not
>     Alexandre> LISTEN, it is just in IDLE state at the master server,
>     Alexandre> the master do not "let" the slaves get the new DB
>     Alexandre> files...Is it a well know problem, have someone face
>     Alexandre> this kind o' trouble before ?
> 
> No, it's not a well known problem. Though DNS/network administrators
> sometimes create problems for themselves with zone transfers.
> 
> Please think about your question for a moment. The DNS protocol has a
> proven, reliable mechanism for synchronising and transferring zone
> data between authoritative servers. It's worked perfectly for
> years. Millions of zones use it every day and it just works. There's
> nothimg wrong with this protocol or its implementation in BIND.
> 
> If zone transfers are not working for you, there will be some sort of
> local administrative problem that's to blame. [If you'd told us the
> zone names, someone on this list could have identified the problem for
> you. Oh well.] The most likely explanation is that you're trying tp
> transfer the zone from a master server that's no longer authoritative
> for it, probably because the zone has not been loaded successfully
> Another strong possibility is a connectivity problem. An access
> control list in the master server or some firewall is blocking zone
> transfer traffic. In either case, the name server logs will be
> reporting the reason why zone transfers are failing. But you didn't
> provide revelant bits of them either. Consult your name server logs
> and if you don't understand them, post the relevant entries here. And
> don't "edit" them to obscure domain names or IP addresses.
> 
> You would be better to spend your time fixing the underlying problem
> instead of working around it with special case scripts. Less effort
> will be needed for a proper solution. And from an operational
> prespective, your DNS infrastructure won't be dependent on
> (undocumented?) kludges that make administration and maintenance a
> nightmare. That has to be a Very Good Thing.
> 
> Another thing: rsh is dangerous and insecure. Nobody should be using
> it. Remote shell access should only be offered though SSH. However for
> BIND9 administration, even this isn't needed, except for restarting
> the name server. rndc can be used to manage remote name servers.
> That's
> why it's called rndc. It uses a shared secret for authentication, so
> it's reasonably secure too.
> 
> 
> 
>