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

[W.C.A. Wijngaards]

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

Hi Michael,

So a different lookup structure is used for local data,
compared to cached data.  The structure is more optimal for
authority lookups (copied mainly from NSD).

This structure is checked before the cache is checked.
This means that authority service is very fast.
Also it means that authority data cannot be influenced by
cache entries (unless set 'transparent' of course), and
that makes poisoning of the authority data impossible by design.

Now the trouble is that if a CNAME is found, particularly
towards a remote site, then really, not an authority answer
but a recursive answer is desired.  I have been thinking about
this.

Perhaps the easiest solution is a type of local data where
- -RD queries get +AA answers.  No CNAME processing.
+RD queries go to the unbound recursive processing, and
this 'fetches' (new feature:) authority data from the
builtin authority store.  And returns the recursive lookup.
However this would normally store such data into the cache,
and it is very weird to have a server both authoritative
for the data as well caching that data (and counting down
the TTL on it as well).

Best regards,
   Wouter

On 10/19/2009 12:46 PM, Michael Tokarev wrote:
> Matthijs Mekking wrote:
> 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
> 

> _______________________________________________
> 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 Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkrlyMcACgkQkDLqNwOhpPgKKgCeM+fdMkbmMvp7XB0R4nCRzl7L
2xEAnAm42xuIclHKfySXqCBYozMBH5o/
=SEEO
-----END PGP SIGNATURE-----