[Dnsmasq-discuss] Minimal config: small # of A records, no upstream server

[Johnny Utahh]

On 2020-07-02 12:57 PM, Geert Stappers wrote:
> On Thu, Jul 02, 2020 at 06:16:49AM -0500, Johnny Utahh wrote:
>> On 2020-07-02 2:18 AM, Geert Stappers wrote:
>>> On Wed, Jul 01, 2020 at 10:06:36PM -0500, Johnny Utahh wrote:
>>>> Hello,
>>>>
>>>> Do I need to make any edits/additions to the dnsmasq.conf below to support
>>>> the following scenario?
>>>>
>>>> Ubuntu 20.04
>>>> dnsmasq 2.80
>>>>
>>>> Details:
>>>>
>>>> I want to provide a _minimal_ DNS server. It *only* serves a few A records
>>>> (from /etc/hosts).
>>>>
>>>> A key point: I want to make sure it does NOTHING else. No
>>>> upstream-DNS-server/service connection. Any DNS requests sent to said server
>>>> outside of the /etc/hosts A-record list will fail. Further: no DHCP, tftp,
>>>> or any others. All of the other bells and whistles I do not know about: I
>>>> want them disabled, too. Just plain old proper DNS records serving and
>>>> associated error-condition handling.
>>>>
>>>> Additionally, the dnsmasq-based DNS server will bind/interface/respond-to
>>>> only `eth8`.
>>>>
>>>>
>>>>      /etc/dnsmasq.conf:
>>>>      interface=eth8
>>>>      no-dhcp-interface=eth8
>>>>
>>> That is indeed not enough for the desired use case.
>>>
>> Thanks, quite good to know. What edits or additions (to the following
>> `/etc/dnsmasq.conf` or any other file) are needed to serve this use case?
> Something that tells Dnsmasq to do non default things.
>
>    server=127.0.0.1#13131
>
> The idea is that dnsmasq does go searching for an upstream DNS. That it
> uses localhost  port 13131.  With nothing at 13131 should result in
> a "nothing here" and thus ending the DNS resolve attempt. If that truely
> gets back to the DNS client as "hostname not found" is unknown to me.
>
> In other words: Default behaviour of dnsmasq is to use the DNS available
> to the host.  Original Poster doesn't want that, so should do something
> extra to prevent.  But be aware that I never have travelled that road.
> Euh yes, I would like to hear how it went.

I'm presuming the only issue here is preventing searches and potential 
"uplinks" with upstream DNS nameservers and that "disabling all other 
features" is addressed by the following settings:

     /etc/dnsmasq.conf:
     port=[myport]
     no-resolv
     no-poll
     interface=eth8
     no-dhcp-interface=eth8
     no-hosts
     addn-hosts=/etc/dnsmasq_a_records
     domain=[mydomain.tld]


> The idea is that dnsmasq does go searching for an upstream DNS.

Okay, copy that, very helpful. It seems dnsmasq is currently determined 
to hunt for upstream namesevers and there's no elegant way to disable 
this... but I explore this point more-exhaustively with these 
points/comments:

1. I'm surprised there's no directive/setting to specifically prevent 
dnsmasq from searching for an upstream DNS. If so: why is my scenario 
(seemingly?) rare enough that such a feature (presumably?) was not 
needed?  While this use case is not predominate, this does not seem like 
an uncommon use case, namely for "isolated VPNs."

2. Does `no-resolv` + `no-poll` effectively implement the feature 
described in #1?

3. I'm happy to implement `server=127.0.0.1#[unused_port_number]` to 
effectively provide the feature described in #1. However, I'm concerned 
about a couple, potential, derivative behaviors:

3.a.  How certain are we that this "workaround" completely disables the 
upstream searching/connections?

3.b. Minor concern: does a continual attempt to connect with a 
non-served port (especially if it's a UDP request) effectively create 
some performance degradation over time (particularly if "reconnects" are 
attempted frequently)?

4. Are there truly, absolutely no other options to prevent 
upstream-nameserver searches?  Does someone besides Geert have any 
direct experience with or hear of others trying this?

5. If I restrict the interface bindings to a VPN-only ethernet device 
(that is itself isolated from the public internet), does this help with 
this "upstream searching restriction"?


In any case, I will test this approach and report back what I find.

~Johnny

/environment: Ubuntu 20.04 //dnsmasq 2.80/

-- 
//
-- 
//
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20200702/15ab36ab/attachment-0001.html>