Is it possible to serve stub-zones authoritatively? It makes sense
for unbound not to clear the authoritative flag for queries it
proxied to stub-zones, doesn't it?
Hi Martin,
Glad to hear your stub-zone problem is solved.
martin f krafft wrote:
Is it possible to serve stub-zones authoritatively? It makes sense
for unbound not to clear the authoritative flag for queries it
proxied to stub-zones, doesn't it?
No, it does not look like solid theory. I understand it could be useful
in practice. You see, the stub may have returned CNAMEs or delegations
to other servers. Unbound would do the additional lookups. Results
stored in the cache with a TTL. Setting AA flag for that is not correct.
Unbound does set AA flag for local-data.
Best regards,
Wouter
You don't proxy to stub-zones, though. All a stub-zone is is a non-standard location for particular zone. That is, "look here for zone A, instead of here".
What I think you are getting at is that it should be possible to have unbound and nsd running on a box, and have that box be a resolver for most things or most clients, but actually be authoritative for the stuff running on nsd. Or, to put it another way, run in a mode that is like what you can do with BIND.
To do this, unbound would have to act as a true proxy for the zone running in nsd. Even setting up a set of forward-zones isn't quite this, because unbound will still do recursion for you.
Of course, I could be projecting an earlier conversation I had with Wouter onto this one 
also sprach W.C.A. Wijngaards <wouter@NLnetLabs.nl> [2008.10.01.1652 +0200]:
No, it does not look like solid theory. I understand it could be
useful in practice. You see, the stub may have returned CNAMEs or
delegations to other servers. Unbound would do the additional
lookups. Results stored in the cache with a TTL. Setting AA flag
for that is not correct.
If any part of the answer is answered from cache or a forward- or
root-server, clear the bit, obviously. But if everything comes from
a stub-zone, there's no reason not to set AA, and there's even no
real reason to cache, is there? I would appreciate not having to
wait for min-TTL to expire to see changes made to my local zone...
also sprach David Blacka <davidb@verisign.com> [2008.10.01.1714 +0200]:
What I think you are getting at is that it should be possible to
have unbound and nsd running on a box, and have that box be
a resolver for most things or most clients, but actually be
authoritative for the stuff running on nsd. Or, to put it another
way, run in a mode that is like what you can do with BIND.
This is exactly what I want/need to do. 10 points!
David Blacka wrote:
What I think you are getting at is that it should be possible to have
unbound and nsd running on a box, and have that box be a resolver for
most things or most clients, but actually be authoritative for the
stuff running on nsd. Or, to put it another way, run in a mode that
is like what you can do with BIND.
Argh. This is a "too many buttons for people to push" problem. We're still seeing
combined auth/resolver servers because of bind, and it's bad in general. Let's
not try and repeat it using nsd+unbound hacks.
Run them on seperate machine's or IP's as indepdendant services. If you want
unbound to catch up on nsd reloads, script it so that unbound drops its cache.
Paul
OK, so what do I do if I don't have multiple machines or multiple IPs? I think you are suggesting that I can't use unbound.
I'll admit that the combined resolver/auth server isn't a good model, and, indeed, that is why unbound and nsd are strictly one thing or the other. However, there are people that will want to run in this combined mode, and some that, arguably, will need to. So, we either tell those folks to take a hike because they are "wrong", or we find a way to allow them to use unbound.
Using dnsproxy might be good enough. OTOH, it might also be nice to not force these people to run *three* separate packages in order to do what they want.
Run nsd on the public ip and unbound on 127.0.0.1 and point resolv.conf
to 127.0.0.1?
Paul
And thus only provide recursive service to that local box. I don't think that was the intent.
Then give the box two IP's. One for Auth and one for Recursive. Don't try to
merge those two different services into one, just because they happen to be
running on the same machine.
Paul
also sprach Paul Wouters <paul@xelerance.com> [2008.10.01.2052 +0200]:
Argh. This is a "too many buttons for people to push" problem.
We're still seeing combined auth/resolver servers because of bind,
and it's bad in general.
What's bad "in general" about running nsd and unbound on the same
machine? I know what's bad about BIND and the like, and it's not the
fact that it provides both services *on the same machine*, but that
*it provides both services*.
Running them both is fine. I was talking against some proposals where
magic happens between the two daemons for a 'seamless' integration of
modified auth zones.
Paul
also sprach Paul Wouters <paul@xelerance.com> [2008.10.01.2241 +0200]:
Then give the box two IP's. One for Auth and one for Recursive. Don't try to
merge those two different services into one, just because they happen to be
running on the same machine.
I am not. nsd runs on 127.0.0.1 and unbound on my LAN IP. That's two
separate IPs and a clear separation of the services, no?
Hello,
In my unbound.conf I have:
...
trust-anchor-file: "/usr/local/etc/unbound/ancoras/br.anchor"
trust-anchor-file: "/usr/local/etc/unbound/ancoras/dlv.isc.org.anchor"
...
But I saw in Chris Griffiths message:
...
trust-anchor-file: "/etc/unbound/anchors/br.anchor"
trust-anchor-file: "/etc/unbound/anchors/se.anchor"
trust-anchor-file: "/etc/unbound/anchors/bg.anchor"
trust-anchor-file: "/etc/unbound/anchors/pr.anchor"
trust-anchor-file: "/etc/unbound/anchors/cz.anchor"
...
My question is about how many trusted keys for validation must I use? And, if I manage about 200 domains, must I take care about them in my recursive servers, including its trusted keys? Are there security additional advantage to take care in anchor .br, .se, .bg and so on?
Thank you,
JB
Until the root is signed, and if you don't want to use DLV for those queries,
yes.
To make it easier, I wrote "dnssec-conf":
http://www.xelerance.com/software/dnssec-conf/
If you're on Fedora/RHEL/Centos, do:
yum install dnssec-conf
dnssec-configure -u --dnssec=on --dlv=on --production
You will find all the keys in /etc/pki/dnssec-keys/
See further: man dnssec-configure, man dnskey-pull
Paul
Note that as of unbound 1.2.x, you can use: trust-anchor-file: "/etc/unbound/anchors/*.anchor"
Paul