[Unbound-users] owerwritting implicit AS112 zones

[Michael Tokarev]

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