Hi Michael:<br><br><div class="gmail_quote">On Tue, Mar 3, 2009 at 12:34 AM, Michael Tokarev <span dir="ltr">&lt;<a href="mailto:mjt@tls.msk.ru">mjt@tls.msk.ru</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d"><br></div>
Unbound is a recursive resolver.  Its local data support is really<br>
rudimentary -- it can return whatever RRs you configured in local-data<br>
statements matching the query, without any attempt to interpret that<br>
data.  But CNAME requires interpretation -- because a recursive<br>
nameserver should return expansion of the CNAME record too, not only<br>
the CNAME itself.  </blockquote><div><br></div><div>Doh! It&#39;s funny how easy it can be to skip over the obvious w/o giving second thought. Thanks for putting me back on track!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

That&#39;s why documentation says about stub zone.  The idea is to have<br>
real authoritative nameserver nearby which can store all the data,<br>
and unbound is able to query it and any other nameserver to construct<br>
the full set.</blockquote><div><br></div><div>Right, which now makes sense as to what the documentation is referring to.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
 In other words, you have to remove all your local-data<br>
statements and delegate the work to a nameserver which can store and<br>
return authoritative data, such as nsd or bind.<br>
<br>
Funny enough, but for unbound it&#39;s easier to query some external<br>
nameserver than to return local data... ;)<br></blockquote><div><br></div><div>Well, the fact that it&#39;s easy to query an external NS is a plus! :-) </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

[]<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
local-zone: &quot;<a href="http://example.net" target="_blank">example.net</a> &lt;<a href="http://example.net" target="_blank">http://example.net</a>&gt;.&quot; static<br>
        local-data: &quot;<a href="http://example.net" target="_blank">example.net</a> &lt;<a href="http://example.net" target="_blank">http://example.net</a>&gt;. 86400 IN NS <br>
</blockquote>
<br>
And c&#39;mon, please, pretty please, get some less crappy mail user<br>
agent (MUA), -- the one which does not mangle your email like that,<br>
stupidly treating just everything like an URL!..</blockquote><div><br></div><div>Blck! Didn&#39;t realize this was happening. Damn it, Google Apps!  ;-)  Thanks for bringing this to my attention!</div></div><br>-- <br>/M:D<br>
<br>M. David Peterson<br>Co-Founder &amp; Chief Architect, 3rd&amp;Urban, LLC<br>Email: m.david@3rdandUrban.com | <a href="mailto:m.david@amp.fm">m.david@amp.fm</a><br>Mobile: (206) 999-0588<br><a href="http://3rdandUrban.com">http://3rdandUrban.com</a> | <a href="http://amp.fm">http://amp.fm</a> | <a href="http://www.oreillynet.com/pub/au/2354">http://www.oreillynet.com/pub/au/2354</a> | <a href="http://broadcast.oreilly.com/m-david-peterson/">http://broadcast.oreilly.com/m-david-peterson/</a><br>