AW: AW: BIND9 behind NAT: no reverse lookup from external net

[Markus Wollny]

Hi!=20

> "Markus Wollny" <Markus.Wollny at computec.de> wrote:
>=20
> > I think it might be a delegation problem on behalf of our provider=20
> > (it's
>=20
> The delegation (from 212.in-addr.arpa) looks OK:

Okay, so that's not the source of my problems then.

> I doubt that.  I would consult your firewall admin to see if=20
> there's any config on it to intercept PTR queries.  Also you=20
> could turn on query-logging on your nameserver to see if it=20
> actually gets the PTR queries for this zone.

Apparently it does, I switched on query-logging for a while and did a
reverse lookup from a remote box:
Mar  2 15:50:38 localhost named[32068]: client 212.123.106.145#42544:
query: 12.0.168.192.in-addr.arpa IN PTR

And I still cannot imagine that it's due to a firewall problem:

The server does does come up with an answer for this query here:
Mar  2 16:02:31 localhost named[32277]: client 212.123.106.145#42697:
query: 145.106.123.212.in-addr.arpa IN PTR

But it doesn't respond with an answer to that one:
Mar  2 16:02:28 localhost named[32277]: client 212.123.106.145#42697:
query: 12.0.168.192.in-addr.arpa IN PTR

Triple-argh!

I just took to desparate measures and simply took a copy of the
zone-entry in named.conf.local from the working zone 212.123.106 and
just replaced the few digits in ist IP address, serial and the name of
the zone-file, then I copied the working zone-file from the former and
made the necessary adjustments for the broken reverse lookup zone -
that's just to eliminate any missing dots or superfluous spaces or
whatever bind might not like. The syslog shows no problems whatsoever on
restart, all the zone files are loaded fine with the approriate serials.
Nothing has changed - it's still resolving everything BUT the reverse
lookups for this one zone, which is the zone of his own external IP
(it's got 212.123.108.10 and I want reverse lookup for both this IP and
one of ist direct neighbours). So I gather that reverse lookup for
itself seems to be something special in this particular NAT-situation
(as internally it sees itself not as 212.123.106.10 but as
192.168.something) that has to be catered for in some place I haven't
thought of yet.

Kind regards

   Markus