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

Mon Mar 11 08:05:41 UTC 2013

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Change this line, I think,
 	    local-zone: "1.168.192.in-addr.arpa." nodefault
into this
 	    local-zone: "168.192.in-addr.arpa." nodefault

Best regards,
   Wouter


On 03/10/2013 08:10 PM, Leen Besselink wrote:
> 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
> _______________________________________________ Unbound-users
> mailing list Unbound-users at unbound.net 
> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRPZBQAAoJEJ9vHC1+BF+Nh4MP/1QmYo4wtvP141aGGAUIsywx
rVoH03ac+FZCMQ3A320ejVX1V/fa/RbgaRcWHOVOkcNBQe6x+RhDD1SykXBu+c+M
oOoGfmIOIU/eeIFxEaZzK9oFRB8Qu61mIoyyVgfHJvRncql/xpxP6/livwUQFCM2
j2xeLnijMf/uJnb7kLbDyjfioRjbQan/NejlHYDMbtYPDUiv/qJpBbB2pNfABnJ0
fJ7PfcvUquUFXss8eI5OYfbD9zOHPgCOMbqaAqVhPK1+advRvHPmsaB972hi1BeM
NISGYu5MQf8+3vZEAYpPzObipH75vKf7WMP7S+XLJ7EsGqVb0YIo3+aAXBc06vcQ
Lj++vZgszN/V7B88oA1+YQmtX9yFzt85VLLR+jbFl5l6wf/ic3CfnhhVAA8XIIxq
9ajsvyprhk7UPcdCzq4e7x6uVQsina2/R7R9V9a3hNeaPZXRFwisk/tFYx2Nphaz
HvzZfLCDk3tfmdZLTjmNzH0pnwzr+WWez/1CyB1kP/m1/D0p/i98Ugnm69UAKYDL
jThwcdZtvr6zeNBqHqUbKvAXLeCpoW0IPRaYA2QNOkEO4+v6NcBUO1Sfo7TxEPrE
npCkkBGT+4n9mdO2uXFq5rL812ZC2H6cEuvzukQg1l6RzrVtzizMmdIyaQzgpqiM
66uvEyGFwQ/5DVicqihX
=H2GA
-----END PGP SIGNATURE-----