Per interface DNS Forwarder configuration

gvecchi

Hi guys,

is it possibile to configure DNS Forwarding service per interface?
I need to configure different Host/Domain overrides based on OpenVPN interface.

Thanks

jimp

It's not supported in the web interface, but the DNS Resolver daemon does support views which can provide different answers depending on where the client is coming from. If you search around the forum you should find some examples to put in the advanced options.

The old DNS Forwarder doesn't support that as far as I know. It does have a "localize queries" option but that only controls responses for hostnames with addresses in the same subnet as clients.

noplan

That sounds pretty impressive...
I m in!

gvecchi

@jimp thanks for your info. Why are you calling the DNS Forwarder as "old"?

johnpoz

While you can create views, and you can forward to different things based upon those views... You do understand the cache is now shared right..

Views are not really meant for this sort of feature.

Be over this multiple times already... If you forward client X to filtering dns, say opendns for example and p0rn is blocked.. But Y you want to let view p0rn - or other way around, etc. So you forward them to googledns (no filtering)..

The one that gets cached will be the one the other one gets, so might be filtered, might not be filtered.

If you want client X to use different dns than Y - then point them their directly. You can not point them to something that has a common cache.

Views are meant as views to "local" data..

gvecchi

@johnpoz thanks for your tricks but I only need to configure different Host/Domain overrides based on OpenVPN interface for internal domains, DNS servers will still remain the internal ones.

johnpoz

Again - host override you can do that is local data to the unbound...

My point is if you say X clien wants to lookup domain.tld point them to here via domain override.. That entry is now cached locally. Y comes along and queries for domain.tld - Y will get that answer..

You can have the records locally on unbound, and control who can view what, and what gets returned based upon query source IP, etc.. But once you forward that to get the answer somewhere else - the answer is cached locally in unbound. And I do not believe there is a way to have non shared chache.. Everyone can view the cache - doesn't matter what view they might be in.

What exactly are you trying to accomplish with different domain overrides for different clients? Why can everyone not just lookup everything? Do you need to point them to different IPs for the fqdn based upon their source IP?

gvecchi

@johnpoz I have an internal domain, let's say domain.tld, and several sub-domains, let's say sub1.domain.tld, sub2.domain.tld and sub3.domain.tld,,: the goal is that clients from OpenVPN connection #1 will be able to resolve each subdomain and clients from OpenVPN connection #2 will be able to resolve only sub1.domain.tld while for domain.tld, sub2.domain.tld and sub3.domain.tld an empty response is expected.

johnpoz

And here is where there is a problem with that.. If client A looks up sub1.domain.tld, now client B comes in and sub1.domain.tld is cache and will get back an answer for sub1.domaint.tld even though you don't want him looking that up.

For your solution to work with views, then all your records for sub1, sub2, etc.. would need to be local on unbound... Now your views can say hey B can not lookup shit in sub1.. only A can.. But if your forwarding to some other NS to lookup sub1 or sub2.. Once that is looked up its in the local cache.. .Which is shared out to ALL clients.. There is no way to say client A can only lookup sub1 records from the cache, If B asks for sub1.domain.tld record and its in the cache - then he will get that returned..

jimp

That does not seem to be the case with unbound. It's smart enough to use the right data for local views. Remote hosts are probably from the cache but I haven't double checked that.

In the Unbound advanced options:

server:
access-control-view: 10.6.0.1/32 viewa
access-control-view: 10.6.0.10/32 viewb

view:
name: "viewa"
local-zone: "example1.com." static
local-data: "test1.example1.com. 90 IN A 1.1.1.1"

view:
name: "viewb"
local-zone: "example1.com." static
local-data: "test1.example1.com. 90 IN A 10.10.10.10"

From 10.0.6.1:

: host test1.example1.com 10.6.0.1
Using domain server:
Name: 10.6.0.1
Address: 10.6.0.1#53
Aliases: 

test1.example1.com has address 1.1.1.1

From 10.6.0.10:

% host test1.example1.com 10.6.0.1
Using domain server:
Name: 10.6.0.1
Address: 10.6.0.1#53
Aliases: 

test1.example1.com has address 10.10.10.10

johnpoz

That works yes - that is LOCAL data..

local-zone: "example1.com." static
local-data: "test1.example1.com. 90 IN A 1.1.1.1"

But if you just forward view A to NS1, and forward view B to NS2... your cache of those records is shared.

jimp

@johnpoz said in Per interface DNS Forwarder configuration:

That works yes - that is LOCAL data..

Which is what OP wants.

I need to configure different Host/Domain overrides based on OpenVPN interface.

johnpoz

NO that is not what he wants..

I need to configure different Host/Domain overrides based on OpenVPN interface.

A domain override points to another NS...

If all he has is local data on unbound, and does not point to another NS to resolve these sub1.domain.tld and sub2.domain.tld then yes he is fine... Be has clearly called out domain overrides which are not local data. They are forwards to a different NS.

jimp

@gvecchi said in Per interface DNS Forwarder configuration:

@jimp thanks for your info. Why are you calling the DNS Forwarder as "old"?

Forgot to address this. The DNS Forwarder service (dnsmasq) used to be the default, but it's not the default any more. The DNS Resolver (unbound) is the current default and what we recommend everyone use. It's more secure, and has more flexibility/capability. We've considered removing the DNS Forwarder but it still has some features people like which are not in the DNS Resolver. Since the DNS Forwarder is no longer the default, it doesn't receive the same level of attention or development work the DNS Resolver does.

jimp

@johnpoz said in Per interface DNS Forwarder configuration:

NO that is not what he wants..
I need to configure different Host/Domain overrides based on OpenVPN interface.
A domain override points to another NS...

You're reading the words they wrote too literally. Based on their later replies they only want host overrides or to override responses for certain domains, not forwarding to other DNS servers.

johnpoz

Sorry if I read what they wrote as they wrote it... He clearly lists both host and domain.

I have been clear that if the data is local its fine - but that is NOT what a domain override is.. Which he clearly stated he needed.

jimp

Their other reply:

I have an internal domain, let's say domain.tld, and several sub-domains, let's say sub1.domain.tld, sub2.domain.tld and sub3.domain.tld,,: the goal is that clients from OpenVPN connection #1 will be able to resolve each subdomain and clients from OpenVPN connection #2 will be able to resolve only sub1.domain.tld while for domain.tld, sub2.domain.tld and sub3.domain.tld an empty response is expected.

Nowhere does it mention alternate DNS servers. Everything they mentioned was local data.

johnpoz

Well then why did he call out domain overrides for??

If your not doing domain overrides then yes this works fine.

jimp

Probably because they don't know the exact terminology. *shrug*

jimp

Also worth noting that unbound doesn't appear to support views for forward-zones, only local data: https://nlnetlabs.nl/documentation/unbound/unbound.conf/

I tried it just to see if it worked and it didn't respect the directives but it also didn't generate any errors.