[Unbound-users] Can't get CNAME entries to resolve

[Michael Tokarev]

M. David Peterson wrote:
> Hello,
> 
> I've been playing around with Unbound and thus far have been /very/ 
> impressed with its performance.  In fact, the only thing currently 
> preventing me switching our primary and secondary DNS from BIND to 
> Unbound is the fact that I can't seem to figure out how to get CNAME 
> resolution to work properly.  The documentation makes reference to using 
> a stub-zone to gain CNAME support, but it's not obvious what that means 
> exactly. I've played around with different stub-zone configurations but 
> as of yet haven't found that seems to work correctly.

Unbound is a recursive resolver.  Its local data support is really
rudimentary -- it can return whatever RRs you configured in local-data
statements matching the query, without any attempt to interpret that
data.  But CNAME requires interpretation -- because a recursive
nameserver should return expansion of the CNAME record too, not only
the CNAME itself.  And this is what unbound currently lacks -- if
CNAME configured in local-data, unbound will only return the record
itself, it will not expand the name the CNAME points to, and second
query is required for that to work (but most stub resolvers in use
today aren't smart enough for that).

That's why documentation says about stub zone.  The idea is to have
real authoritative nameserver nearby which can store all the data,
and unbound is able to query it and any other nameserver to construct
the full set. In other words, you have to remove all your local-data
statements and delegate the work to a nameserver which can store and
return authoritative data, such as nsd or bind.

Funny enough, but for unbound it's easier to query some external
nameserver than to return local data... ;)

And speaking of implementation details, I don't quite understand
this very issue, and my issue too (owerwriting implicit AS112 zones
thread as of few days ago).  If I were to implement this, I'd use
the same cache for local-data as for all the remote stuff, but I'd
mark certain records there as non-expireable (those local-data RRs
and {local,stub,forward}-zone declarations).  This way should solve
all problems like this.  But I never ever looked at how things are
implemented internally, so it's just my guess...

[]
> local-zone: "example.net <http://example.net>." static
>         local-data: "example.net <http://example.net>. 86400 IN NS 

And c'mon, please, pretty please, get some less crappy mail user
agent (MUA), -- the one which does not mangle your email like that,
stupidly treating just everything like an URL!..

/mjt