[solved] Unbound vs "nodomain"

[aboaboit]

I'm using unbound in parallel mode with dnsmasq, so far so good.

Now I've added a couple of SAP demo appliances (one is a VM and the other a Docker image) on my main desktop, each with a dedicated IP so the ports don't clash, official hostnames are:

• vhcalnplci.dummy.nodomain
• vhcala4hci.dummy.nodomain
  (by "official" I mean: I'm not allowed to change them, unless I'm prepared to go and hunt for all the places in the system where the demo name is used so, no, those are the names!)

I know I could simply edit the relevant hosts file on Linux and Windows clients and be done with it but I'm kind of allergic to mucking with local clients when I can fix it once and for all at the DNS level.

So, this is a part of /etc/config/dhcp:

config domain 'vhcalnplci'
        option name 'vhcalnplci.mylocaldomain'
        option ip '192.168.2.5'
config domain 'vhcala4hci'    
        option name 'vhcala4hci.mylocaldomain'
        option ip '192.168.2.6' 
config domain
        option name 'vhcalnplci.dummy.nodomain'
        option ip '192.168.2.5'            
config domain                 
        option name 'vhcala4hci.dummy.nodomain'
        option ip '192.168.2.6'

I can connect using the shortname in the SAP GUI config, no problem here, both on the same desktop and local clients. However, for some functions, the GUI will open a browser and use the FQDN instead of the shortname and this most definitely does't work right now.

"dig -p 1053 vhcala4hci.dummy.nodomain" returns the correct address so dnsmasq is fine.

I already have "option domain" in the config but it is already in use for "mylocaldomain" and it's an option, not a list.

How do I tell unbound that ".nodomain" is local as well as "mylocaldomain"?

I've tried with forward and stub zones but no luck so far:

[aboaboit]

@vgaetera first off, thanks

Without going into the nooks and crannies of SAP GUI, suffice it to say that not all clients have nmcli installed and, most important, I have yet to see a case where the browser was opened with anything but the full name. If we can get this to work, the search path would be a nice finishing touch but not more. The reason shortname lookups work is because both hostname are present with ".mylocaldomain"

Right now I have the following:

unbound.@zone[2]=zone
unbound.@zone[2].fallback='0'
unbound.@zone[2].enabled='1'
unbound.@zone[2].port='1053'
unbound.@zone[2].dns_assist='dnsmasq'
unbound.@zone[2].zone_type='forward_zone'
unbound.@zone[2].zone_name='dummy.nodomain.'
unbound.@zone[2].server='127.0.0.1'

I've tried your suggestion, no changes: fdqn lookup works on port 1053 (dnsmasq), fails on port 53 (unbound).

unbound.dummy_nodomain=zone
unbound.dummy_nodomain.enabled='1'
unbound.dummy_nodomain.fallback='0'
unbound.dummy_nodomain.zone_type='forward_zone'
unbound.dummy_nodomain.resolv_conf='1'
unbound.dummy_nodomain.zone_name='dummy.nodomain.'

I'm not convinced that "resolv_conf" should be enabled: the query should go to dnsmasq on localhost, port 1053, not to an external server.

[aboaboit]

Now this is interesting: I've raised verbosity to 3 (query level) and I spotted this bit:

Wed Mar 17 14:41:33 2021 daemon.info unbound: [28945:0] info: response for vhcala4hci.dummy.nodomain. A IN
Wed Mar 17 14:41:33 2021 daemon.info unbound: [28945:0] info: reply from <dummy.nodomain.> 127.0.0.1#1053
Wed Mar 17 14:41:33 2021 daemon.info unbound: [28945:0] info: query response was nodata ANSWER

To verify:

• "dig -p 1053 dummy.nodomain" on the router -> no answer
• "dig -p 1053 vhcala4hci.dummy.nodomain" -> correct IP

[aboaboit]

I got it to work, bypassing dnsmasq altogether:

# Special zone for SAP VM
local-zone: "dummy.nodomain." static
local-data: "vhcalnplci.dummy.nodomain. IN A 192.168.2.5"
local-data: "vhcala4hci.dummy.nodomain. IN A 192.168.2.6"
local-data-ptr: "192.168.2.5 vhcalnplci.dummy.nodomain"
local-data-ptr: "192.168.2.6 vhcala4hci.dummy.nodomain"

Domain search is handled with this addition to /etc/config/dhcp:
list dhcp_option '119,mylocaldomain,dummy.nodomain'

[vgaetera]

The current setup looks odd as Dnsmasq is usually the primary caching DNS forwarder.
So, when you install Unbound, Dnsmasq should forward requests to Unbound.
You can also just disable the DNS role for Dnsmasq and use Unbound exclusively.

[aboaboit]

Not at all odd: the setup you're describing is called "serial" in the documentation whereas I have adopted the "parallel" version because of the double transfers.