Matthijs Mekking wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Michael,
Cached data is gathered querying authoritative servers, local data is
not.
Sure, it's exactly what I wrote.
Unbound is a recursive resolver, not an authoritative one.
Sure.
Thus, it
can resolve CNAMEs, but it is not intended to publish CNAMEs.
Sure thing it is not intended to publish anything, being
recursive non-auth resolver.
The
authoritative features are minimal with a purpose.
Authoritative features are minimal. But this still does not
answer my question - _why_ unbound can't resolve local-data
CNAMEs and why it _treats_ them differently than cached data
(I didn't ask where the data comes from in each case which is
obvious).
If you need authoritative local data with CNAME (and DNAME, referrals,
wildcards, ...) processing, I advise to set up a stub zone.
I know how it's done in unbound. I've a bunch of servers here and there
running unbound and nsd in parallel, a huge mix of them.
But I want to reduce this huge mix/mess somewhat. The _only_ thing
why I run _both_ unbound and nsd at some places, and can't switch
from named at other places, is because I need a few (2 or 3) "remote"
CNAMEs in local data. Like a small remote office without constant
connectivity, which needs to be able to resolve 5..10 local names,
sometimes be able to resolve external names recursively and sometimes
has 2..3 local CNAMEs pointing to external resources.
Note also:...
Michael Tokarev wrote:
Out of curiocity.
... this. I'm asking for a _reason_ why it's done this way.
And later on, mentioned possible implementation details that
gives more curiocity ;)
I'll try to dig into sources.
Thanks.
Why unbound can't resolve CNAMEs in local-data
as it does with other CNAMEs? What is different
between local-data and cached data?
If I were to implement that stuff, I'd, probably,
use the same cache for both "kinds" of RRs, but
for local-data stuff I'd mark them as "permanent".
When constructing answer, take CNAME as if it
were cached normally, and resolve the target name
the usual way.
I don't know how it's implemented in unbound. Why
the restriction and/or different treatment to start
with?
Thanks!
/mjt
_______________________________________________
Unbound-users mailing list
[email protected]
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEcBAEBAgAGBQJK3EE4AAoJEA8yVCPsQCW5dUwIAIeEbxYWB5KnVWcGrQys8Yqo
SZ8EETs2Xw8UBSf+uFIagw9YCa0EvQQVi8FJJ7v3eFdonCEhqBrJWuSqUgjqAuox
RxuJY4cuIhm5s82wf44nXCRX+wUVOhznIyhwWo61soCXSYAg9HNUVuV7B8ozm6Jq
fs90YXUtegSvilxS7lIKi0jmF73v1+JMaM16ODcaNiu6ooZUVWJ4H1ysOmHH0+cz
0kh9NcSYaksVrNh/AtNp4FNAK63spt+8Rc9W0S0NU0qSweUK3NEJALJHmta9u/dw
c3G+fG+KCWv+AR8guI0VWu2EhSczAea9IxMmCvh/41wMSBB8NGIvvsBo9VquPLE=
=NBzl
-----END PGP SIGNATURE-----
_______________________________________________
Unbound-users mailing list
[email protected]
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
