Maintained by: NLnet Labs

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

Leen Besselink
Sun Mar 10 20:10:22 CET 2013


On Sun, Mar 10, 2013 at 02:15:10PM +0100, Jeremie Le Hen wrote:
> 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:
> 

Hi,

Maybe I'm mistaken, but I believe you might also need 1 of these ?:

     private-address: <IP address or subnet>
              Give IPv4 of IPv6 addresses  or  classless  subnets.  These  are
              addresses  on  your  private  network, and are not allowed to be
              returned for public  internet  names.   Any  occurence  of  such
              addresses are removed from DNS answers. Additionally, the DNSSEC
              validator may mark the  answers  bogus.  This  protects  against
              so-called  DNS  Rebinding, where a user browser is turned into a
              network proxy, allowing remote access  through  the  browser  to
              other  parts of your private network.  Some names can be allowed
              to contain your private addresses, by default all the local-data
              that  you  configured  is  allowed to, and you can specify addi-
              tional names using private-domain.   No  private  addresses  are
              enabled  by default.  We consider to enable this for the RFC1918
              private IP address space by  default  in  later  releases.  That
              would  enable  private  addresses  for  10.0.0.0/8 172.16.0.0/12
              192.168.0.0/16 169.254.0.0/16 fd00::/8 and fe80::/10, since  the
              RFC  standards  say these addresses should not be visible on the
              public internet.  Turning on 127.0.0.0/8 would hinder many spam-
              blocklists as they use that.

       private-domain: <domain name>
              Allow  this  domain,  and  all its subdomains to contain private
              addresses.  Give multiple times to allow multiple  domain  names
              to contain private addresses. Default is none.

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

Hope that helps.

Have a nice day,
	Leen.

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