On Fri, Oct 10, 2008 at 4:09 PM, Kevin Darcy wrote:
> Which error? The "failed to connect" error? That's not going to have
> anything to do with the data in the zone file on the master. The most
> that'll happen with bad data is that the master will fail to load the
> zone, and you'll get SERVFAIL responses.

Thanks. It's good to know both the problems are different.

> "failed to connect" is a connectivity problem of some sort.

Any idea what could it be? None of my clients can query the DNS on the
slave. But they all can SSH, ping or traceroute to the slave. Here's
snippet of tcpdump output of querying the secondary for www.mit.edu:

55650+ A? www.mit.edu. (29)
55650 Refused- 0/0/0 (29)

nmap port 53 shows it's open.

> What does nmap mean by "is filtered"? I'm not sure what it's trying to
> denote.

means nmap can't determine if it's open or closed.

> I'd recommend doing a tcpdump of your *actual* refresh queries. You can

tcpdump shows the slave goes to the primary but the primary doesn't
give anything back for domain.com. I have another domain file that
gets updated from the same primary to the same secondary and that file
is ok as far as zone transfer is concerned.

> As for copying the zone file from somewhere else, if you have another
> slave you can get the zone from, more power to you. Just point the
> "masters" clause at it.

No I don't have another slave. I moved the domain.com file from the
secondary and restarted bind but it still times out.