Can't get CNAME entries to resolve

Unbound
1

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.

The only example I’ve found that highlights a CNAME entry as part of the Unbound config file is located at > http://www.howtoforge.com/installing-using-unbound-nameserver-on-debian-etch < Unfortunately the provided example – a sample of which is provided inline below – doesn’t work. Can someone steer me in the right direction as far as how to go about referencing both an internal and external CNAME alias which Unbound will then resolve when requests for the configured sub-domain are made?

Thanks in advance for your help!

local-zone: “example.net.” static
local-data: “example.net. 86400 IN NS ns1.hostingcompany.com.”
local-data: “example.net. 86400 IN NS ns2.hostingcompany.com.”
local-data: “example.net. 86400 IN SOA ns1.hostingcompany.com. hostmaster.hostingcompany.com. 2008052201 28800 7200 604800 86400”
local-data: “example.net. 86400 IN A 1.2.3.4”
local-data: “www.example.net. 86400 IN CNAME example.net.”
local-data: “mail.example.net. 86400 IN A 1.2.3.4”
local-data: “example.net. 86400 IN MX 10 mail.example.net.”
local-data: “example.net. 86400 IN TXT v=spf1 a mx ~all”

2

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

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

3

a message of 118 lines which said:

Unfortunately the provided example -- a sample of which is provided
inline below -- doesn't work.

You did not say in what way it "does not work". I installed the
configuration in my Unbound and what I can see:

1) Data is correctly served:

% dig CNAME www.example.net
...
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
...
;; ANSWER SECTION:
www.example.net. 86400 IN CNAME example.net.

2) CNAME is not followed:

% dig A www.example.net
...
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
...
;; AUTHORITY SECTION:
example.net. 86400 IN SOA ns1.hostingcompany.com. hostmaster.hostingcompany.com. 2008052201 28800 7200 604800 86400

Is it what you observe?

4

Hi M:D,

What you are running into is the fact that Unbound is not designed to be
a full-featured *authoritative* DNS server. It is a full featured
*recursive* DNS server.

Thus, Unbound can perform CNAME resolution as a recursive server very
well. But publishing CNAME records - what you are doing below - as an
authoritative server is not its forte.

The authoritative features present in unbound have been purposefully
left minimal; enough to block a site. Very simple.

How to make the stub thing work.
The idea is to use another server to be the authoritative server. Such
as NSD (the authoritative server made by NLnet Labs which has similar
high performance). You run NSD on port: 10053 with the example.net
zone. NSD is a good authoritative server for CNAME, DNSSEC, NSEC3, ...

Then you provide unbound with a stub zone
stub-zone:
  name: "example.net"
  stub-addr: 127.0.0.1@10053

You can also run the NSD server on a different computer, of course.

Best regards,
   Wouter

M. David Peterson wrote:

5

Hi Michael:

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.

Doh! It’s funny how easy it can be to skip over the obvious w/o giving second thought. Thanks for putting me back on track!

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.

Right, which now makes sense as to what the documentation is referring to.

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

Well, the fact that it’s easy to query an external NS is a plus! :slight_smile:

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!..

Blck! Didn’t realize this was happening. Damn it, Google Apps! :wink: Thanks for bringing this to my attention!

6

Yes, and it’s now clear why that is. Thanks for your help!

7

What you are running into is the fact that Unbound is not designed to be
a full-featured authoritative DNS server. It is a full featured
recursive DNS server.

Yeah, I should have spent that extra five seconds to think through things a bit before sending my query to the list. That said, you folks have been /more/ than generous with your time. Thanks!

How to make the stub thing work.
The idea is to use another server to be the authoritative server. Such
as NSD (the authoritative server made by NLnet Labs which has similar
high performance). You run NSD on port: 10053 with the example.net
zone. NSD is a good authoritative server for CNAME, DNSSEC, NSEC3, …

Then you provide unbound with a stub zone
stub-zone:
name: “example.net”
stub-addr: 127.0.0.1@10053

You can also run the NSD server on a different computer, of course.

I wasn’t aware of the existence of NSD before now. Thanks for bringing it to my attention and for providing the above example! Will try both now.
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david@3rdandUrban.com | m.david@amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 | http://broadcast.oreilly.com/m-david-peterson/