Cannot reverse-resolve RFC1918 addresses

Unbound
1

Hi!

I am having some issues getting unbound to do reverse-resolution of
RFC1918 names, in this case 10.255.0.0/16 (255.10.in-addr.arpa.).

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

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

forward-zone:
  name: "."
  forward-addr: 78.31.10.86
  forward-addr: 78.31.10.93

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 @78.31.10.86 -x 10.255.1.17 +short
calc7.c.lon.spotify.net.

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

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

;; QUESTION SECTION:
;17.1.255.10.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
10.in-addr.arpa. 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
10.in-addr.arpa. 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
direction.

Best regards,
John Stäck
stack@spotify.com

2

Hello,

3

Unbound has built-in, empty, zones for 10.in-addr.arpa and other special, never-to-be-forwarded-to-internet, zones.

This is documented in the man page for unbound.conf - see the description of the "nodefault" option for "local-zone".

4

Hi John,

You are looking at the default local-zones.

from http://unbound.net/documentation/unbound.conf.html

The default zones are localhost, reverse 127.0.0.1 and ::1, and the
AS112 zones. The AS112 zones are reverse DNS zones for private use and
reserved IP addresses for which the servers on the internet cannot pro-vide
correct answers. They are configured by default to give nxdomain
(no reverse information) answers. The defaults can be turned off by
specifying your own local-zone of that name, or using the ‘nodefault’
type.

You need to remove the AS112 zone you need by adding a line to your config:

local-zone: “x.y.in-addr.arpa.” nodefault

Best regards,
Arni

Men & Mice

5

Zitat von John Stäck <stack@spotify.com>:

Hi!

I am having some issues getting unbound to do reverse-resolution of
RFC1918 names, in this case 10.255.0.0/16 (255.10.in-addr.arpa.).

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

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

forward-zone:
  name: "."
  forward-addr: 78.31.10.86
  forward-addr: 78.31.10.93

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 @78.31.10.86 -x 10.255.1.17 +short
calc7.c.lon.spotify.net.

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

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

;; QUESTION SECTION:
;17.1.255.10.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
10.in-addr.arpa. 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
10.in-addr.arpa. 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
direction.

Hello

the default is to not do queries for AS112 zones (reverse RFC1918):

  # a number of locally served zones can be configured.
  # local-zone: <zone> <type>
  # local-data: "<resource record string>"
  # o deny serves local data (if any), else, drops queries.
  # o refuse serves local data (if any), else, replies with error.
  # o static serves local data, else, nxdomain or nodata answer.
  # o transparent gives local data, but resolves normally for other names
  # o redirect serves the zone data for any subdomain in the zone.
  # o nodefault can be used to normally resolve AS112 zones.

6

Either of these does the trick, thanks!

(going with the "nodefault", just because it seems to make more sense)

Regards,
John Stäck
stack@spotify.com