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 _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
