Failure to create a stub-zone for AS112 zone

Unbound
1

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@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@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).

2

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.

3

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

4

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.

If I understand correctly, I should not use private-address as they will
remove any occurence of IP addresses fom my local network; also, it
seems that private-domain only apply to forward zones as reverse zones
do not return IP address, isnt'it?

I tried both (independently) and it didn't work unfortunately.

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

Ok, indeed that works. Is it the expected behaviour, and if yes what is
the rationale of this? I think we should be able to divide further
RFC1918 reverse zones for convenience, unless there is a strong reason I
don't understand to not do that; I mean I have the impression that
unbound somewhat enforces the pre-CIDR behavior of these private
networks.

Cheers,