unbound fetches DNS record from nsd but does not return it to client

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Patrik,

On 03/08/15 18:50, Patrik Lundin wrote:
> On Mon, Aug 03, 2015 at 12:42:00PM +0200, W.C.A. Wijngaards via
> Unbound-users wrote:
>> 
>> 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.
>> 
> 
> Thank you for making the configuration information more explicit.
> I believe what I have been missing is a hint at the "nodefault"
> description that it only works for the exact zone names:
> 
> === nodefault Used to turn off default contents for AS112 zones.
> The other types also turn off default contents for the zone. The 
> 'nodefault' option has no other effect than turning off default
> contents for the given zone. ===
> 
> Reading this it is not clear to me that "nodefault" only works for
> the exact zones, and that I am supposed to use "transparent" if I
> configure 1.168.192.in-addr.arpa for example.

Added text to address that.  Thanks for pointing that out and the
'transparent' workaround for it.

> 
> Maby this is just me :).
> 
> Out of curiosity: what is the reason unbound does not work for the 
> original poster if domain-insecure is missing? The domain was 
> "data1.datanet.home", and since there is no DS record for "home" at
> ".", it seems to me this would mean no further DNSSEC processing is
> necessary. What am I missing?

There is an NXDOMAIN at "home." at ".".  DNSSEC does not allow data
under an NXDOMAIN.  If there would have been an insecure delegation
(NS records and no DS record), then it would have worked as you said.

Best regards,
   Wouter

> 
>> 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...
>> 
> 
> Sounds reasonable, thanks for the information :).
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVwGZKAAoJEJ9vHC1+BF+NwCEP/RDua2yo7e4AmMIVwzDA0PRS
+dUbO8HJjAzrnOrTpMq3p6uM7mjO64YKa4QYV+JZhPdeYM9qFSXVoBzpcgDU+tvV
eNpEkt0poIrR1brRmVyVENYS4zUCeKkEd3KDLbrxgJ0da/L0ruZB2MkYVX5EB32O
Wv4u8IZ/K793YTWiLaK3CmUXSOeuSzgOlH7H9rk5SKNKMthHVy+u3KtEHF0iUJcy
ycbaJkiyRQre8DcgDdPhxxAn009vPs5HRmwSXnP1KvqhDEjSgCXTi2o6Y2nmkjA4
gS1oDONbbcr7AuHvmJN1/vRqAIssmy/7yhJnNziYq838TAsV9fF2bpgnjM1+gYUm
xoXL0d//y25gzl7ngFmReN9YtbOnOfy50aVy2/92JZrnPel63flXyaficTfR1/nS
98SSVBEwLxrF1LmO30dtoCFTcfdVWg7trcmVFcVnqpwY8bFteqTkAfmgi0yjNzKV
OBfC4LOYBtHfBE91quGDoO3c3kxxpmlkkqUsx01fJFBez4AFFoxzOAigpw1BL6Op
rZZThUqk8Kv1eu2fjdRIdJ2e2G2jF2CYteFquZUBScUyzYDx2v8S+o0Od5OsbtZ5
qIXdfsNOdcVIYtPTnKOtgpIbNQmN+SsRbQtgJTt70fH61MJEdmbLZPA8ViMZ/kP1
yHtfdCBSazGZiC8dWTeA
=Qg2t
-----END PGP SIGNATURE-----