disappearing MX records?

[Jim Reid]

>>>>> "John" == John Kerbawy <john at NOC.maKintosh.com> writes:

    John> I run BIND8 on a OpenBSD box with a DSL connection. I don't
    John> understand only 1 of the 2 domains breaks. The box that does
    John> the DNS is the primary NS for the domain that doesn't break
    John> (belluccis.com), and is the secondary domain for the domain
    John> that does break (maKintosh.com). It just so happens that the
    John> box doing the master NS for maKintosh.com has been down for
    John> around a week now. Is this the cause of my problems and if
    John> so, how do I fix it? Below is what I think is relevant from
    John> my named.conf

    John> options {
    John>	directory "/";
    John>	named-xfer "/named-xfer";
    John> };

Here's one problem. You've told the name server to run an executable
called /named-xfer when it needs to retrieve a zone with a zone
transfer. [ie when it fetches the data for any slave (secondary)
zones.] Did you really install named-xfer in the root directory?
Since there's probably nothing exectuable called named-xfer in /, the
zone transfer attempts will fail. These failures should be reported in
the name server logs.

There should also be messages in the logs about the non-availability
of the master server for makintosh.com. If that box is down, there's
nothing you can do about it apart from complain to the administrator
of that system. You can of course fix the strange choice of location
for named-xfer in the options{} statement above while you're waiting
for the master name server for makintosh.com to come back.

It's also a bit strange to make the name server use "/" as its working
directory. You might not want it to dump core in the root filesystem.
It's usually a good idea to store all the name server zone files
in one place and making this the name server's working directory. This
should be simpler to manage than sprinkling the files across various
directories in the root filesystem. If you're happy with the existing
set-up, then carry on. You're the one that manages it after all.