BIND9 behind NAT: no reverse lookup from external net

[Ronan Flood]

"Markus Wollny" <Markus.Wollny at computec.de> wrote:

> 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.Flood at 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)