[Unbound-users] failure to create a stub-zone for AS112 zone

[Jeremie Le Hen]

Hi,

Can you please Cc: me when replying, as I've not subscribed.

I've been pulling my hairs out of my head for two days to create what
looks like a very simple configuration:

I'm using unbound-1.4.17 on OpenBSD 5.2.  nsd is listening on 127.0.0.2
and replies correctly to both forward and reverse zones when I query it
directly.

Here is the unbound config:

    server:
	    verbosity: 2
	    interface: 127.0.0.1
	    interface: 192.168.1.14
	    access-control: 0.0.0.0/0 refuse
	    access-control: 127.0.0.0/8 allow
	    access-control: 192.168.1.0/24 allow
	    do-not-query-localhost: no
	    local-zone: "1.168.192.in-addr.arpa." nodefault
    python:
    remote-control:
    stub-zone:
	    name: "home.local."
	    stub-addr: 127.0.0.2
    stub-zone:
	    name: "1.168.192.in-addr.arpa."
	    stub-addr: 127.0.0.2


The forward zone works correctly, but unbound keeps returning NXDOMAIN
for the reverse zone.

    jlh at leaf:~$ host obiwan 192.168.1.14
    Using domain server:
    Name: 192.168.1.14
    Address: 192.168.1.14#53
    Aliases: 
    
    obiwan.home.local has address 192.168.1.3
    jlh at leaf:~$ host 192.168.1.3 192.168.1.14
    Using domain server:
    Name: 192.168.1.14
    Address: 192.168.1.14#53
    Aliases: 
    
    Host 3.1.168.192.in-addr.arpa. not found: 3(NXDOMAIN)


What is the most frustrating is that even with the highest verbosity
unbound prints absolutely no debug message when receiving or replying
to the request in the reverse zone.  (I guess the NXDOMAIN response is
served from the cache, because a cache query in the forward one doesn't
show any log as well.)

I've checked traffic on loopback with tcpdump(8), we can indeed see some
traffic for the forward zone query, but nothing for the reverse zone
one.

Next step for me is to start adding debugging statements to the code,
but I would prefer not doing this as it may be pretty time consuming.
Any idea why this happens?

Note: I've tried to add a "local-data:" statement to unbound.conf; in
that case unbound replies correctly.  So I know I can work around my
problem using this; I just want to understand why it doesn't work as I
expect.


Here is the verbose log:

[1362921133] unbound[7485:0] notice: Start of unbound 1.4.17.
[1362921133] unbound[7485:0] warning: increased limit(open files) from 128 to 4152
[1362921133] unbound[7485:0] debug: creating udp4 socket 127.0.0.1 53
[1362921133] unbound[7485:0] debug: creating tcp4 socket 127.0.0.1 53
[1362921133] unbound[7485:0] debug: creating udp4 socket 192.168.1.14 53
[1362921133] unbound[7485:0] debug: creating tcp4 socket 192.168.1.14 53
[1362921133] unbound[7485:0] debug: chdir to /var/unbound
[1362921133] unbound[7485:0] debug: chroot to /var/unbound
[1362921133] unbound[7485:0] debug: chdir to /etc
[1362921133] unbound[7485:0] debug: drop user privileges, run as _unbound
[1362921133] unbound[7485:0] debug: switching log to stderr
[1362921133] unbound[7485:0] debug: module config: "validator iterator"
[1362921133] unbound[7485:0] notice: init module 0: validator
[1362921133] unbound[7485:0] debug: validator nsec3cfg keysz 1024 mxiter 150
[1362921133] unbound[7485:0] debug: validator nsec3cfg keysz 2048 mxiter 500
[1362921133] unbound[7485:0] debug: validator nsec3cfg keysz 4096 mxiter 2500
[1362921133] unbound[7485:0] notice: init module 1: iterator
[1362921133] unbound[7485:0] debug: target fetch policy for level 0 is 3
[1362921133] unbound[7485:0] debug: target fetch policy for level 1 is 2
[1362921133] unbound[7485:0] debug: target fetch policy for level 2 is 1
[1362921133] unbound[7485:0] debug: target fetch policy for level 3 is 0
[1362921133] unbound[7485:0] debug: target fetch policy for level 4 is 0
[1362921133] unbound[7485:0] debug: total of 59601 outgoing ports available
[1362921133] unbound[7485:0] debug: start threads
[1362921133] unbound[7485:0] debug: libevent 1.4.14b-stable uses kqueue method.
[1362921133] unbound[7485:0] info: DelegationPoint<1.168.192.in-addr.arpa.>: 0 names (0 missing), 1 addrs (0 result, 1 avail) parentNS
[1362921133] unbound[7485:0] debug:    ip4 127.0.0.2 port 53 (len 16)
[1362921133] unbound[7485:0] info: DelegationPoint<home.local.>: 0 names (0 missing), 1 addrs (0 result, 1 avail) parentNS
[1362921133] unbound[7485:0] debug:    ip4 127.0.0.2 port 53 (len 16)
[1362921133] unbound[7485:0] debug: no config, using builtin root hints.
[1362921133] unbound[7485:0] debug: cache memory msg=33040 rrset=33040 infra=1304 val=33156
[1362921133] unbound[7485:0] info: start of service (unbound 1.4.17).


-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.