-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Patrik,
On 01/08/15 10:33, Patrik Lundin via Unbound-users wrote: > On Fri, Jul 31, 2015 at 10:36:34PM -0400, Sonic via Unbound-users > wrote: >> I doubt that local-zone: "1.168.192.in-addr.arpa" nodefault is >> necessary since you're defining it as a stub-zone. >> > > This is actually necessary. I just tested on my firewall at home, > and if I remove "local-zone: "168.192.in-addr.arpa." nodefault" I > will get the unbound default NXDOMAIN even if I still have my > stub-zone declaration: === stub-zone: name: > "1.168.192.in-addr.arpa" stub-addr: 127.0.0.1 === > > However, the configuration is still wrong since "nodefault" only > works on the specific RFC1918 boundaries, and not anything below. > If I change this: --- local-zone: "168.192.in-addr.arpa." > nodefault --- ... to this: --- local-zone: > "1.168.192.in-addr.arpa." nodefault --- > > I again get the unbound default NXDOMAIN even if it looks like it > matches what I want better. As you have pointed out to me on > openbsd-misc in the past, the correct configuration to use in the > latter case is this: --- local-zone: "1.168.192.in-addr.arpa." > transparent --- > > This is only mentioned in passing in the man page for unbound.conf > and I had missed it completely before you pointed it out to me > here: http://marc.info/?l=openbsd-misc&m=140647222022445&w=2 This > is probably my biggest pet peeve in the unbound configuration :). > > This of course does not relate to the main question in the thread, > but I am pretty sure reverse lookups does not currently work either > for the above reasons. I've fixed up the manual page and the example config file, and they now discuss configuring domain-insecure or local-zone nodefault for locally served zones. The configuration is like this because the access-control filter happens first (it is by IP address netblock). Then the local-zone filter is applied (it is by domain name). Then the DNS cache is used, the items are fed in there with the stub-zone clause. The cache entries are also 'filtered' by DNSSEC validation and private-address removal. And all of these components are separately configurable... Best regards, Wouter > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVv0V4AAoJEJ9vHC1+BF+NhK4QAIRsxbf70lUH9fpqoLjHbZRo i4aGw0FqkWSUFtZWq/rrNETF9ERFhfOq/T1PSRQ2hXe218x91lsKyLSl6rc1q61Z kykI21+6BMBv+mhkuiJfZ2iG6yt/Y4fya727hI/FESIdj4Nayz/IPKo39MaIw02v VZbuC24uU5A1JZG4TFgO2gRi+drOTskmsF9RI5H/syAnRmZ0xGfgKIMthkbuX/ib j5AhSoivX6Eo5Vcu5krPCY+UJrjj7oEU4IOnHQzp8DV/pdbnREyRAUrKGrTLQuIl GPEnQbYlOx+0FeYgBsoAfB8mpfM4XVjgiLv0cD89qgB9dESTuPzVVuz7PAk7tWi9 iUCvli/E7Bh74remRgpL/NhdOZjLbvU2QK1U5m/9FkNWI8LTHJqV38VhpPCTkdq4 0a4+t8Qi5iBtIj8JHQ/mCM2WjnOCw+WeOAJHixnqn9+zzw7w259Yvr7QZYAq50pR HwLEIAaaN/6PcCzpoU5h0Ytk8Xy+PzM77AtpwPNFwOtwTg3KBSdBbAxB59oXa/DV D6Hx9z5Ft3OEWb5eZRNSrov8DD9CUxUKaFbEYafQVf/yJ7p0Gw43NVMAelBFr8FH P9HxQ2xw0SGsHVDfaqnu3tnFQBpjSsJoNNi3iCq5RguGMCIIhtYvO/DhHZC2rM7G W/DPOzUQEsJNf4xyikrc =mxSO -----END PGP SIGNATURE-----
