Unbound: shortname lookups? non authoritative answer?

Installing and Using OpenWrt Network and Wireless Configuration
1

In a previous post after installing unbound there's the solution to my first relevant issue after installing unbound.

Couple of things still bug me:

  1. whereas "ping" with a shortname works (because the local resolver will add the domain before querying the dns), a direct dig query with a shortname still goes to root and of course fails. The same goes, of course, when the shortname is entered in the configuration of a program, say transgui.

I thought I had to change "option domain" in unbound.conf from the default "lan" to my own localdomain but the documentation says the option is ignored when link is dnsmasq and I've found that to be correct.

Any ideas? Is this the expected behaviour?

  1. in a parallel scenario, unbound is asking dnsmasq for dhcp-assigned entries and the reply is listed as non-authoritative, which is technically correct since unbound did not have first-hand information.

Is there a way to tell unbound that queries to dnsmasq for local domain can be considered authoritative?

2

@anomeome @dlakelan any ideas?

3

I think so. dig/host/dnslookup is for debugging DNS, you don't want it looking up something other than what you actually typed in.

2 Likes
4

Thanks, that makes sense. Reason for asking is that I had the shortname for my NAS in the configuration of transgui and now it is not resolved anymore, only fqdn works. The NAS was on static IP assignment before and still is now, clients were and still are on dhcp, only change was the switch from dnsmasq to unbound.

5

Right, I suspect that dnsmasq takes short names and adds the local domain because it knows it's authoritative for that local domain. unbound is purely recursive, so it's never authoritative for anything and doesn't add the local domain.

It's just a guess. I specifically chose to do the serial version DNSmasq -> unbound -> Cloudflare DoT because DNSmasq is doing some nonstandard stuff on purpose to support the local domain / DHCP etc.

3 Likes
6

Ok, I see your reasoning. I'll probably roll back the changes, capture a few lookups with wireshark and then compare.

I expected clients to use the domainname supplied via DHCP to complete the hostname before sending the query but they have different OS, different networks and different settings, so it's better to check.

EDIT: not done yet, but I've since found out that my QNAP NAS does not have a way to enter a search domain when using the static configuration. Bummer! And it is ignored when supplied via dhcp, double bummer!

7

Well, there's no consistency in how dns lookups are made :frowning: but apparently this is not due to unbound or the integration with dnsmasq (serial vs parallel).

For example, the same Android client using the same two test apps (fing and transdrone) will occasionally query for shortname and occasionally for fqdn. This may be due to the adblock (blockada) since disabling it momentarily seems to yield more consistent results.

I'll stick with fqdn everywhere and be on my way :slight_smile: