BIND9 behind NAT: no reverse lookup from external net
Markus Wollny
We have recently migrated an old BIND8 that was running on a SuSE Linux
7.1 box to BIND9 running on Debian Sarge. I have added the necessary
$TTL and $ORIGIN lines which weren't needed in BIND9 and have got it up
and running. The box is behind a NAT-firewall, so it's got an IP in the
192.168.0.x range and a static NAT mapping to an external IP. It's doing
ordinary domain name resolution fine for both internal and external
clients; however when trying a reverse lookup using its external IP
address, the server doesn't provide an answer.
These are two queries from the outside internet:
extbox:~# dig @ns1.computec.de dozer.computec.de
; <<>> DiG 9.2.4 <<>> @ns1.computec.de dozer.computec.de
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42687
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;dozer.computec.de. IN A
;; ANSWER SECTION:
dozer.computec.de. 86400 IN A 212.123.108.12
;; AUTHORITY SECTION:
computec.de. 86400 IN NS ns1.sec-dns.de.
computec.de. 86400 IN NS ns1.computec.de.
;; ADDITIONAL SECTION:
ns1.sec-dns.de. 80742 IN A 212.123.100.100
ns1.computec.de. 86400 IN A 212.123.108.10
;; Query time: 4 msec
;; SERVER: 212.123.108.10#53(ns1.computec.de)
;; WHEN: Tue Mar 1 14:02:46 2005
;; MSG SIZE rcvd: 127
So that's working alright; but when I try the reverse lookup:
extbox:~# dig @ns1.computec.de -x 212.123.108.12
; <<>> DiG 9.2.4 <<>> @ns1.computec.de -x 212.123.108.12
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7927
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
I don't get an answer. When digging from the internal network while
using the external IP of the nameserver (or its name, which resolves to
the external IP), the result is the same. When I query the server with
its internal IP, the reverse lookup is working fine:
intbox:~# dig @192.168.0.10 -x 212.123.108.12
; <<>> DiG 9.2.4 <<>> @192.168.0.10 -x 212.123.108.12
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22154
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;12.108.123.212.in-addr.arpa. IN PTR
;; ANSWER SECTION:
12.108.123.212.in-addr.arpa. 86400 IN PTR dozer.computec.de.
;; AUTHORITY SECTION:
108.123.212.in-addr.arpa. 86400 IN NS ns1.computec.de.
108.123.212.in-addr.arpa. 86400 IN NS ns1.sec-dns.de.
;; ADDITIONAL SECTION:
ns1.sec-dns.de. 80448 IN A 212.123.100.100
ns1.computec.de. 86400 IN A 212.123.108.10
;; Query time: 1 msec
;; SERVER: 192.168.0.10#53(192.168.0.10)
;; WHEN: Tue Mar 1 14:07:40 2005
;; MSG SIZE rcvd: 152
The same applies for queries executed locally on the server - it works
when I use localhost, 127.0.0.1 or the internal IP as server, but fails
when I use the servername or the external IP.
Here's the relevant bit from /etc/bind/named.conf.local:
zone "108.123.212.in-addr.arpa" in {
type master;
file "db.212.123.108"; =20
};
And this is the zone-file db.212.123.108:
$TTL 86400
@ 2H IN SOA ns1.computec.de. hostmaster (
2005030101 ; serial
1D ; refresh
1H ; retry
1W ; expiry
1D ) ; minimum
1D IN NS ns1.computec.de.
1D IN NS ns1.sec-dns.de.
12 1D IN PTR dozer.computec.de.
10 1D IN PTR ns1.computec.de.
Could you please give me a hint as to where I could start looking for
the problem? I am not the administrator of the NAT firewall, but as
ordinary nameresolution from the outside is working fine AND I cannot
get reverse lookup via external IP even on the local machine, I think it
might still be something in my machine's config - or does reverse lookup
require other firewall settings than ordinary name resolution? Port 53
TCP and UDP is open...
Kind regards
Markus
Ronan Flood
> We have recently migrated an old BIND8 that was running on a SuSE Linux
> 7.1 box to BIND9 running on Debian Sarge. I have added the necessary
> $TTL and $ORIGIN lines which weren't needed in BIND9 and have got it up
> and running. The box is behind a NAT-firewall, so it's got an IP in the
> 192.168.0.x range and a static NAT mapping to an external IP. It's doing
> ordinary domain name resolution fine for both internal and external
> clients; however when trying a reverse lookup using its external IP
> address, the server doesn't provide an answer.
> extbox:~# dig @ns1.computec.de -x 212.123.108.12
>
> ; <<>> DiG 9.2.4 <<>> @ns1.computec.de -x 212.123.108.12
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7927
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>
> I don't get an answer. When digging from the internal network while
> using the external IP of the nameserver (or its name, which resolves to
> the external IP), the result is the same. When I query the server with
> its internal IP, the reverse lookup is working fine:
> The same applies for queries executed locally on the server - it works
> when I use localhost, 127.0.0.1 or the internal IP as server, but fails
> when I use the servername or the external IP.
Are you using views in your named.conf?
> Could you please give me a hint as to where I could start looking for
> the problem? I am not the administrator of the NAT firewall, but as
> ordinary nameresolution from the outside is working fine AND I cannot
> get reverse lookup via external IP even on the local machine, I think it
> might still be something in my machine's config - or does reverse lookup
> require other firewall settings than ordinary name resolution?
I wouldn't have thought so, but perhaps.
> Port 53 TCP and UDP is open...
That's interesting, because if I try it over UDP, I get the same as you,
dig @ns1.computec.de -x 212.123.108.12 +norec
; <<>> DiG 9.2.3 <<>> @ns1.computec.de -x 212.123.108.12 +norec
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 57683
;; flags: qr aa ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;12.108.123.212.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
123.212.in-addr.arpa. 86400 IN SOA localhost. root. 1 604800 86400 2419200 86400
(claims not even to have the zone!?)
but over TCP I get the answer
dig @ns1.computec.de -x 212.123.108.12 +norec +vc
; <<>> DiG 9.2.3 <<>> @ns1.computec.de -x 212.123.108.12 +norec +vc
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46275
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;12.108.123.212.in-addr.arpa. IN PTR
;; ANSWER SECTION:
12.108.123.212.in-addr.arpa. 86400 IN PTR dozer.computec.de.
;; AUTHORITY SECTION:
108.123.212.in-addr.arpa. 86400 IN NS ns1.sec-dns.de.
108.123.212.in-addr.arpa. 86400 IN NS ns1.computec.de.
;; ADDITIONAL SECTION:
ns1.sec-dns.de. 80862 IN A 212.123.100.100
ns1.computec.de. 86400 IN A 212.123.108.10
Also I get different results over UDP for a PTR query and an ANY query
dig @ns1.computec.de 12.108.123.212.in-addr.arpa. ptr +norec
; <<>> DiG 9.2.3 <<>> @ns1.computec.de 12.108.123.212.in-addr.arpa. ptr +norec
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62018
;; flags: qr aa ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
(... as for dig -x ...)
but dig @ns1.computec.de 12.108.123.212.in-addr.arpa. any +norec
; <<>> DiG 9.2.3 <<>> @ns1.computec.de 12.108.123.212.in-addr.arpa. any +norec
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30559
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;12.108.123.212.in-addr.arpa. IN ANY
;; ANSWER SECTION:
12.108.123.212.in-addr.arpa. 86400 IN PTR dozer.computec.de.
Not sure where that gets you ...
--
Ronan Flood <R.F...@noc.ulcc.ac.uk>
working for but not speaking for
Network Services, University of London Computer Centre
(which means: don't bother ULCC if I've said something you don't like)
Markus Wollny
=20
> Are you using views in your named.conf?
No. Not a single one.
> > Port 53 TCP and UDP is open...
>=20
> That's interesting, because if I try it over UDP, I get the=20
> same as you,
> but over TCP I get the answer
>=20
> dig @ns1.computec.de -x 212.123.108.12 +norec +vc
>=20
> ; <<>> DiG 9.2.3 <<>> @ns1.computec.de -x 212.123.108.12=20
> +norec +vc ;; global options: printcmd ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46275 ;;=20
> flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
>=20
> ;; QUESTION SECTION:
> ;12.108.123.212.in-addr.arpa. IN PTR
>=20
> ;; ANSWER SECTION:
> 12.108.123.212.in-addr.arpa. 86400 IN PTR dozer.computec.de.
>=20
> ;; AUTHORITY SECTION:
> 108.123.212.in-addr.arpa. 86400 IN NS ns1.sec-dns.de.
> 108.123.212.in-addr.arpa. 86400 IN NS ns1.computec.de.
>=20
> ;; ADDITIONAL SECTION:
> ns1.sec-dns.de. 80862 IN A 212.123.100.100
> ns1.computec.de. 86400 IN A 212.123.108.10
I think it might be a delegation problem on behalf of our provider (it's
sometimes a quite tedious task to actually get some answer from them,
let alone problems solved...). I've got another reverse lookup zone on
that machine and this one is working fine. I suspect that if you send a
query over TCP, the server does answer without bothering about
delegation, but when doing it the standard UDP-way, it doesn't provide
the answer if there's no delegation for that zone.
Kind regards
Markus
Ronan Flood
> I think it might be a delegation problem on behalf of our provider (it's
The delegation (from 212.in-addr.arpa) looks OK:
dig @ns-pri.ripe.net. 108.123.212.in-addr.arpa. ns +norec
;; AUTHORITY SECTION:
108.123.212.in-addr.arpa. 172800 IN NS ns1.computec.de.
108.123.212.in-addr.arpa. 172800 IN NS ns1.sec-dns.de.
> sometimes a quite tedious task to actually get some answer from them,
> let alone problems solved...). I've got another reverse lookup zone on
> that machine and this one is working fine. I suspect that if you send a
> query over TCP, the server does answer without bothering about
> delegation, but when doing it the standard UDP-way, it doesn't provide
> the answer if there's no delegation for that zone.
I doubt that. I would consult your firewall admin to see if there's
any config on it to intercept PTR queries. Also you could turn on
query-logging on your nameserver to see if it actually gets the PTR
queries for this zone.
Markus Wollny
> "Markus Wollny" <Markus...@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
Ronan Flood
> 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
But look at the query: 12.0.168.192.in-addr.arpa, when I guess you
asked for "dig -x 212.123.108.12". That suggests that the NAT firewall
is translating the address within the query.
> 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.
The firewall ...
Markus Wollny
> guess you asked for "dig -x 212.123.108.12". That suggests=20
> that the NAT firewall is translating the address within the query.
Thanks for noticing this one - I didn't :)
I already tried to solve the thing with a reverse lookup zone for
192.168.0, but that didn't do the trick either, so I guess I'll hand
this over to the admin of that NAT firewall. Thanks a lot for your help!
Kind regards
Markus