$ cat /etc/unbound/unbound.conf
[...]
stub-zone:
name: "30.172.in-addr.arpa"
stub-addr: 172.30.20.243
stub-addr: 172.30.20.244
[...]
yet, I get back the built-in as112 content:
$ dig +short soa 30.172.in-addr.arpa
localhost. nobody.invalid. 1 3600 1200 604800 10800
I don't think the built-in content should arrive explicitly configured
stub zones?
I think you need to add
local-zone: "30.172.in-addr.arpa." nodefault
to the config in order to get normal resolution and hit the stub-zone, because you are defining a stub-zone instead of a local-zone to replace the built-in. However, nodefault doesn't appear to do anything. It looks to me like a typo in services/localzone.h - a patch like this helps
diff -ru unbound-1.0.0/services/localzone.h unbound-1.0.0-working/services/localzone.h
--- unbound-1.0.0/services/localzone.h 2007-11-22 13:48:58.000000000 +0000
+++ unbound-1.0.0-working/services/localzone.h 2008-05-28 22:44:26.000000000 +0100
@@ -66,7 +66,7 @@
local_zone_redirect,
/** remove default AS112 blocking contents for zone
* nodefault is used in config not during service. */
- local_zone_nodefault
+ local_zones_nodefault
};
/**
Alternatively adding this seems to work as well
local-zone: "30.172.in-addr.arpa." transparent
HTH
John
Hi John, Robert,
The fix below is not the correct fix, well the code part, John is right
about having to put a 'nodefault' config item to allow the blocked AS112
zone to be resolved normally. The real problem was that the trailing
'.' in the local-zone name field was used during comparisons, getting
the dot right (present or absent) would make it work.
I've fixed it in trunk r1106 so that it ignores the trailing dot during
comparisons. From there it'll be picked up in the next release.
Oh and by the way the final workaround (the transparent zone) worked
because that code already ignored the trailing dot for comparisons 
Thank you for the bug report,
~ Wouter
John Dickinson wrote: