Commonly it would require an authoritative DNS server to serve records and not just a resolver. However, dnsmasq has apparently the option to serve/resolve records for private domains. Suppose your router utilizes the vanilla resolver kresd (knot reolver) in which case you might want to look up the respective documentation - I am not familiar with it and thus cannot assist. Else and alternatively there is unbound (my preference) as resolver which can either use dnsmasq (in tandem) for resolving private domains or it can serve (and resolve) records for private domain on its own. It depends what you want.

For some use cases dnsmasq is better, for some it certainly isn’t (even on a router). Dnsmasq has an advantage here that it has always been designed specifically to run on routers whereas knot-resolver is not. Even so, I believe for most router users knot-resolver is better than dnsmasq (including my own Omnia), but my opinion on this isn’t really relevant here (and perhaps not even “trust-worthy” as I develop knot-resolver) – it’s about the choice of each person (for their device) and of the Turris team (for the default). It is possible to run with dnsmasq only on Omnia, though reportedly there were some problems with updates (I don’t really know, you can search this forum). To expand on other choices, some people on this forum prefer to ditch whole Turris OS for plain OpenWRT, or use a different HW. Vcunat: Dnsmasq has an advantage here that it has always been designed specifically to run on routers whereas knot-resolver is not.

Tell dnsmasq to filter out queries which the public DNS cannot. # answer, and which load the. This option only affects forwarding, SRV records originating for. # dnsmasq (via. A SRV record sending LDAP for the example.com domain to.

I have seen videos of talk at ripe et.al where turris folks share their frustration of making a dns resolver work with the professional community and earn sympathy. I think most users (here) would sympathize as well.

The ratio of issues caused by vs. Issues solved by knot for turris users further indicates that it might not be warranted to shove this onto unsupecting con-/prosumers (as a default) when there is something with a better feature set (for the job) already available. I really appreciate the work that went into knot, i just dont think the countless hours of turris users, each figuring out that knot may no be the right tool for their job, helped much. Hadc: [] i just dont think the countless hours of turris users, each figuring out that knot may no be the right tool for their job, helped much.

I think for vast majority of Omnia users it just works, even if most users with problems don’t write anywhere about that (thousands of Omnias are in use), and some users actually want features missing on dnsmasq (e.g. TLS forwarding).

I believe one “marketing problem” here is that Omnia wants to present itself as secure, which is why Unbound was used in Turris 1.x (Knot-resolver wasn’t really usable at that point).

# Configuration file for dnsmasq. # # Format is one option per line, legal options are the same # as the long options legal on the command line. See # '/usr/sbin/dnsmasq --help' or 'man 8 dnsmasq' for details.

# Listen on this specific port instead of the standard DNS port # (53). Setting this to zero completely disables DNS function, # leaving only DHCP and/or TFTP.

#port=5353 # The following two options make you a better netizen, since they # tell dnsmasq to filter out queries which the public DNS cannot # answer, and which load the servers (especially the root servers) # unnecessarily. If you have a dial-on-demand link they also stop # these requests from bringing up the link unnecessarily. # Never forward plain names (without a dot or domain part) #domain-needed # Never forward addresses in the non-routed address spaces.