Re: [Dnsmasq-discuss] HA Cluster - IPv6 router adv lifetime of 0
Hi William, I think priority is correct here. Well observed! On 10/2/21 13:55, William Edwards wrote: > Jochen Demmer via Dnsmasq-discuss schreef op 2021-10-02 10:28: >> Hi, >> >> I've been trying to develop my own kind of firewall solution named >> nftwall which uses nftables as packet filter and is being managed >> centrally by Ansible - no webGUI. >> >> My first attempt was to use dnsmasq but then I found out of this >> obstacle. I've been thinking about switching to KEA + radvd but >> actually I would like to keep using dnsmasq. >> I manage my VRRP IPs with keepalived. There are small scripts for an >> event of a primary - secondary change. Especially in an event of >> controlled switch of primary - secondary I would like the primary >> dnsmasq to send a lifetime of 0 in the router advertisement package. >> That way the clients know that this router shall not be used any more. > > No experience with RAs so far, but isn't that what the priority field > is for? Correct! ra-param already supports setting lifetime to 0, which should work for your use case even without code change. # server is not primary ra-param=eth0,low,0,0 # should announce prefix without clients routing via it. # server is primary dhcp-authoritative ra-param=eth0,high,0,600 # Use on elected primary router, make this route preferred. Isn't switching those parameters on election change all you would need? > >> >> Please confirm my findings that this is currently not possible with >> dnsmasq. If so please accept my feature request to implement that. >> >> Regards >> Jochen Demmer -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] HA Cluster - IPv6 router adv lifetime of 0
Hello Jochen, I think it would need to be more complex change I think. On 10/4/21 13:04, Jochen Demmer via Dnsmasq-discuss wrote: > Hi, > > I'm sorry for being unclear. > There is a cluster of two firewalls (active passive). > The clients use the link local address as their default gateway. I > want to initialize a manual switch: > The primary becomes secondary, the old secondary becomes primary. I think dnsmasq does not implement DHCP failover in any sort of ways. It expects it is the only one DHCP server and maintains just its own lease database, right? Wouldn't more complex support be required? It seems to me such scenario might be better suited for enterprise grade DHCP implementations, such as ISC Kea. It seems to me dnsmasq targets less resourceful machines without router duplication environment. > > As the router advertisements for the clients contain a default route I > would like to make adjustments. The default route is being published > by providing clients with the link-local address of the firewall > (whichever is primary). > When there is such a controlled switch I would like to let the old > primary send a router advertisement package to the clients with a > lifetime of 0. This will signal the clients to not use this device any > more. > Next the new primary (formerly secondary) will start to advertise > itself as the new default router. I think it should also switch dhcp-authoritative flag. It is not only about routes, but it should stop managing IP addresses, when different instance is primary server, right? I think dnsmasq may receive signal to switch state over d-bus for example. Then it should deactivate its own dhcp-range and start sending lifetime 0 to indicate it is no longer the preferred one. It would be much easier if dnsmasq would restart on such change and configuration would change, correct? > > In this event I would like to have a trigger so that the designated > primary sends such a 0 lifetime package. If I'm not mistaken such a > feature is missing. Dnsmasq seems to be able to send 0 lifetime. It does so in cases when address range disappears on the router. I admit it is too radical to remove address range to send it, if there might be other server better suited for it. We could add dhcp-range=...,ra-inactive, which would send lifetime==0 announcement for the duration of a lease, then stop it. Similar to src/dhcp6.c:793 handling of removed addresses. May that work? It would require dnsmasq restart after configuration change. > > AFAIK this is how pfSense handles such setups. They do use CARP but at > that point it doesn't differ from a VRRP scenario. > > Regards > Jochen > > Am Samstag, Oktober 02, 2021 13:17 CEST, schrieb Geert Stappers via > Dnsmasq-discuss : > >> On Sat, Oct 02, 2021 at 10:28:16AM +0200, Jochen Demmer via >> Dnsmasq-discuss wrote: >> > >> > Hi, >> >> Welcome, >> >> >> > I've been trying to develop my own kind of firewall solution named >> > nftwall which uses nftables as packet filter and is being managed >> > centrally by Ansible - no webGUI. >> > >> > My first attempt was to use dnsmasq but then I found out of this >> > obstacle. I've been thinking about switching to KEA + radvd but >> actually >> > I would like to keep using dnsmasq. >> > I manage my VRRP IPs with keepalived. There are small scripts >> > for an event of a primary - secondary change. Especially in an >> > event of controlled switch of primary - secondary I would like the >> > primary dnsmasq to send a lifetime of 0 in the router advertisement >> > package. That way the clients know that this router shall not be used >> > any more. >> >> What? >> >> >> > Please confirm my findings that this is currently not possible with >> > dnsmasq. >> > >> > If so please accept my feature request to implement that. >> >> Patches to this mailinglist do get noticed. >> >> >> >> Groeten >> Geert Stappers >> -- >> 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 mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNS from dhcp-host while client is offline
Hey, On 10/4/21 14:37, Dominik Derigs wrote: > Hey Petr, > > On Mon, 2021-10-04 at 11:45 +0200, Petr Menšík wrote: >> Perhaps a flag could be added to dhcp-range, requesting also >> addition of dhcp-hosts to static dns. > Maybe this flag would better be set on --dhcp-host and --dhcp- > hostsfile if this is used? This would feel more "natural" to me. I wanted to avoid the need to specify it always per host. dhcp-hostsfile would work also. Good idea. It might introduce limitation to used comma character in accepted filenames. But I guess nobody would complain. Or we could test just ",offline" suffix. dhcp-range has already some flags to apply, hence I thought about that first. I admit it is not directly related to mode of hosts. > > Initially, I've myself found this an odd behavior to only serve > only DHCP host names that are known to be "alive". I do see some > value in not serving A records when we know the server is > offline, however, the very same happens on the Internet all the > time: no DNS server I'm aware of checks if an A record is > reachable before giving you the reply. Sure, DNS server should not ping me before responding with my address. However DHCP uses leases, host can acquire or release the lease, giving the server clear idea when it might be available. Nothing similar exist for DNS. I admit fixed leases have no clear disadvantage to register the name all the time. Their address would never be given to anyone else. I think ISC DHCP uses DHCID record, which marks client owner of the lease. Maybe we could implement it also, even when dnsmasq has such information internally known. It might be used to get leased or only statically defined difference from clients, if that information is considered useful. Address records might be defined all the time. > I've seen other systems using dnsmasq (it may or not have been > DD-WRT, no promises!) that created two files from static leases: > A dhcp-hostsfile and an addn-hosts file. Having an option to make > the latter obsolete sounds like a good idea. Sure, if we know it is already desired, we should make it possible. Should be simple enough to implement. > > Best, > Dominik > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Is it possible to use different upstream DNS servers for different interfaces?
Hi, I have two interfaces on my router, one for home and the other for office. I’d like for clients from home and office to use different upstream DNS servers. I know I can use two Dnsmasq instances to achieve that, but that prevents the two types of clients to access each other by host names that they announce to the Dnsmasq DHCP. It seems the “server” option is the one that I should pay attention to, but its interface/IP parameter only specify the source interface/IP to query from. I wonder if it’s something possible with Dnsmasq? If not, is there a workaround? Regards, Glen ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Is it possible to merge host names on two Dnsmasq instances?
Thank you so much for bringing VLAN trunking to my attention. I’ve successfully set it up on the router and the AP, with one Dnsmasq instance to rule them all! It’s a really elegant solution. Regards, Glen > On Oct 2, 2021, at 2:59 PM, Paul Fertser wrote: > > Hi Glen, > >> On Wed, Sep 29, 2021 at 10:16:00AM +0800, Glen Huang wrote: >> it seems impossible for the router to take over guest WiFi’s DHCP, >> since it’s based on AP’s interfaces > > Just make the wired link between your router and the AP trunking, on > the AP bridge main and guest SSIDs to different VLANs, and on the > router serve all the VLANs with a single dnsmasq instance. > > HTH > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fercer...@gmail.com ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] unittests
Hey Geert,
On 10/2/21 14:40, Geert Stappers via Dnsmasq-discuss wrote:
> In-Reply-To: <8a018620-25a7-a292-c951-dd2017d54...@redhat.com>
> On Mon, May 03, 2021 at 12:53:39PM +0200, Petr Menšík wrote:
>> On 4/30/21 12:42 AM, Simon Kelley wrote:
>>> On 14/04/2021 18:35, Petr Menšík wrote:
Hi Simon and other dnsmasq friends,
after some struggling with Makefile support, I am sending my dnsmasq
unit tests. It uses another directory with tests specific code. I moved
some common parts to Makefile.config, in order to be able to reuse them.
Unit tests are under tests directory with own Makefile.
New target make check should work also from top directory. Some checks
would work only from tests directory (make kyua). Current coverage is
rather poor, but I hope can be used as a building block to better tests.
Especially option parsing tests are easy to write. Testing of sending
and receiving packets seems to be difficult, it should be tested by
different kind of test IMHO.
First is attempt to refactor, the second is what evolved into more
complex set of tests.
Original separate commits are still available on github [1].
What do you think?
>>> Well, I applied the patch, and run "make check" and all the tests passed!
>>>
>>> Now I have to understand how to write new tests.
>> Configuration parsing tests are easy, just provide input parameters
>> similar way to existing test and then check expected values are provided.
>>> Would it make sense to consider some changes to the main code to make
>>> the tests easier? I see that die() is a problem. Can we change the code
>>> in die() to do something useful when testing?
>> I have chosen to omit dnsmasq.c code from tests. It contains main()
>> function, cannot be part of test anyway. Sure, some code changes would
>> help with reducing needed repetitions in tests. Especially init code
>> required in tests should be moved out of dnsmasq.c, where it could be
>> called directly from tests. Shared init code must not be static
>> functions of course.
>>
>> die does make sense everywhere where it is a corner case. If we move
>> die() calls to dnsmasq.c, it would be okay. Other files should return
>> indication of fatal error, but not die directly. It would need
>> additional wrappers in dnsmasq.c, but such functions would be more testable.
>>> Also the tests seem to can copies of initialisation code, does it make
>>> sense to abstract the initialisation in main() so that it can be used by
>>> the tests standalone?
>> Yes, it make sense to move parts of initialization to subsystem-specific
>> initialization functions. I would move dns_init() into rfc1035.c,
>> dhcp_init() into dhcp-common.c etc. It should make main source file
>> shorter and it would be more obvious, which subsystems are initialized
>> in which order, whether they depend on anything before it. I think the
>> best practice is to break long functions into several shorter, more
>> readable functions. I think current main() is a great example to break
>> into more smaller functions and move some of them to shareable files.
>> Parts required by current tests are small enough.
>>> I'm thinking of changing the existing main()
>>>
>>> main()
>>> {
>>>
>>> while (1)
>>> events()
>>> }
>>>
>>> into
>>>
>>> main()
>>> {
>>> init();
>>> while (1)
>>> events()
>>> }
>>>
>>> So that init() is available for testing.
>>>
>>>
>>> Cheers,
>>>
>>> Simon.
>>>
PS: sending this message again, because patch #2 were big enough to
require moderator's approval. Compressed it as a workaround.
Cheers,
Petr
1. https://github.com/InfrastructureServices/dnsmasq/tree/unittests
> What was / is the posting from Simon asking something
>
> Would unittest have detect this side-effect of the change?
I doubt unit tests would find that. Unit tests should test some
functions that they work correctly. My unit tests were just attempt to
make *some* tests, but just very basic. It was intended more to check
options parsing correctness and obvious breakages in these parts. There
is no function in dnsmasq, where you put "fake" incoming packet and it
would respond reply would look like this.
Unit tests usually require code like Lego, which uses parts of code to
prepare reply to a request. Then virtual responder can be made. Many
parts of dnsmasq are not ready for that. It provides no strong library,
which can replicate internal data processing. Response to a dns packet
is somehow hard to validate just from the code. cmocka library is a good
one for unit tests.
It would be beneficial to have also behavior tests. Which would start
dnsmasq with some parameters and use standard tools like dhclient or dig
to make a request. Then verify response received is correct. That is
what I attempted at separate tests [2], but have not worked on it
recently. It would be much easier to test logic handling
Re: [Dnsmasq-discuss] DNS from dhcp-host while client is offline
Hi Michael, On 10/5/21 14:43, Michael wrote: > On 10/4/21 05:37, Dominik Derigs wrote: >> Hey Petr, >> >> On Mon, 2021-10-04 at 11:45 +0200, Petr Menšík wrote: >>> Perhaps a flag could be added to dhcp-range, requesting also >>> addition of dhcp-hosts to static dns. >> Maybe this flag would better be set on --dhcp-host and --dhcp- >> hostsfile if this is used? This would feel more "natural" to me. >> >> Initially, I've myself found this an odd behavior to only serve >> only DHCP host names that are known to be "alive". I do see some >> value in not serving A records when we know the server is >> offline, however, the very same happens on the Internet all the >> time: no DNS server I'm aware of checks if an A record is >> reachable before giving you the reply. >> >> I've seen other systems using dnsmasq (it may or not have been >> DD-WRT, no promises!) that created two files from static leases: >> A dhcp-hostsfile and an addn-hosts file. Having an option to make >> the latter obsolete sounds like a good idea. >> > > Maybe I am misunderstanding the issue, but dnsmasq already give the > ability that is being asked for I believe. > > > If you want a static DNS entry, add the entry to /etc/hosts or > -addn-hosts= > > If you want a DHCP lease that always hands out the same ip address but > is only valid during the lease, create a dhcp-host entry that includes > the IP & hostname > > If you want a DHCP lease can always be looked up via DNS, add it to > /etc/hosts or -addn-hosts and the dhcp-host entry contains the hostname > > > > Michael Sure, we understand it is already possible. Our point is it may have valid uses, but requires duplication of hostname and IP definition in multiple files. It cannot be done just from single source file without helper tool generating configuration data copy. It is not possible to have static hosts IP definition AND mapping of MAC address in just single place. It can be written in dhcp-host, /etc/ethers or /etc/hosts. But it has to be always two places. It could be useful to have just single line for each host and still able to fixed IP. It requires additional tooling, when relatively simple change may allow it directly without additional scripts. Just that. Cheers, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNS from dhcp-host while client is offline
Hey Michael, On Tue, 2021-10-05 at 05:43 -0700, Michael wrote: > Maybe I am misunderstanding the issue, but dnsmasq already give > the ability that is being asked for I believe. if you go back one mail earlier than my last mail, you'd see that the we're discussing specifically to not need two independent files but serve DHCP and DNS from a single source of knowledge. Best, Dominik ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNS from dhcp-host while client is offline
On 10/5/2021 2:43 PM, Michael wrote: On 10/4/21 05:37, Dominik Derigs wrote: Hey Petr, On Mon, 2021-10-04 at 11:45 +0200, Petr Menšík wrote: Perhaps a flag could be added to dhcp-range, requesting also addition of dhcp-hosts to static dns. Maybe this flag would better be set on --dhcp-host and --dhcp- hostsfile if this is used? This would feel more "natural" to me. Initially, I've myself found this an odd behavior to only serve only DHCP host names that are known to be "alive". I do see some value in not serving A records when we know the server is offline, however, the very same happens on the Internet all the time: no DNS server I'm aware of checks if an A record is reachable before giving you the reply. I've seen other systems using dnsmasq (it may or not have been DD-WRT, no promises!) that created two files from static leases: A dhcp-hostsfile and an addn-hosts file. Having an option to make the latter obsolete sounds like a good idea. Maybe I am misunderstanding the issue, but dnsmasq already give the ability that is being asked for I believe. If you want a static DNS entry, add the entry to /etc/hosts or -addn-hosts= If you want a DHCP lease that always hands out the same ip address but is only valid during the lease, create a dhcp-host entry that includes the IP & hostname If you want a DHCP lease can always be looked up via DNS, add it to /etc/hosts or -addn-hosts and the dhcp-host entry contains the hostname The idea here is to let Dnsmasq do that programatically instead of having to do it manually. -- John Doe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNS from dhcp-host while client is offline
On 10/4/21 05:37, Dominik Derigs wrote: Hey Petr, On Mon, 2021-10-04 at 11:45 +0200, Petr Menšík wrote: Perhaps a flag could be added to dhcp-range, requesting also addition of dhcp-hosts to static dns. Maybe this flag would better be set on --dhcp-host and --dhcp- hostsfile if this is used? This would feel more "natural" to me. Initially, I've myself found this an odd behavior to only serve only DHCP host names that are known to be "alive". I do see some value in not serving A records when we know the server is offline, however, the very same happens on the Internet all the time: no DNS server I'm aware of checks if an A record is reachable before giving you the reply. I've seen other systems using dnsmasq (it may or not have been DD-WRT, no promises!) that created two files from static leases: A dhcp-hostsfile and an addn-hosts file. Having an option to make the latter obsolete sounds like a good idea. Maybe I am misunderstanding the issue, but dnsmasq already give the ability that is being asked for I believe. If you want a static DNS entry, add the entry to /etc/hosts or -addn-hosts= If you want a DHCP lease that always hands out the same ip address but is only valid during the lease, create a dhcp-host entry that includes the IP & hostname If you want a DHCP lease can always be looked up via DNS, add it to /etc/hosts or -addn-hosts and the dhcp-host entry contains the hostname Michael ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] [PATCH] localhost-service support
Hi Simon,
We have chosen to listen by default just on localhost interface, like
default configuration of BIND9 and Unbound has. However I have received
multiple bug reports since that. People do not reconfigure defaults,
because that was not required before. They stumble often on the default.
It would be nice, if default configuration could be ignored the same way
for local-service. But local-service default conflicts with
systemd-resolved for example. Therefore I made a change and propose
listening on just localhost. But behaving similar way to local-service.
The second patch adds simpler way to skip reading default configuration.
Just handle --conf-file= as skipping config file reading. It were just
ignored until now.
What would you think of it?
Cheers,
Petr
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From 9ce66ed5d42ca66d09ed645ea37cda41161c147b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?=
Date: Tue, 5 Oct 2021 13:46:51 +0200
Subject: [PATCH 1/2] Introduce new locahost-service option
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Similar to local-service, but more strict. Listen only on localhost
unless other interface is specified. Has no effect when interface is
done explicitly. I had multiple bugs fillen on Fedora, because I have
changed default configuration to:
interface=lo
bind-interfaces
People just adding configuration parts to /etc/dnsmasq.d or appending to
existing configuration often fail to see some defaults are already there.
Give them auto-ignored configuration as smart default.
Signed-off-by: Petr Menšík
---
man/dnsmasq.8 | 4
src/dnsmasq.c | 2 ++
src/dnsmasq.h | 3 ++-
src/option.c | 32
4 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index 457667a..6987439 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -257,6 +257,10 @@ only has effect if there are no \fB--interface\fP, \fB--except-interface\fP,
\fB--listen-address\fP or \fB--auth-server\fP options. It is intended to be set as
a default on installation, to allow unconfigured installations to be
useful but also safe from being used for DNS amplification attacks.
+.TP
+.B --localhost-service
+Listen to DNS queries only on localhost interface. Has no effect in similar cases to
+\fB--local-service\fP.
.TP
.B \-2, --no-dhcp-interface=
Do not provide DHCP or TFTP on the specified interface, but do provide DNS service.
diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index cfbbbf1..46d8b74 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -872,6 +872,8 @@ int main (int argc, char **argv)
if (option_bool(OPT_LOCAL_SERVICE))
my_syslog(LOG_INFO, _("DNS service limited to local subnets"));
+ else if (option_bool(OPT_LOCALHOST_SERVICE))
+ my_syslog(LOG_INFO, _("DNS service limited to localhost"));
}
my_syslog(LOG_INFO, _("compile time options: %s"), compile_opts);
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index b2f0b57..f3af87b 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -275,7 +275,8 @@ struct event_desc {
#define OPT_UMBRELLA_DEVID 64
#define OPT_CMARK_ALST_EN 65
#define OPT_QUIET_TFTP 66
-#define OPT_LAST 67
+#define OPT_LOCALHOST_SERVICE 67
+#define OPT_LAST 68
#define OPTION_BITS (sizeof(unsigned int)*8)
#define OPTION_SIZE ( (OPT_LAST/OPTION_BITS)+((OPT_LAST%OPTION_BITS)!=0) )
diff --git a/src/option.c b/src/option.c
index 485f367..8ad5338 100644
--- a/src/option.c
+++ b/src/option.c
@@ -175,6 +175,7 @@ struct myoption {
#define LOPT_CMARK_ALST366
#define LOPT_QUIET_TFTP367
#define LOPT_NFTSET368
+#define LOPT_LOCALHOST_SVC 369
#ifdef HAVE_GETOPT_LONG
static const struct option opts[] =
@@ -207,6 +208,7 @@ static const struct myoption opts[] =
{ "interface", 1, 0, 'i' },
{ "listen-address", 1, 0, 'a' },
{ "local-service", 0, 0, LOPT_LOCAL_SERVICE },
+{ "localhost-service", 0, 0, LOPT_LOCALHOST_SVC },
{ "bogus-priv", 0, 0, 'b' },
{ "bogus-nxdomain", 1, 0, 'B' },
{ "ignore-address", 1, 0, LOPT_IGNORE_ADDR },
@@ -532,6 +534,7 @@ static struct {
{ LOPT_QUIET_RA, OPT_QUIET_RA, NULL, gettext_noop("Do not log RA."), NULL },
{ LOPT_LOG_DEBUG, OPT_LOG_DEBUG, NULL, gettext_noop("Log debugging information."), NULL },
{ LOPT_LOCAL_SERVICE, OPT_LOCAL_SERVICE, NULL, gettext_noop("Accept queries only from directly-connected networks."), NULL },
+ { LOPT_LOCALHOST_SVC, OPT_LOCALHOST_SERVICE, NULL, gettext_noop("Listen for queries on localhost interface only."), NULL },
{ LOPT_LOOP_DETECT, OPT_LOOP_DETECT, NULL, gettext_noop("Detect and remove DNS forwarding loops."), NULL },
{ LOPT_IGNORE_ADDR, ARG_DUP, "", gettext_noop("Ignore DNS responses containing ipaddr."), NULL },
{ LOPT_DHCPTTL, ARG_ONE, "", gettext_noop("Set TTL in DNS responses with
Re: [Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
I could not find any relevant difference between nuc-efi.pcapng and qemu-efi.pcapng responses. They seem very similar. Yet qemu continues with TFTP download and next step. Nuc does not react anyhow to boot offer. It seems to not download or start snponly.efi. It seems to me the answer lies only on its boot rom firmware. I just expect both used matching configuration and dnsmasq version. >From dnsmasq side, answer to DHCP discover and request contains expected value in expected format. Critical is any output of NUC when it receives the offer. Does it fail with any error code? Does it print any error? At least screenshot would be useful. It seems to me the problem is somewhere in its PXE implementation, which we cannot solve in dnsmasq. Because it even does not try to download and execute snponly.efi, even iPXE build with debug logs (which I am not sure how to enable btw) would not help. What kind machine it is? Does it have the latest bios firmware available? Would this machine boot at least snponly.efi if pxe-service were commented out? It seems similar to previous intel_nuc_efi_with_ltsp-pxeservice.pcapng file requests, but it does use proxyDHCP requests like the old one. How changed dnsmasq configuration to make this change? How does dnsmasq.conf look like for it? Option 43 suboption PXE discovery control (6) is different now. It seems not well received by PXE firmware this time. Used config file of dnsmasq is not attached this time, I can only guess. HW address is different, not sure how different is used machine. Was it this machine, which returned PXE-E21: Remote boot cancelled.? Returned control to LoadFile control seems suspicious. May it require non-efi image instead? If you can reach support for this machine, I think it might be reported to them. Especially about how PXE menu can specify Local Boot? I am afraid I don't know how to help now. If one machine can boot with the same setup that another cannot, it is up to you to find commonly working configuration. On 9/30/21 12:47, Shrenik Bhura wrote: > > 1. seems to have wrong pcap file or it does not use configuration attached > > in linked archive. It seems it offers > menu items from 2. archive with custom pxe-services. > > Apologies, there was definitely some mistake. > > We have applied the patch and tried with and without dhcp-no-override > but it still fails to boot. Herein are the pcap and the logs for this > case. > https://drive.google.com/file/d/1-GvsId99FC8f8B2I0YaTVuje5385u4LC/view?usp=sharing > > Additionally, also included is the qemu pcap wherein it does boot > successfully. > > On Wed, 29 Sept 2021 at 20:29, Petr Menšík wrote: > > It is somehow hard to guess described results for each > configuration (1. 2. 3.). It is unclear to me, what you saw for > each variant printed by the computer. > > 1. seems to have wrong pcap file or it does not use configuration > attached in linked archive. It seems it offers menu items from 2. > archive with custom pxe-services. > > Option 43 Suboption: (9) PXE boot menu > Length: 41 > boot menu: > 8000155058454c494e555820285838362d36345f4546492980010e5058454c494e555820… > Type: Unknown (32768) > Length: 21 > Description: PXELINUX (X86-64_EFI) > Type: Unknown (32769) > Length: 14 > Description: PXELINUX (EFI) > > Above is not present in config file presented for it, but in 2. > Are you sure you have killed dnsmasq and started it again? > > I think it might be difference between pxe-service served file > chosen via menuboot. I have noticed there are two way to specify > file to boot in DHCP for IPv4. One is in fixed header and first > try chosen from menu is in that. pxe-service options makes it to > request direct query to DHCP server, marked proxyDHCP in > wireshark. This proxy ACK is followed by TFTP. > > I used filter in wireshark: "dhcp or (!tftp.destination_file && tftp)" > > However following DHCP offers boot file path ONLY in option 67 > value. Fixed header boot file is all zeroed. It seems to me this > is the part the snponly.efi firmware does not understand. It does > not try to use path in option, but may insist only on file. Since > option #52 overload is not in packet, I guess dnsmasq should have > used mess->file for path and not option 67. But rules of > rfc2131.c:2476 are simple. If client have requested option 67, it > should handle it as option 67. I guess it is bug in snponly.efi. > Either it should not include option 67 between requested options > or it should actually handle the option. Dnsmasq would offer boot > path in both cases. > > Interesting enough, dnsmasq is inconsistent with itself. It > behaves a bit different way in PXE proxy mode, where file header > part is always used. In normal mode unless --dhcp-no-override is > used, option is used if requested.
[Dnsmasq-discuss] [PATCH] --local is broken
Hey Simon,
Since commit "Fix --address=/#/.. which was lost in 2.86"
(26bbf5a314d833beaf0f147d24409969f05f3dba) --local being a
synonym for --server is broken as --local became a synonym for --
address.
The attached patch fixes this.
This was reported on the Pi-hole forums:
> I have local=/fritz.box/192.168.0.1 in my /etc/dnsmasq.d/02-
> localdns.conf config file. This worked fine until upgrading
> pihole last night. Now all queries to FQDNs such as google.com
> get responded with google.com.fritz.box and ip address
> 192.186.0.1.
>
> Changing the line to server=/fritz.box/192.168.0.1 restores the
> previous handling. However, according to the dnsmasq manpage "-
> -local is a synonym for --server to make configuration files
> clearer in this case."
Best,
Dominik
From 57461836c48deda17c468ae3c2033d0cc3dc34ec Mon Sep 17 00:00:00 2001
From: DL6ER
Date: Tue, 5 Oct 2021 10:15:21 +0200
Subject: [PATCH] --local should behave as --server, not as --address according
to the man page
Signed-off-by: DL6ER
---
src/option.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/option.c b/src/option.c
index 5307f01..dc1efd3 100644
--- a/src/option.c
+++ b/src/option.c
@@ -2758,7 +2758,7 @@ static int one_opt(int option, char *arg, char *errstr, char *gen_err, int comma
if (!arg || !*arg)
flags = SERV_LITERAL_ADDRESS;
- else if (option != 'S')
+ else if (option == 'A')
{
/* # as literal address means return zero address for 4 and 6 */
if (strcmp(arg, "#") == 0)
@@ -2790,7 +2790,7 @@ static int one_opt(int option, char *arg, char *errstr, char *gen_err, int comma
flags &= ~SERV_FOR_NODOTS;
/* address=/#/ matches the same as without domain */
- if (option != 'S' && domain[0] == '#' && domain[1] == 0)
+ if (option == 'A' && domain[0] == '#' && domain[1] == 0)
domain[0] = 0;
}
--
2.25.1
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] unittests
On 10/5/2021 5:13 PM, Petr Menšík wrote:
Hey Geert,
On 10/2/21 14:40, Geert Stappers via Dnsmasq-discuss wrote:
In-Reply-To: <8a018620-25a7-a292-c951-dd2017d54...@redhat.com>
On Mon, May 03, 2021 at 12:53:39PM +0200, Petr Menšík wrote:
On 4/30/21 12:42 AM, Simon Kelley wrote:
On 14/04/2021 18:35, Petr Menšík wrote:
Hi Simon and other dnsmasq friends,
after some struggling with Makefile support, I am sending my dnsmasq
unit tests. It uses another directory with tests specific code. I moved
some common parts to Makefile.config, in order to be able to reuse them.
Unit tests are under tests directory with own Makefile.
New target make check should work also from top directory. Some checks
would work only from tests directory (make kyua). Current coverage is
rather poor, but I hope can be used as a building block to better tests.
Especially option parsing tests are easy to write. Testing of sending
and receiving packets seems to be difficult, it should be tested by
different kind of test IMHO.
First is attempt to refactor, the second is what evolved into more
complex set of tests.
Original separate commits are still available on github [1].
What do you think?
Well, I applied the patch, and run "make check" and all the tests passed!
Now I have to understand how to write new tests.
Configuration parsing tests are easy, just provide input parameters
similar way to existing test and then check expected values are provided.
Would it make sense to consider some changes to the main code to make
the tests easier? I see that die() is a problem. Can we change the code
in die() to do something useful when testing?
I have chosen to omit dnsmasq.c code from tests. It contains main()
function, cannot be part of test anyway. Sure, some code changes would
help with reducing needed repetitions in tests. Especially init code
required in tests should be moved out of dnsmasq.c, where it could be
called directly from tests. Shared init code must not be static
functions of course.
die does make sense everywhere where it is a corner case. If we move
die() calls to dnsmasq.c, it would be okay. Other files should return
indication of fatal error, but not die directly. It would need
additional wrappers in dnsmasq.c, but such functions would be more testable.
Also the tests seem to can copies of initialisation code, does it make
sense to abstract the initialisation in main() so that it can be used by
the tests standalone?
Yes, it make sense to move parts of initialization to subsystem-specific
initialization functions. I would move dns_init() into rfc1035.c,
dhcp_init() into dhcp-common.c etc. It should make main source file
shorter and it would be more obvious, which subsystems are initialized
in which order, whether they depend on anything before it. I think the
best practice is to break long functions into several shorter, more
readable functions. I think current main() is a great example to break
into more smaller functions and move some of them to shareable files.
Parts required by current tests are small enough.
I'm thinking of changing the existing main()
main()
{
while (1)
events()
}
into
main()
{
init();
while (1)
events()
}
So that init() is available for testing.
Cheers,
Simon.
PS: sending this message again, because patch #2 were big enough to
require moderator's approval. Compressed it as a workaround.
Cheers,
Petr
1. https://github.com/InfrastructureServices/dnsmasq/tree/unittests
What was / is the posting from Simon asking something
Would unittest have detect this side-effect of the change?
I doubt unit tests would find that. Unit tests should test some
functions that they work correctly. My unit tests were just attempt to
make *some* tests, but just very basic. It was intended more to check
options parsing correctness and obvious breakages in these parts. There
is no function in dnsmasq, where you put "fake" incoming packet and it
would respond reply would look like this.
Unit tests usually require code like Lego, which uses parts of code to
prepare reply to a request. Then virtual responder can be made. Many
parts of dnsmasq are not ready for that. It provides no strong library,
which can replicate internal data processing. Response to a dns packet
is somehow hard to validate just from the code. cmocka library is a good
one for unit tests.
It would be beneficial to have also behavior tests. Which would start
dnsmasq with some parameters and use standard tools like dhclient or dig
Those tools are not standards, for instance on OpenWRT.
--
John Doe
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] unittests
On 6/10/21 09:11, Petr Menšík wrote: On 10/5/21 20:28, john doe wrote: Those tools are not standards, for instance on OpenWRT. dig is quite standard thing for troubleshooting DNS. If it is not available for OpenWRT, it should be fixed. I am bind9 maintainer too, it might get surprising to me. For anything DNS related I would not write tests without dig. dig is available on OpenWRT in the bind-dig package. It is not installed by default but it is available, much like in regular linux distributions. Hamish ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] unittests
Hey Petr and others, On Tue, 2021-10-05 at 17:13 +0200, Petr Menšík wrote: > It would be beneficial to have also behavior tests. it may be the time to mention that we do exactly this for Pi-hole FTL which embeds the full dnsmasq for the DNS part. On every commit, a virtual machine is started which firstly compiles our project (including dnsmasq) and secondly runs it with standard parameters and starts a full test bench with more than a hundred individual tests. While the majority of tests are for extensions we made to dnsmasq (regular expressions, database integration, CNAME inspection, etc), we also have some standard DNS tests sending some A, , PTR, CNAME, SRV, SOA, ANY, TXT, NAPTR, MX, DS, RRSIG, etc. queries to specific domains and checking the answers. We then also check the logs and if anything is still working. For instance, our tests complained when merging my patch adding all the known DNS RR types because "query[type=5]" changes to "query[CNAME]". This was not a bug but you see the tests have noticed it. Even when this isn't directly applicable to the dnsmasq core project, it is still something that tests dnsmasq, even when embedded in another project. There is no unittest library whatsoever involved. The tests simply run on a compiled binary. You can find everything here if you're curious: https://github.com/pi-hole/FTL/tree/master/test Best, Dominik ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Re: 2.86rc1
On 30/09/2021 23:49, Petr Menšík wrote:
> Thanks!
>
> I were checking it a bit on test build and found part of file
> 0013-Fix-coverity-issues-detected-in-domain-match.c.patch avoided
> application. domain-match.c:447 still has add_resource_record return
> value unchecked, unlike A record above.
>
> Btw, return values shadows truncp pointer. If add_resource_record ever
> returns 0, truncp would always be set to 1. It seems trunc =
> !add_resource_record() || trunc; Would give the same result without
> passing it extra time as a pointer. Perhaps it should set { trunc = 1;
> break; } on !add_resource_record() and not return 0 as I proposed first.
>
The intention of add_resource_record() (and the way it's used everywhere
else) is that you can just keep calling it, and if any record goes over
the packet limit, it will set *trunc, stop adding records, and return 0
on subsequent calls. The only thing you have to do is not bump the
section record counter if it returns zero, and set the trunc flag if
*trunc is 1 by the end.
This code fails to do the first, and therefore breaks.
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=d2ad5dc073aaacaf22b117f16106282a73586803
does it right.
Cheers,
Simon.
> Attached alternative fix, which works better and were actually tested by:
>
> for F in {1..40}; do echo "--address=/test/127.0.0.$F"; done | xargs
> src/dnsmasq -d --port 2053 --conf-file=/dev/null --log-queries
>
> for F in {1..20}; do echo "--address=/test/::$F"; done | xargs
> src/dnsmasq -d --port 2053 --conf-file=/dev/null --log-queries
>
> Both create truncated responses to test a/ queries. Current state
> would not reply on A truncated query at all.
>
> On 9/12/21 00:05, Simon Kelley wrote:
>> Applied in 2.87.
>>
>> Cheers,
>>
>> Simon.
>>
>>
>>
>> On 03/09/2021 22:47, Petr Menšík wrote:
>>> Hi Simon,
>>>
>>> I have prepared a set of patches applied over 2.86rc3 release. They were
>>> made to silent some of reports from Coverity scans we do for our
>>> packages. I did include reported parts in commit messages, so commit
>>> messages are somehow noisy and contain more bytes that the diffs itself.
>>>
>>> It should add few safety checks on multiple places. Fix few error paths
>>> not releasing allocated memory and retries in case of failed syscall. It
>>> is not perfect, but should be good enough.
>>>
>>> Not heavily tested, compiles without issues or warnings and reduced
>>> reported issues. Review would be appreciated.
>>>
>>> What do you think, can they still be merged?
>>>
>>> Cheers,
>>>
>>> Petr
>>>
>>> On 8/25/21 3:46 PM, Simon Kelley wrote:
I just pushed a few final changes, tagged as dnsmasq-2.86rc1.
I'm fairly confident that this can be released as 2.86 in the near
future, but if you can, please test it now, to avoid disappointment later.
https://thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq-2.86rc1.tar.gz
Cheers,
Simon.
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>>
>> ___
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss@lists.thekelleys.org.uk
>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] --local is broken
On 05/10/2021 19:52, Dominik Derigs wrote: > Hey Simon, > > Since commit "Fix --address=/#/.. which was lost in 2.86" > (26bbf5a314d833beaf0f147d24409969f05f3dba) --local being a > synonym for --server is broken as --local became a synonym for -- > address. > > The attached patch fixes this. > > This was reported on the Pi-hole forums: > >> I have local=/fritz.box/192.168.0.1 in my /etc/dnsmasq.d/02- >> localdns.conf config file. This worked fine until upgrading >> pihole last night. Now all queries to FQDNs such as google.com >> get responded with google.com.fritz.box and ip address >> 192.186.0.1. >> >> Changing the line to server=/fritz.box/192.168.0.1 restores the >> previous handling. However, according to the dnsmasq manpage "- >> -local is a synonym for --server to make configuration files >> clearer in this case." > > Best, > Dominik > Patch applied. More discussion in my reply to Petr's reply. Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] --local is broken
On 05/10/2021 21:50, Petr Menšík wrote: > I have already reported it, but might got lost in different thread. > > https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q3/015723.html > > I took a look at the change, it seems it was intentional. Your proposed > change would break something else Simon tried to fix in commit 26bbf5a3 > I think. > > I think --address=/#/1.2.3.4 got broken. Which should be roughly > equivalent to --address=/./1.2.3.4, now that just . is accepted itself. > It got threated as --address=//1.2.3.4 in previous versions by mistake. > Your fix would restore --local=/test/1.1.1.1, but would break this part > again. I can't find an example of that. I think Dominik's patch is correct. (though I have to admit, I can't remember what problem I was trying to solve with the change from option == 'A' to option != 'S'. Whatever it was is spurious, as far as I can tell now. We now have the situation that --address=1.2.3.4 --address=/#/1.2.3.4 --address=/./1.2.3.4 all now do exactly the same thing, which is curious, but not a disaster. > That is why I had not attached patch to it, because correct fix > it more demanding. And address+server parsing is complicated enough now. > I think --local should emit warning if used with an address. I think its > intention was to be used just with domains like --local=/invalid/, > entries containing server also should use --server instead. > That may be what I was trying to fix. If the man page says that --local is a synonym for --server, then it should be. Clearly from Dominik's error reports, his users have been using --local=/example.com/1.2.3.4 and understanding its sematics OK. Cheers, Simon. > Cheers, > Petr > > On 10/5/21 20:52, Dominik Derigs wrote: >> Hey Simon, >> >> Since commit "Fix --address=/#/.. which was lost in 2.86" >> (26bbf5a314d833beaf0f147d24409969f05f3dba) --local being a >> synonym for --server is broken as --local became a synonym for -- >> address. >> >> The attached patch fixes this. >> >> This was reported on the Pi-hole forums: >> >>> I have local=/fritz.box/192.168.0.1 in my /etc/dnsmasq.d/02- >>> localdns.conf config file. This worked fine until upgrading >>> pihole last night. Now all queries to FQDNs such as google.com >>> get responded with google.com.fritz.box and ip address >>> 192.186.0.1. >>> >>> Changing the line to server=/fritz.box/192.168.0.1 restores the >>> previous handling. However, according to the dnsmasq manpage "- >>> -local is a synonym for --server to make configuration files >>> clearer in this case." >> Best, >> Dominik >> >> ___ >> Dnsmasq-discuss mailing list >> Dnsmasq-discuss@lists.thekelleys.org.uk >> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss > > -- > Petr Menšík > Software Engineer > Red Hat, http://www.redhat.com/ > email: pemen...@redhat.com > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
