Local-zone transparent behavior

Unbound
1

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

2

Unbound is not a authoritative nameserver, so logic for MX and/or additional data
is not really there, other then the simple "insert in cache" override you use above.
For more complicated things, use a forwarder to a local auth nameserver that has that
zone, eg:

stub-zone:
   name: "foo.com."
   stub-addr: 127.0.0.1@5353
   stub-prime: "no"

Then run an auth server (nsd or bind) on port 5353 that has the zone foo.com.

Note that if you want answers that contain RFC1918 space, eg 192.168.0.0/16
you might need an additional:

local-zone: "168.192.in-addr.arpa." nodefault

Paul

3

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

4

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

5

Ohh, this might be because the RFC1918 address are dropped for security reasons.
To allow these, check the private-address: and private-domain: options. Try
adding:

private-domain: cust1.com
private-domain: cust2.com
private-domain: cust3.com

Paul

6

I just tried this to no effect. I’m thinking the behavior I detailed is by design due to a change log entry on Unbound 1.2.0.

“fixup reported problem with transparent local-zone data where queries with different type could get nxdomain. Now queries with a different name get resolved normally, with different type get a correct NOERROR/NODATA answer.”

The MX is a different type than the A, so it gets NOERROR/NODATA…or am I misunderstanding that entry?

-Bryan