Wouter, 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. 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. Whenever possible, a customer's DNS is setup cnamed to ourdom.com. So mail.customer.com is cnamed to mail.ourdom.com, www.customer.com cname web1.ourdom.com, MX of customer.com points to smtp.ourdom.com. We then only have to maintain internal IPs for ourdom.com, much less overhead on an internal DNS box. The one downside to this is what if we host a website and we type customer.com, can't cname that, so this is where Unbound came in. 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 ourdom.com. Unbound forwards to Bind and Bind forwards to the ISP's DNS. This allowed for www.customer.com (which cnames to web1.ourdom.com) to resolve to a private IP. I can use local-data to override customer.com. A with the private IP. Tried to send an email to customer.com, the email server can't find the MX record. The MX record exists upstream, it points to smtp.ourdom.com. When I hit Bind directly, it returns the private IP fine. Unbound returns that the record doesn't exist due to overriding company.com A. I can make this work by adding the MX records into Unbound along with company.com 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: "company.com. 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. Thanks for comments, -Bryan On Fri, Mar 19, 2010 at 4:07 AM, W.C.A. Wijngaards <wouter at nlnetlabs.nl>wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Bryan, > > Why do you want this, really? It is not possible to simple set the MX > or NS records as well? > > Or the set-up that Paul detailed? > > Just asking before bloating the code with a feature. > > Best regards, > Wouter > > On 03/18/2010 08:10 PM, Bryan Clay wrote: > > Hello all, > > > > It's my understanding that in a configuration like: > > > > local-zone: foo.com transparent > > local-data: "foo.com A 55.55.55.55" > > > > Any queries for MX or NS records on foo.com <http://foo.com> will > > return NOERROR/NODATA by design, even if that data exists in a forwarder > > upstream. This make me cry and I would be hugely grateful for a method, > > now or in a future release, for a way to bypass this behavior. > > > > I also recommend that this specific behavior be documented with the rest > > of the transparent behavior in the manual. It took me more than an hour > > to diagnose this issue. Maybe it will keep some other poor sap from > > going insane. > > > > Thanks for comments, > > Bryan > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkujMKgACgkQkDLqNwOhpPjgDACdHORbXf3SymDt+twjK+z7vi6D > L7wAnjS/0D1IjmLLMywSeN442Axip9X3 > =kCwS > -----END PGP SIGNATURE----- > _______________________________________________ > Unbound-users mailing list > Unbound-users at unbound.net > http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20100319/f20672a7/attachment.htm>