We have a number of private zones on our site: a forward zone
private.cam.ac.uk, and a number of reverse zones under 172.16.0.0/12.
Should I configure these as stub zones, forward zones, or redirect zones?
At the moment private.cam.ac.uk is not signed but cam.ac.uk is. Does
DNSSEC validation affect how I should configure these zones? Do I need to
use the domain-indecure option?
Tony.
Hi Tony,
We have a number of private zones on our site: a forward zone
private.cam.ac.uk, and a number of reverse zones under 172.16.0.0/12.
Should I configure these as stub zones, forward zones, or redirect zones?
As stub zones. Possibly set
local-zone: "16.172.in-addr.arpa" nodefault
so that unbound does not provide default blocking for the zone.
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.
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.
At the moment private.cam.ac.uk is not signed but cam.ac.uk is. Does
DNSSEC validation affect how I should configure these zones? Do I need to
use the domain-indecure option?
Well, if private.cam.ac.uk does not exist in cam.ac.uk at all, Yes,
you need to use domain-insecure: "private.cam.ac.uk".
If cam.ac.uk has a delegation to private.cam.ac.uk then this turns
into a proper unsigned delegation and it works out of the box.
Best regards,
Wouter
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?
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?
I've been setting up some test zones to see what the differences in
behaviour are. No results yet, though.
Tony.
Tony Finch 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
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
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.
Thanks for the explanation.
Could you please add some text to the man page saying that unbound expects
the target of a forward zone to be a recursive server, and explain whether
or not it does recursive processing in both the stub and forward zone
sections. That would have given me enough clues.
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 was confused by the text "It can be used to redirect a domain to a
different address" which I thought meant "to redirect queries from unbound
about a domain" rather than it being a kind of wildcard. I'm not sure what
would be a better way to explain it...
> 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).
Thanks, that'll help me with testing. I also now realise I'll need another
back-end nameserver since the current one is authoritative for my test
zones.
Tony.
a message of 46 lines which said:
Thanks for the explanation.
Could you please add some text to the man page saying that unbound expects
the target of a forward zone to be a recursive server,
Note that it is in the comments of the default unbound.conf:
# Forward zones
# Create entries like below, to make all queries for 'example.com' and
# 'example.org' go to the given list of servers. These servers have to handle
# recursion to other nameservers.
Thanks for pointing that out. I would prefer it if I could find out
everything from the man pages - for example, I don't think the example
configuration is available except in the source tarball.
Tony.