[Unbound-users] stub vs. forward vs. redirect

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/17/2009 12:55 PM, Tony Finch wrote:
> On Thu, 17 Sep 2009, W.C.A. Wijngaards wrote:
>>
>> As stub zones.  Possibly set
>> local-zone: "16.172.in-addr.arpa" nodefault
>> so that unbound does not provide default blocking for the zone.
> 
> Thanks for the tip.
> 
>> If you made them forward-zones, it would likely work as well, but if
>> there are CNAMEs then you probably want unbound to process the cname
>> chain chasing, as the other server is authoritative for these zones.
> 
> Do I have to put something in the configuration file to make that happen?

stub-zone:
	name: "16.172.in-addr.arpa"
	stub-addr: 172.16.0.1
Something like that.

>> A redirect would work if you want to block access to those zones, and
>> return an answer to some 'redirect notify' page in all cases.
> 
> Hmm. I still have very little idea about what redirect is supposed to do,
> and what is the difference between forward and stub zones. I have similar
> problems with bind :-) Is there some documentation that I have failed to
> find?

http://unbound.net/documentation/unbound.conf.html (manual page)

stub: send query to other nameserver. The other nameserver is
authoritative, so you have to perform recursive processing yourself.
forward: send query to other nameserver.  The other nameserver is a
recursive (caching) server.  So it performs recursion for you.
redirect: answer all queries for this domain with a specific ip address,
useful for (government enforced) blocking of sites, or making
facebook.com go to 127.0.0.1 to keep the kids away from it, since it
also blocks blabla.facebook.com and so on.

> I've been setting up some test zones to see what the differences in
> behaviour are. No results yet, though.

You could see if you host a CNAME record, that points outside of the
zone,  test12.private.example. CNAME www.google.com. ; with a stub-zone
unbound looks up google for you.  With a forward declaration unbound
expects the other server to do so (but it may not do so, if it is a
master zone and authoritative, not a recursive server).

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkqyITAACgkQkDLqNwOhpPif2ACfVQ6AQvn/gLcQ7s3XRlvCgMFc
kcQAnAvKhYRHBrZgXAtrKOHT/x9ed8Mi
=5rl2
-----END PGP SIGNATURE-----