not listening on any interface

[Kevin Darcy]

You've verified that the internal instance is only limited to listening on
the internal interface (and possibly also loopback), right? Seems from what
you're saying that the external instance runs fine by itself, even on the
internal interface, but you can't run both at the same time. This implies
that the internal instance is the source of the problem.


- Kevin

gstaniak at inka.zagiel.pl wrote:

> Hello,
>
> I'm trying to implement a split DNS schema on a firewall machine, using
> two bind instances listening on two interfaces (LAN, WAN), with the LAN
> instance using the WAN instance as a forwarder. This kind of setup
> worked with an older version of bind (8.2.3). Now I'm trying to use
> 9.2.0rc3 (I know there's a final 9.2.0, I'm waiting for Mandrake to
> produce an updated package), and I keep getting the above mentioned
> message in my log file for the WAN interface. Sorry I don't post a log
> snippet, I don't have access to the machine in question right now,
> anyway, I don't see there any other indications of what is going on:
> bind just tells me it's reading config data, it doesn't find IPv6
> interfaces, and then "not listening on any interface", just before
> "startup suceeded".
>
> The two instances do not share anything in terms of config data or
> resources, rnds processes run on two separate ports, after startup I see
> 'named' processes running, everything seems ok, it just doesn't listen
> on the address it gets in the config file. I searched this newsgroup
> through Google - the common answers do not apply: there are no other
> processes blocking port 53 etc. I ran the troublesome (WAN) instance
> alone with '-f -d 9' - no problems in the data files, a number of
> running processes, but still "not listening on any...". When I replaced
> the external NIC address in the "listen" directive with the internal NIC
> address, it starts up OK and runs without any problems.
>
> Does anybody have an idea of what might be the problem? I'll be grateful
> for any suggestions.
>
> TIA,
>
> --
> Grzegorz Staniak <gstaniak at zagiel.pl>