Owerwritting implicit AS112 zones

Unbound
1

Hello.
A first-post-user here.

Just noticed a problem here which is related to built-in zones
for private network space such as 192.168.*.

Here's the config example I have:

  forward-zone:
   name: "1.168.192.in-addr.arpa"
   forward-addr: 192.168.1.1

The intention is to forward all requests for 192.168.1.* to the
nameserver in question. But it does not quite work:

$ dnsget -v 192.168.1.1
;; trying 1.1.168.192.in-addr.arpa.
;; sending 53 bytes query to 127.0.0.1 port 53

;; received 112 bytes response from 127.0.0.1 port 53
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43632, size: 112
;; flags: qr rd ra aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; QUERY SECTION (1):
;1.1.168.192.in-addr.arpa. IN PTR

;; AUTHORITY section (1):
168.192.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800

;; ADDITIONAL section (1):
;EDNS0 OPT record (UDPsize: 4096): 0 bytes

dnsget: unable to lookup PTR record for 1.1.168.192.in-addr.arpa: domain name does not exist

As you see, unbound returns built-in SOA record and no data.
On the other hand, 192.168.1.1 responds just fine:

$ dnsget -v 192.168.1.1 -n 192.168.1.1
;; trying 1.1.168.192.in-addr.arpa.
;; sending 53 bytes query to 192.168.1.1 port 53

;; received 231 bytes response from 192.168.1.1 port 53
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3969, size: 231
;; flags: qr rd ra aa; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5

;; QUERY SECTION (1):
;1.1.168.192.in-addr.arpa. IN PTR

;; ANSWER section (1):
1.1.168.192.in-addr.arpa. 172800 IN PTR paltus.tls.msk.ru.

;; AUTHORITY section (3):
168.192.in-addr.arpa. 172800 IN NS tsrv.tls.msk.ru.
168.192.in-addr.arpa. 172800 IN NS paltus.tls.msk.ru.
168.192.in-addr.arpa. 172800 IN NS vampire.tls.msk.ru.

;; ADDITIONAL section (4):
tsrv.tls.msk.ru. 86400 IN A 192.168.1.2
paltus.tls.msk.ru. 86400 IN A 192.168.1.1
vampire.tls.msk.ru. 86400 IN A 192.168.1.8
;EDNS0 OPT record (UDPsize: 4096): 0 bytes

It's even more, when adding local-data SOA for any of the built-in
zones, that data is APPENDED to the built-in RRset:

;; AUTHORITY section (2):
168.192.in-addr.arpa. 3600 IN SOA foo. foo.bar. 1 3600 1200 604800 10800
168.192.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800

Double RRset is not really a problem, but forward-zone (or stub-zone,
which behaves exactly the same from this point of view) is wrong.
In my example, built-in zone is 168.192.in-addr.arpa, and I specify
a sub-zone of it (1.168.192), which should take precedence instead
of being ignored entirely.

Comments?

Thanks!

/mjt

2

And a quick follow-up...

Michael Tokarev wrote:

[]forward-zone (or stub-zone,
which behaves exactly the same from this point of view) is wrong.
In my example, built-in zone is 168.192.in-addr.arpa, and I specify
a sub-zone of it (1.168.192), which should take precedence instead
of being ignored entirely.

I discovered how to do it.
By adding

   local-zone: "1.168.192.in-addr.arpa" transparent

in addition to the forward zone declaration of the
same name, unbound actually starts forwarding requests
as it should. I think that 'local-zone' line should
be added implicitly here when forward-zone or
stub-zone is configured, and no specific local-zone
of the same name is given.

3

a message of 31 lines which said:

I discovered how to do it.
By adding

  local-zone: "1.168.192.in-addr.arpa" transparent

The documentation says to use "nodefault". Here is how I do it and it
seems to work:

server:
# Do not forget to put local-zone in the "server:" section or you'll get
# undecipherable error messages!
        ...
        # Suppress the default:
        local-zone: 10.in-addr.arpa. nodefault

forward-zone:
     name: "0.10.in-addr.arpa"
     forward-addr: 192.134.4.162
     forward-addr: 192.134.4.163
forward-zone:
     name: "1.10.in-addr.arpa"
     forward-addr: 192.134.4.162
     forward-addr: 192.134.4.163
...