[Unbound-users] Cannot reverse-resolve RFC1918 addresses

[Arni Birgisson]

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


On Feb 14, 2012, at 8:14 AM, John Stäck wrote:

> 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 at spotify.com
> 
> _______________________________________________
> Unbound-users mailing list
> Unbound-users at unbound.net
> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20120214/40bf87ae/attachment.htm>