Re: [Dnsmasq-discuss] Dynamic address config?

[Matus UHLAR - fantomas via Dnsmasq-discuss]

On Wed, Nov 23, 2022 at 01:47:27PM +0800, Feng Shao wrote:
> There are a bunch of machines in our lab, and we normally don't have DNS
> records configured for them, only accessing by IP. In order to ssh to them
> with key auth, I have a config in my .ssh/config like
>
> Host *.mylab
>   User root
>   IdentityFile ~/.ssh/id_rsa.work
>
> and I have some "address=/123.123.123.123.mylab/123.123.123.123" line in
> dnsmasq.conf. The problem here is I need to add an entry whenever a new IP
> comes.



On Wed, Nov 23, 2022 at 5:28 PM Geert Stappers via Dnsmasq-discuss <
dnsmasq-discuss@lists.thekelleys.org.uk> wrote:

So share with us a more representive sample set of such entries.


On 24.11.22 10:10, Feng Shao wrote:

In dnsmasq.conf, I have lines like:
address=/123.123.123.123.mylab/123.123.123.123
address=/123.123.123.12 4.mylab/123.123.123.12
4
address=/123.123.123.12 5.mylab/123.123.123.12
5
address=/123.123.123.12 6.mylab/123.123.123.12
6



The requirement is I want to ssh any host in my lab without password, I am
open to any other solution.


configuring /etc/hosts and thus providing DNS for those hosts is easier 
than configuring those hosts in dnsmasq configuration.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
- Have you got anything without Spam in it?
- Well, there's Spam egg sausage and Spam, that's not got much Spam in it.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq mishandles some cases when bad dns response packet is received

[Petr Menšík]

Should we think about an option, let's say strict-dns, which would 
toggle additional checks on incoming packets? Like ensuring the packet 
is not longer than expected. New extensions have been added to EDNS 
pseudosection, I doubt that would change anytime soon. It may filter out 
also not matching class in responses, when such class were not used in 
the question. Though that would require explicit remembering of class, 
which is not stored now. Class is used only as part of hash in question, 
so checking class in answer and additional section is not possible now.


While I agree clients should be fixed too, network DNS cache is often 
the most prominent place to add checks. We support blocking lists. We 
might allow also some additional checks. Because more and more devices 
lacks updates after few years of service. At least some checks possible 
would be great option.


I don't think dnsmasq fully qualifies as this proxy. It has even EDNS 
support and is usually caching.


I agree the resolver must accept any query and class combination and 
deliver a response for it. But I am not sure whether resolver must 
deliver response with a different class from the original query. I doubt 
that is mandatory by any RFC. I am not sure this is meant by


https://www.rfc-editor.org/rfc/rfc5625.html#section-4.3

Cheers,
Petr

On 11/23/22 23:22, Simon Kelley wrote:



On 23/11/2022 02:56, zhangjiangyu via Dnsmasq-discuss wrote:

Hi,

On 23/11/2022 07:21, Simon via Dnsmasq-discuss wrote:


The main argument for this seems to be a security one: the client may
not handle a malformed packet, and a suitably crafted malformed packet
may compromise the client with a buffer overflow or similar. If the
client is sending all requests via dnsmasq, then dnsmasq should detect
and eliminate malformed packets from upstream rather than sending them
to the client as this protects the client from compromise.

If we have a client which is vulnerable to malformed packets then the
solution is to fix the client, not put it behind dnsmasq. Putting the
client behind dnsmasq and relying on dnsmasq to intercept malformed
packets is not fix since and attacker may be able to send malformed
packets direct to the client anyway or the configuration may change 
such

that the client talks directly to other servers which the attacker may
have control over. Using dnsmasq to filter malformed packets from the
client is at best fragile and at worst doesn't work. It also transfers
the responsibility to handle untrusted data from the client to dnsmasq,
which is the wrong approach.

Dnsmasq has to accept malformed packets from the internet without
crashing or being compromised, and, as far as anyone knows, it does.
Because of the fairly unique architecture of dnsmasq, altering it to
only return known correctly formed packets is a large change which adds
to the code footprint, increases that chance that something which is in
fact correct but encodes DNS data which dnsmasq doesn't understand will
be rejected by mistake, and can't guarantee to catch all malformed
packets anyway.

I can see the argument for flagging packets which dnsmasq detects are
malformed as part of it's code to extract data for caching, but I don't
think attempting to detect all malformed packets is required. the only
reason to do that is to protect vulnerable clients, and that problem is
fixed by fixing the clients.



Ok, Now I understand that the fairly unique architecture of dnsmasq 
cannot verify all malformed packets. But I think there should be a 
basic detection of the packets. sure, dnsmasq does not need to judge 
the legality of each record resource data.


|like this basic record structure:
|    1  1  1  1  1  1
|  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
|    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|    |   |
|    /   /
|    /  NAME /
|    |   |
|    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|    |  TYPE |
|    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|    | CLASS |
|    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|    |  TTL  |
|    |   |
|    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|    |   RDLENGTH    |
|    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
|    / RDATA /
|    /   /
|    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The structure of the record is stationary, and the rfc stipulates 
that the value of the class has a certain scope and meaning, so the 
clear regulation of the dns rfc should be checked and necessary. But 
for the

Re: [Dnsmasq-discuss] Dynamic address config?

[Geert Stappers via Dnsmasq-discuss]

On Thu, Nov 24, 2022 at 08:47:28AM +0100, Matus UHLAR - fantomas wrote:
> On 24.11.22 10:10, Feng Shao wrote:
> > On Wed, Nov 23, 2022 at 5:28 PM Geert Stappers wrote:
> > > On Wed, Nov 23, 2022 at 01:47:27PM +0800, Feng Shao wrote:
> > > > There are a bunch of machines in our lab, and we normally don't have DNS
> > > > records configured for them, only accessing by IP. In order to ssh to 
> > > > them
> > > > with key auth, I have a config in my .ssh/config like
> > > >
> > > > Host *.mylab
> > > >   User root
> > > >   IdentityFile ~/.ssh/id_rsa.work
> > > >
> > > > and I have some "address=/123.123.123.123.mylab/123.123.123.123" line in
> > > > dnsmasq.conf. The problem here is I need to add an entry whenever a new 
> > > > IP
> > > > comes.
> > >
> > > So share with us a more representive sample set of such entries.
> > >
> > In dnsmasq.conf, I have lines like:
> > address=/123.123.123.123.mylab/123.123.123.123
> > address=/123.123.123.124.mylab/123.123.123.124
> > address=/123.123.123.125.mylab/123.123.123.125
> > address=/123.123.123.126.mylab/123.123.123.126

Strange hostnames.  Consider `nodeNNN.mylab` like

  address=/node123.mylab/123.123.123.123
  address=/node124.mylab/123.123.123.124
  address=/node125.mylab/123.123.123.125
  address=/node126.mylab/123.123.123.126 [1]


> > } } Can this configuration be dynamically? For example,
> > } } "address=/*.mylab/somecmd %1", where "somecmd" is a external command 
> > and %1
> > } } will be replaced by the name in A/ request. So that for any DNS 
> > request
> > } } to *.mylab, dnsmasq invoke this external command and pass the name as
> > } } argument, the output of external command, which will be interpreted as
> > } } IPv4/IPv6 addr then responsed to client?
> > } 
> > } Advice:  Use an open question to start a discussion.
> > } 
> > 
> > The requirement is I want to ssh any host in my lab without password, I am
> > open to any other solution.
>
> configuring /etc/hosts and thus providing DNS for those hosts is easier than
> configuring those hosts in dnsmasq configuration.
>

Yes, that could work.  But for an untold reason[2] there was request
for "dynamically" or a feature request/advice.  As far as I known
nothing like such exists in dnsmasq. Here an idea, just an idea:

  server=/mylab/127.0.0.1#5354

And at port 5354 on localhost is an "Domain Name Server" that does
the requested dynamic address config / dynamic address translation.


Groeten
Geert Stappers

[1] Use 192.0.2.0/24 for documentation (
https://en.wikipedia.org/wiki/Reserved_IP_addresses )
[2] Maybe a XY-problem, explained at https://xyproblem.info/
-- 
Silence is hard to parse

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] [PATCH] Make use-stale-cache configurable

[Dominik Derigs]

Hey Simon,

We observed a few cache oddities with the current release-
candidate of dnsmasq and have been able to pin this down to the
use of the new use-stale-cache option. The issue happens with
cached content being served when the actual domain data has moved
on. This is, of course, unavoidable with this option, however, it
made me wanting a way to configure "serve stale data but only if
it is not too old". This is added by this patch adding an
optional argument:

--use-stale-cache[=]

In fact RFC 8767 "Serving Stale Data to Improve DNS Resiliency"
even states that

> The maximum stale timer should be configurable

The RFC suggests a "value is between 1 and 3 days" and later
states that "Shorter values, even less than a day, can
effectively handle the vast majority of outages." Hence, my patch
also changes the current (so far, unreleased) behavior from
serving expired content forever to a default value of one day.
This is freely configurable (I will set it down to one hour on
our systems) and can even be made serving forever, just as before
by explicitly setting the optional value to 0.

Best,
Dominik


Internal tracking is happening here:
https://github.com/pi-hole/dnsmasq/pull/11
From de4c49ff02b1cf5e553f185942ccc75c51c763bc Mon Sep 17 00:00:00 2001
From: DL6ER 
Date: Thu, 24 Nov 2022 19:15:04 +0100
Subject: [PATCH] Make use-stale-cache configurable. The default is to stop
 serving from cache once records are expired by more than a day.

---
 man/dnsmasq.8 |  5 +++--
 src/cache.c   | 16 
 src/config.h  |  1 +
 src/dnsmasq.h |  6 +++---
 src/option.c  | 22 --
 5 files changed, 39 insertions(+), 11 deletions(-)

diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index 53bccb8..2495ed1 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -828,11 +828,12 @@ name on successive queries, for load-balancing. This turns off that
 behaviour, so that the records are always returned in the order
 that they are received from upstream.
 .TP
-.B --use-stale-cache
+.B --use-stale-cache[=]
 When set, if a DNS name exists in the cache, but its time-to-live has expired, dnsmasq will return the data anyway. (It attempts to refresh the
 data with an upstream query after returning the stale data.) This can improve speed and reliability. It comes at the expense
 of sometimes returning out-of-date data and less efficient cache utilisation, since old data cannot be flushed when its TTL expires, so the cache becomes
-strictly least-recently-used.
+mostly least-recently-used. To mitigate issues caused by massively outdated DNS replies, the maximum overaging of cached records can be specified in seconds
+(defaulting to not serve anything older than one day). Setting the TTL excess time to zero will serve stale cache data regardless how long it has expired.
 .TP
 .B \-0, --dns-forward-max=
 Set the maximum number of concurrent DNS queries. The default value is
diff --git a/src/cache.c b/src/cache.c
index 119cf9f..b3c38c0 100644
--- a/src/cache.c
+++ b/src/cache.c
@@ -380,9 +380,17 @@ static int is_outdated_cname_pointer(struct crec *crecp)
 
 static int is_expired(time_t now, struct crec *crecp)
 {
-  /* Don't dump expired entries if we're using them, cache becomes strictly LRU in that case.
- Never use expired DS or DNSKEY entries. */
-  if (option_bool(OPT_STALE_CACHE) && !(crecp->flags & (F_DS | F_DNSKEY)))
+  /* Don't dump expired entries if they are within the accepted timeout range.
+ The cache becomes approx. LRU. Never use expired DS or DNSKEY entries.
+ Possible values for daemon->cache_max_expiry:
+  -1  == serve cached content regardless how long ago it expired
+   0  == the option is disabled, expired content isn't served
+   == serve cached content only if it expire less than  seconds
+ ago (where n is a positive integer) */
+  if (daemon->cache_max_expiry != 0 &&
+  (daemon->cache_max_expiry == -1 ||
+   difftime(now, crecp->ttd) < daemon->cache_max_expiry) &&
+  !(crecp->flags & (F_DS | F_DNSKEY)))
 return 0;
 
   if (crecp->flags & F_IMMORTAL)
@@ -1762,7 +1770,7 @@ void dump_cache(time_t now)
 	daemon->cachesize, daemon->metrics[METRIC_DNS_CACHE_LIVE_FREED], daemon->metrics[METRIC_DNS_CACHE_INSERTED]);
   my_syslog(LOG_INFO, _("queries forwarded %u, queries answered locally %u"), 
 	daemon->metrics[METRIC_DNS_QUERIES_FORWARDED], daemon->metrics[METRIC_DNS_LOCAL_ANSWERED]);
-  if (option_bool(OPT_STALE_CACHE))
+  if (daemon->cache_max_expiry != 0)
 my_syslog(LOG_INFO, _("queries answered from stale cache %u"), daemon->metrics[METRIC_DNS_STALE_ANSWERED]);
 #ifdef HAVE_AUTH
   my_syslog(LOG_INFO, _("queries for authoritative zones %u"), daemon->metrics[METRIC_DNS_AUTH_ANSWERED]);
diff --git a/src/config.h b/src/config.h
index df1d985..1e7b30f 100644
--- a/src/config.h
+++ b/src/config.h
@@ -60,6 +60,7 @@
 #define LOOP_TEST_DOMAIN "test" /* domain for loop testing, "test" is reserved by RFC 2606 and won't therefore clash */
 #defi