What's wrong with CNAMEs in local-data?

Unbound
1

Out of curiocity.

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

2

Hi Michael,

Cached data is gathered querying authoritative servers, local data is
not. Unbound is a recursive resolver, not an authoritative one. Thus, it
can resolve CNAMEs, but it is not intended to publish CNAMEs. The
authoritative features are minimal with a purpose.

If you need authoritative local data with CNAME (and DNAME, referrals,
wildcards, ...) processing, I advise to set up a stub zone.

stub-zone:
    name: "stub.example"
    stub-addr: 127.0.0.1 at 10053

And run NSD on port 10053 with the stub.example zone.

Best regards,

Matthijs Mekking
NLnet Labs

Michael Tokarev wrote:

3

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 :wink:

I'll try to dig into sources.

Thanks.

4

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