Unbound prioritizes external answers over dnsmasq's answers

jus7incase · November 19, 2019, 10:57pm

Hi all

I have so far been running dnsmasq as it comes out of the box.
To enjoy various DNS security protocols I installed unbound and the LUCI interface for unbound.
I configured it to use dnsmasq for DHCP. (The DoT resolution work like a charm - but that is not the topic here. If you are interested in the setup, you may still well ask.)

I need this because I have configured a substantial number of internal hostnames in dnsmasq. More detailed explanation further down.

I seems that unbound first asks any servers configured in unbound, and if it does not find answer there, it will ask dnsmasq. This means, if there is a hostname that exists on an external NS and also in my dnsmasq hostnames, unbound will answer with the IP resolved from the external NS.

So you ask - what the .... why is this a problem?

There is one use case that makes me depend on this:
For all mobile clients I have configured a global name for all my own services that I consume from my home LAN and also when on the road coming from WAN. However, these services are not running on OpenWRT, but in my DMZ on a dedicated server. If I just provide a DDNS IP for the service, it will be reachable from the WAN, so when I am on the road. But from my home LAN, this does not work, because the packets would need to be routed to the WAN interface and from there would need to be forwarded back to the DMZ server. OpenWRT doesn't do this, and it would also be inefficient.

To solve this, I also provided the same global names - which I registered with DDNS providers - also in my dnsmasq hostnames, but assign the internal DMZ IP addresses there - not the external IP.

So far this has worked very well, because dnsmasq was responding with the local hostnames first, before it was asking external NSes.

Since I use unbound, this order as turned around, and the IPs from the external DDNSes are returned before the internal dnsmasq is asked.

This way, I cannot reach my DMZ services using the global names any more from LAN.

Long story short - the question is:
Is there a way i can make unbound asks the local dnsmasq BEFORE it asks other NSes?
(or is this overall a stupid idea and you have a better solution how I can reach my DMZ services from LAN and from WAN using the same FQDN?)

Any help is highly appreciated!
JC

jeff · November 19, 2019, 11:01pm

Look into unbound views, (type-)transparent zones, and stub resolvers. That's how I provide local overrides on a subnet-by-subnet basis for "global" DNS entries.

(I have no idea how to configure with UCI, as I use file-based config.)

jus7incase · November 19, 2019, 11:35pm

Hi jeff, thanks for the pointers. i actually read up on those concepts in the manpage. Since I a totally new to unbound I have not clue what the config file blocks would have to look like for what you are proposing. Do you mind giving a sample setup and sample excerpts from your config that implement the overrides?

I know this is some work. It would be of great help and appreciated, I am still stuck..

jeff · November 19, 2019, 11:54pm

Working "from the inside out" (super stripped-down example)

Define the local overrides

$ cat zones/external.192.168.1.0.zone 
local-data: "imaps.example.com.			A	192.168.1.4"
local-data: "mail.example.com.			A	192.168.1.4"
[...]

and their reverse

$ cat zones/192.168.1.rev 
local-data-ptr: "192.168.1.4			mail.example.com"
[...]

Now define a view for hosts on the 192.168.1.0/24 subnet

$ cat 40-view-data.conf 
view:
	name: 192.168.1.0
	view-first: yes

	include: /var/unbound/conf.d/zones/external.192.168.1.0.zone

Define the zone itself

$ cat 30-global-data.conf 
server:
local-zone: "example.com." typetransparent

and give it to the clients

$ cat 20-access-control.conf 
server:
	interface:	0.0.0.0
	interface:  	::0

	access-control: 192.168.1.0/24 allow

	access-control-view: 192.168.1.0/24	"192.168.1.0"

Make sure that 192.168.0.0 can be returned

$ cat 10-server.conf 
#
# See ideas at
# https://calomel.org/unbound_dns.html
#

server:

	private-address: 192.168.0.0/16

So, with this, a host on the 192.168.1.0/24 subnet makes a request for something in example.com

is allowed by 20-access-control.conf
is assigned to the view that I chose to name "192.168.1.0" (a helpful name that just happens to be the subnet)
Looks at the view-first
If the data is there (mail.example.com), it gets it (locally accessible "inside" server)
If the data is not there, typetransparent sends the request for cloud.example.com to the public servers for example.com, and receives the "public" address

typetransparent means that if, for example, you're looking for MX for mail.example.com, it will go to the public servers (as the local data is only for A records).

I haven't hooked up dnsmasq, as I run kea, and just have the static IPs assigned listed in my zone files. I've personally never found much value in reverse resolving to DHCP-generated names. I've thought it through in the past. As I recall, another layer with setting dnsmasq as a stub resolver was the approach I would have taken. I checked my notes and unfortunately didn't find any details.

Keywords: split-horizon DNS, hairpin NAT

jus7incase · November 20, 2019, 12:11am

Thanks, I am trying to wrap my head around it. In my case it is just 1! global name because I just have 1 WAN IP with 1 DDNS provider. OK actually I assign the same WAN IP to several DDNS providers for failover.
Would that mean that I need for each DDNS name a separate zone (they all point to the same IP!), or would I put them all in one zone. If several zones, could I use 1 view fo all of them or would I have to create an own view for each of the zones?

shm0 · November 20, 2019, 12:17am

Isn't using a forward zone much easier?
(stub zone doesn't work because dnsmasq doesn't act as authoritative dns server?)

Something like:
/etc/config/unbound

config zone
	option enabled '1'
	option fallback '0'
	option zone_type 'forward_zone'
	list zone_name 'host1.ddnsdomainname.com'
	list zone_name 'host2.ddnsdomainname.com'
	list server '127.0.0.1@1053'

//edit
None uci approach:
In /etc/unbound/unbound_ext.conf add:

forward-zone:
  name: host1ddnsdomain.com
  forward-addr: 127.0.0.1@1053
  forward-first: no
  forward-tls-upstream: no

forward-zone:
  name: host2ddnsdomain.com
  forward-addr: 127.0.0.1@1053
  forward-first: no
  forward-tls-upstream: no

/etc/unbound/unbound_srv.conf

private-domain: host1ddnsdomain.com
private-domain: host2ddnsdomain.com
domain-insecure: host1ddnsdomain.com
domain-insecure: host2ddnsdomain.com

Assuming that dnsmasq is running on port 1053.
And that dnsmasq is still configured to give out local IP address for the ddns hostname(s).

But jeffs approach is the better one

jeff · November 20, 2019, 12:25am

I create a view for each of my subnets. That way, for example, my phone and laptop always get mail from “imaps.example.com” on wireless, wired, VPN to home, or outside. They get an on-link IP at home, my public IP (port forwarded at my router) when away. No messy hairpin NAT games.

jus7incase · November 20, 2019, 1:21am

I tried this method as it seemed easier. Alas, it does not work. The reason seams to be that the "config zone" paragraph is not recognized in "/etc/config/unbound" and those keywords seem not to be defined (see https://github.com/openwrt/packages/blob/openwrt-18.06/net/unbound/files/README.md)

Does that actually work for you, shm0?

anomeome · November 20, 2019, 1:34am

Appears to have been introduced in later versions, there in master and also 19.x I think.

shm0 · November 20, 2019, 2:07pm

I apologize that I overlooked this.

I edited my post above to include a none uci approach.

jus7incase · November 20, 2019, 2:38pm

Thank you shm0, that works on OpenWT 18, indeed.

shm0 · November 20, 2019, 2:42pm

I'm glad that it works you

jus7incase · November 20, 2019, 8:08pm

Actually DHCP does not seem to announce the router as dns server any more. How can I verify that (I looked into the DHCP ACK using wireshark and I found NO DNS servers), and where could I check the config accordingly?

jeff · November 20, 2019, 8:23pm

tcpdump-mini would be a great tool to use to diagnose.

jus7incase · November 20, 2019, 8:26pm

any DHCP specific tools? like dhclient?
I am looking around what the reason could be. the interface dhcp settings look normal in the UI at least.

jus7incase · November 20, 2019, 8:30pm

I tried to put "6,10.0.1.40" in DHCP Options for LAN interface. Accordingly the DHCP ACK now containts "DNS Server". That was not necessary earlier when I was just using dnsmasq. This since to have broken when I installed unbound. ???? Is this a bug?