[Unbound-users] Cannot reverse-resolve RFC1918 addresses

[lst_hoe02 at kwsoft.de]

Zitat von John Stäck <stack at 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.
	#
	# defaults are localhost address, reverse for 127.0.0.1 and ::1
	# and nxdomain for AS112 zones. If you configure one of these zones
	# the default content is omitted, or you can omit it with 'nodefault'.

So if you need reverse lookup for RF1918 address space you have to  
configure something like

local-zone: "255.10.in-addr.arpa" nodefault

and if you use DNSSEC maybe also

domain-insecure: "10.in-addr.arpa"
domain-insecure: "your.internal.domain"

Regards

Andreas