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 > [email protected] > > _______________________________________________ > Unbound-users mailing list > [email protected] > http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
_______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
