Maintained by: NLnet Labs

[Unbound-users] Cannot reverse-resolve RFC1918 addresses

John Stäck
Tue Feb 14 09:14:38 CET 2012


I am having some issues getting unbound to do reverse-resolution of
RFC1918 names, in this case (

We got unbound set up as basically a local resolver cache, the config
looks like this:

  prefetch: yes
  num-threads: 1
  incoming-num-tcp: 256
  outgoing-num-tcp: 256
  statistics-interval: 60

  name: "."

The two forward-addr IP:s are our upstream recursive resolvers (which
are set up to properly answer the RFC1918 stuff we need). When I ask
them, I get a perfectly normal answer:

$ dig @ -x +short

But when I ask the unbound server, I get NXDOMAIN and a strange SOA:
$ dig @ -x

; <<>> DiG 9.7.3 <<>> @ -x
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1244
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0


;; AUTHORITY SECTION:	10800	IN	SOA	localhost. nobody.invalid. 1 3600 1200
604800 10800

(removed some useless extra info for brevity)

Unbound is not doing any forwarded upstream requests for the failed
query (according to packet traces), and one rather odd thing is that I
get nothing whatsoever in the log for it (no matter what verbosity). I
get the exact same answer for any RFC1918 address, while all other
queries (regular or reverse) resolve normally and show up in the log.
A-record lookups that return 10.X addresses work just fine, it is only
PTR records that do not.

I have been messing around with some other settings, such as various
combinations of private-address / private-domain, and setting as a separate forward or stub zone. In no case do I
see anything for those queries in the logs.

None of it works. The only way I get any answer back (except NXDOMAIN)
is if I specify data with local-data or local-data-ptr, but those
queries are not logged either.

Tested on unbound 1.4.16 on Ubuntu 11.10, as well as 1.4.14-2~bpo60+1
on debian squeeze with the same result.

Have I set things up incorrectly (especially with the
private-address/-domain)? From what I understand, not having these
statements should mean they are treated normally and not filtered out,
but it doesn't seem to make any difference to this issue. What should
I do to get this going? Thankful for any pointers in the right

Best regards,
John Stäck
stack at