Maintained by: NLnet Labs

[Unbound-users] local-zone transparent behavior

Bryan Clay
Fri Mar 19 14:18:21 CET 2010


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  So is cnamed to, cname, MX of points to  We then only
have to maintain internal IPs for, much less overhead on an
internal DNS box.  The one downside to this is what if we host a website and
we type, 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  Unbound forwards to Bind and Bind forwards to the ISP's DNS.
 This allowed for (which cnames to to
resolve to a private IP.  I can use local-data to override A
with the private IP.

Tried to send an email to, the email server can't find the MX
record.  The MX record exists upstream, it points to  When
I hit Bind directly, it returns the private IP fine.  Unbound returns that
the record doesn't exist due to overriding A.

I can make this work by adding the MX records into Unbound along with 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" 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,

On Fri, Mar 19, 2010 at 4:07 AM, W.C.A. Wijngaards <wouter at>wrote:

> 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: transparent
> > local-data: " A"
> >
> > Any queries for MX or NS records on <> 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
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora -
> iEYEARECAAYFAkujMKgACgkQkDLqNwOhpPjgDACdHORbXf3SymDt+twjK+z7vi6D
> L7wAnjS/0D1IjmLLMywSeN442Axip9X3
> =kCwS
> _______________________________________________
> Unbound-users mailing list
> Unbound-users at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>