BIND9 behind NAT: no reverse lookup from external net
Ronan Flood
ronan at noc.ulcc.ac.uk
Tue Mar 1 16:19:59 UTC 2005
"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)
More information about the bind-users
mailing list