<div>Wouter,</div><div><br></div><div>I haven't used stub zones much, but my understanding of stub zones is they're kind of a read-only secondary zone.  I don't think they will solve my issue.</div><div><br></div>
<div>I'll spare you the long story as to why, it's a good one, but this is what I'm trying to do.  This setup is a local DNS server, so addresses that would normally resolve to an external IP will get resolved to a private IP.</div>
<div><br></div><div>Whenever possible, a customer's DNS is setup cnamed to <a href="http://ourdom.com">ourdom.com</a>.  So <a href="http://mail.customer.com">mail.customer.com</a> is cnamed to <a href="http://mail.ourdom.com">mail.ourdom.com</a>, <a href="http://www.customer.com">www.customer.com</a> cname <a href="http://web1.ourdom.com">web1.ourdom.com</a>, MX of <a href="http://customer.com">customer.com</a> points to <a href="http://smtp.ourdom.com">smtp.ourdom.com</a>.  We then only have to maintain internal IPs for <a href="http://ourdom.com">ourdom.com</a>, much less overhead on an internal DNS box.  The one downside to this is what if we host a website and we type <a href="http://customer.com">customer.com</a>, can't cname that, so this is where Unbound came in.</div>
<div><br></div><div>I can use Unbound's transparent local-zone feature.  Install a box with Unbound on port 53 and Bind on 5353, with Bind maintaining private IPs for <a href="http://ourdom.com">ourdom.com</a>.  Unbound forwards to Bind and Bind forwards to the ISP's DNS.  This allowed for <a href="http://www.customer.com">www.customer.com</a> (which cnames to <a href="http://web1.ourdom.com">web1.ourdom.com</a>) to resolve to a private IP.  I can use local-data to override <a href="http://customer.com">customer.com</a>. A with the private IP.  </div>
<div><br></div><div>Tried to send an email to <a href="http://customer.com">customer.com</a>, the email server can't find the MX record.  The MX record exists upstream, it points to <a href="http://smtp.ourdom.com">smtp.ourdom.com</a>.  When I hit Bind directly, it returns the private IP fine.  Unbound returns that the record doesn't exist due to overriding <a href="http://company.com">company.com</a> A.</div>
<div><br></div><div>I can make this work by adding the MX records into Unbound along with <a href="http://company.com">company.com</a> A, but the data I want is already upstream, I'd rather not enter it again.  Looking at it from where I am, it would be really nice to have the local-data override be type specific (local-data: "<a href="http://company.com">company.com</a>. A 22.22.22.22" only overrides the A record and not the MX.)  It would be even better to only have to tell Unbound one time that I want it that way, and not on every zone.</div>
<div><br></div><div>Thanks for comments,</div><div>-Bryan<br><br><div class="gmail_quote">On Fri, Mar 19, 2010 at 4:07 AM, W.C.A. Wijngaards <span dir="ltr"><<a href="mailto:wouter@nlnetlabs.nl">wouter@nlnetlabs.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Hi Bryan,<br>
<br>
Why do you want this, really?  It is not possible to simple set the MX<br>
or NS records as well?<br>
<br>
Or the set-up that Paul detailed?<br>
<br>
Just asking before bloating the code with a feature.<br>
<br>
Best regards,<br>
   Wouter<br>
<div class="im"><br>
On 03/18/2010 08:10 PM, Bryan Clay wrote:<br>
> Hello all,<br>
><br>
> It's my understanding that in a configuration like:<br>
><br>
> local-zone: <a href="http://foo.com" target="_blank">foo.com</a> transparent<br>
> local-data: "<a href="http://foo.com" target="_blank">foo.com</a> A 55.55.55.55"<br>
><br>
</div>> Any queries for MX or NS records on <a href="http://foo.com" target="_blank">foo.com</a> <<a href="http://foo.com" target="_blank">http://foo.com</a>> will<br>
<div class="im">> return NOERROR/NODATA by design, even if that data exists in a forwarder<br>
> upstream.  This make me cry and I would be hugely grateful for a method,<br>
> now or in a future release, for a way to bypass this behavior.<br>
><br>
> I also recommend that this specific behavior be documented with the rest<br>
> of the transparent behavior in the manual.  It took me more than an hour<br>
> to diagnose this issue.  Maybe it will keep some other poor sap from<br>
> going insane.<br>
><br>
> Thanks for comments,<br>
> Bryan<br>
</div>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.9 (GNU/Linux)<br>
Comment: Using GnuPG with Fedora - <a href="http://enigmail.mozdev.org/" target="_blank">http://enigmail.mozdev.org/</a><br>
<br>
iEYEARECAAYFAkujMKgACgkQkDLqNwOhpPjgDACdHORbXf3SymDt+twjK+z7vi6D<br>
L7wAnjS/0D1IjmLLMywSeN442Axip9X3<br>
=kCwS<br>
-----END PGP SIGNATURE-----<br>
_______________________________________________<br>
Unbound-users mailing list<br>
<a href="mailto:Unbound-users@unbound.net">Unbound-users@unbound.net</a><br>
<a href="http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users" target="_blank">http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users</a><br>
</blockquote></div><br></div>