<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 2020-07-02 12:57 PM, Geert Stappers wrote:<br>
<blockquote type="cite"
cite="mid:20200702175734.rbn7wxmp26vrpvlt@gpm.stappers.nl">
<pre wrap="">On Thu, Jul 02, 2020 at 06:16:49AM -0500, Johnny Utahh wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 2020-07-02 2:18 AM, Geert Stappers wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, Jul 01, 2020 at 10:06:36PM -0500, Johnny Utahh wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">That is indeed not enough for the desired use case.
</pre>
</blockquote>
<pre wrap="">
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?
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<br>
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:<br>
<br>
<pre style="white-space: pre-wrap; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;"> /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]</pre>
<br>
<blockquote type="cite">
<pre wrap="">The idea is that dnsmasq does go searching for an upstream DNS.</pre>
</blockquote>
<br>
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:<br>
<br>
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."<br>
<br>
2. Does `no-resolv` + `no-poll` effectively implement the feature
described in #1?<br>
<br>
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:<br>
<br>
3.a. How certain are we that this "workaround" completely disables
the upstream searching/connections?<br>
<br>
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)?<br>
<br>
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?<br>
<br>
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"?<br>
<br>
<br>
In any case, I will test this approach and report back what I find.<br>
<br>
~Johnny<br>
<pre style="white-space: pre-wrap; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;"><i>environment:
Ubuntu 20.04
</i><i>dnsmasq 2.80</i></pre>
-- <br>
<i> </i>
<br>
<div class="moz-signature">-- <br>
<i> </i></div>
</body>
</html>