[Unbound-users] What's wrong with CNAMEs in local-data?

Michael Tokarev mjt at tls.msk.ru
Mon Oct 19 10:46:04 UTC 2009


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
>> Unbound-users at unbound.net
>> 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-----




More information about the Unbound-users mailing list