Re: [Dnsmasq-discuss] Details of the --dhcp-optsdir= option
On Fri, Sep 03, 2021 at 02:32:06PM -0700, Michael wrote: > > > So the normal 'everything working' situation will be system A (say on > > 192.168.1.2) is a DNS and DHCP server. System B (say on 192.168.1.3) > > provides only DNS. System A's DHCP server will give out both > > 192.168.1.2 and 192.168.1.3 as DNS servers. > > > > If 192.168.1.3 fails or is off line everything continues to work OK > > except maybe some slowing down of DNS because of requests to > > 192.168.1.3 having to timeout before retrying on 192.168.1.2. > > > > If 192.168.1.2 fails I will add the DHCP configuration to it > > 'manually' and then I'll have a working system while I fix > > 192.168.1.2. > > > > I think it is important to understand the DNS doesn't really have the > concept of primary and secondary nameservers. They are all expected to be > equal and the client can choose which one it wants to try. So, your > servers have to have the ability to give the same responses or you will go > crazy trying to figure out why somethings aren't working right. > Yes, that's why I intend to have both DNS servers running when things are 'normal'. Both should respond pretty quickly so it shouldn't matter which gets asked first. > > In your scenario, you could sync the leases file over regularly as a > backup. Then when the failure occurs, you would update the secondary box > to add the dhcp options, stop the redirection above, and begin > owning/managing the DHCP leases file. When the primary comes back online, > you have to reverse the whole process or leave it this way until the next > failure, but sync the files the other way. > Ah, I think I can see the issue you're trying to point me to. If a client X gets its IP etc. from server A then server B won't have its details and if another client Y makes a DNS request for the name of the client X then server B won't know it. If I copy the leases file back and forth regularly will server B know client X's IP? Maybe it would actually be better to run only one dnsmasq and just keep its configuration and lease files in sync with the other installation. If server A fails then just start up dnsmasq on server B. This is simpler as both dnsmasq configurations can be identical, the only issue is that I need to change server B's IP address to that of server A. It might actually be easier/quicker to add the second IP in promiscuous mode (or run dnsmasq in a docker container in macvlan mode, but this adds a whole layer of complexity, especially as the servers will probably be different hardware). -- Chris Green ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Details of the --dhcp-optsdir= option
On Fri, Sep 03, 2021 at 02:32:06PM -0700, Michael wrote: > On 9/3/21 1:23 PM, Chris Green wrote: > > If I have set dhcp-optsdir in /etc/dnsmasq.conf and add a file to the > > directory it points to I assume any extra configuration in the added > > file will 'just happen' without any restart or signalling of dnsmasq. > > > > However (like the description for dhcp-hostsdir I presume that an > > option I have added as above will not be removed if I delete the added > > file. Specifically if I put a dhcp-range option in the added file > > (when there wasn't one in /etc/dnsmasq.conf) the DHCP server in > > dnsmasq will be turned on, but removing the file won't turn the DHCP > > server off again. I'd need to restart dnsmasq to turn the DHCP server > > off (or would one of the signals suffice?). > I believe this is correct. > > > > I'm thinking of running dnsmasq on two systems on my LAN to provide > > some resilience. One will be configured to run DHCP as well as DNS, > > the other will be DNS only. Apart from DHCP the configurations > > will be identical and the IPs of both systems will be given by the > > DHCP server as DNS IPs. > > > This works if your DHCP server only hands out static addressing so the host > names are all listed in the /etc/hosts or addn hosts location on both > machines. If the DHCP server is handing out addresses from a pool, then > only the DHCP dnsmasq instance will know about those hosts by name. > I was aiming to synchronise the lease file in /var between the two systems as well as the configuration. -- Chris Green ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Details of the --dhcp-optsdir= option
On 04/09/2021 09:15, Chris Green wrote: >> This works if your DHCP server only hands out static addressing so the host >> names are all listed in the /etc/hosts or addn hosts location on both >> machines. If the DHCP server is handing out addresses from a pool, then >> only the DHCP dnsmasq instance will know about those hosts by name. >> > I was aiming to synchronise the lease file in /var between the two > systems as well as the configuration. > Hi Chris Did you see my suggestion to cross post the events to each machine using a script? I replied in one of your other threads re this situation? I think you could make a simple/imperfect cluster setup like this fairly easily? (good enough for a small home lan) Ed W ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Details of the --dhcp-optsdir= option
On Sat, Sep 04, 2021 at 11:29:32AM +0100, Ed W wrote: > On 04/09/2021 09:15, Chris Green wrote: > > >> This works if your DHCP server only hands out static addressing so the host > >> names are all listed in the /etc/hosts or addn hosts location on both > >> machines. If the DHCP server is handing out addresses from a pool, then > >> only the DHCP dnsmasq instance will know about those hosts by name. > >> > > I was aiming to synchronise the lease file in /var between the two > > systems as well as the configuration. > > > > Did you see my suggestion to cross post the events to each machine using > a script? I replied in one > of your other threads re this situation? I think you could make a > simple/imperfect cluster setup > like this fairly easily? (good enough for a small home lan) > Yes, but I'm not quite clear what you mean by "cross post the events"? Do you mean something more than just synchronising the /var/lib/misc/dnsmasq.leases file between the two systems? Anyway I think I'm slowly working my way to a reasonable way of doing this. My latest idea changes things a little:- Run identical dnsmasq configurations on two systems, keep the configuration files and lease files synchronised. Use --listen-address to tell dnsmasq to listen to an IP that is only configured on one of the systems. Then, if that system dies, use 'ip addr add x.x.x.x eth0' to create the IP that dnsmasq will use on the backup system and all will be well. Will dnsmasq complain if the --listen-address doesn't exist? If so I can simply disable dnsmasq on the backup system (still synchronise files) and start it up as well as configure the IP when I need it. Can anyone see any major holes in this? -- Chris Green ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] What's the "right" way to specify upstream servers?
On 03.09.21 17:13, Chris Green wrote: I know there probably isn't a "right" way to do this but, while I've been trying to sort out how to make my dns/dhcp more resilient, I have looked at my existing dnsmasq running on a Pi and it looks a bit odd to me. It's a pretty standard, off the shelf Raspberry Pi installation using the Lite version as it's headless. The dnsmasq.conf file has been changed quite a lot over the years though and I wonder if it's still optimal. The upstream servers *seem* to be specified in /etc/dhcpcd.conf as follows:- # Example static IP configuration: interface eth0 static ip_address=192.168.1.2/24 #static ip6_address=fd51:42f8:caae:d92e::ff/64 static routers=192.168.1.1 static domain_name_servers=192.168.1.2 1.1.1.1 212.159.13.49 this is dhcp client configuration, not dhcp server. iiuc it tells dhcp client not to use IP address, default route nor servers that DHCP server provided. I really wonder why you run dhcp client in this case. /etc/resolv.conf is:- # Generated by resolvconf nameserver 127.0.0.1 this means local clients query something running on localhost, apparently dnsmasq. So, is the above OK? Is it the "right" way to do it? etc. I recomment using nameservers the DHCP server provided, not override it unless you really know why. Also, I would put upstream nameservers to resolv.conf, so the resolving works even if dnsmasq fails, crashes or is killed. The /etc/resolv.conf is written by /etc/init.d/dnsmasq and is, I believe, correct so that dnsmasq does local cacheing. However I'm not sure about the upstream servers in /etc/dhcpcd.conf including the local host as well. I don't see dnsmasq configuration here. I assume it's configured but I am not familiar to raspberry 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. 99 percent of lawyers give the rest a bad name. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Details of the --dhcp-optsdir= option
On 04/09/2021 12:07, Chris Green wrote: > On Sat, Sep 04, 2021 at 11:29:32AM +0100, Ed W wrote: >> On 04/09/2021 09:15, Chris Green wrote: >> >>> I was aiming to synchronise the lease file in /var between the two >>> systems as well as the configuration. >>> >> Did you see my suggestion to cross post the events to each machine using >> a script? I replied in one >> of your other threads re this situation? I think you could make a >> simple/imperfect cluster setup >> like this fairly easily? (good enough for a small home lan) >> > Yes, but I'm not quite clear what you mean by "cross post the events"? > Do you mean something more than just synchronising the > /var/lib/misc/dnsmasq.leases > file between the two systems? Hi, yes, dnsmasq emits a dbus event when a lease is created and has a dbus method to add a lease to it's db. Both can be scripted (examples given), so you can effectively "do something" every time a lease is handed out and poke the details of that lease into the other system *live*, ie it goes directly into its in memory db (which eventually will filter out to the on disk db) This gives you your optimal solution in that both machines have an in sync view of the lease table, ie promoting the second machine will immediately know the state of all the leases handed out by the first I speculate (without proof) that it might even work "well enough" to have both machines online and fighting to hand out dhcp leases... It's definitely *wrong*, but on a small network it might not break... > Anyway I think I'm slowly working my way to a reasonable way of doing > this. My latest idea changes things a little:- > > Run identical dnsmasq configurations on two systems, keep the > configuration files and lease files synchronised. Use > --listen-address to tell dnsmasq to listen to an IP that is only > configured on one of the systems. Then, if that system dies, use 'ip > addr add x.x.x.x eth0' to create the IP that dnsmasq will use on the > backup system and all will be well. > > Will dnsmasq complain if the --listen-address doesn't exist? If so I > can simply disable dnsmasq on the backup system (still synchronise > files) and start it up as well as configure the IP when I need it. > > Can anyone see any major holes in this? I think you can just have listen-address=0.0.0.0 on both machines? You then need a "high availability" system to ensure that the IP only gets assigned to one of the devices or the other... However, my opinion would be that for a small home network it would be "good enough" that the machines ping each other and if one goes down, the other promotes itself? eg consider the dns machine to be given out via DHCP as 192.168.22.1 and two real machines on 192.168.22.2 and 192.168.22.3, they each ping each other and if one is missing (or $machine==master), the other promotes itself to master and grabs the 192.168.22.1 IP address Now to do this properly you need to consider netsplits, ie where both machine *are* alive, but some other reason prevents them seeing each other. In the trivial case above they will both promote themselves to master. If you add in some (weird) way that both can see half the network then problems occur. The "proper" solution is a third machine to act as a voting tie breaker, some hardware to STONITH the dead note, etc, etc. However, I will risk derision by claiming that for dhcp in a home network, a) a netsplit would be very occasional and b) it's easily cleaned up from by just unplugging and replugging the affected machines, so really not worth the effort to properly implement... Good luck! Ed W > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] What's this error in syslog mean?
When [re]starting dnsmasq I see the following in syslog:- Sep 4 17:01:08 dns systemd[1]: dnsmasq.service: Succeeded. Sep 4 17:01:08 dns systemd[1]: Stopped dnsmasq - A lightweight DHCP and caching DNS server. Sep 4 17:01:08 dns systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server... Sep 4 17:01:08 dns dnsmasq[18982]: dnsmasq: syntax check OK. Sep 4 17:01:08 dns dnsmasq[18991]: started, version 2.80 cachesize 150 Sep 4 17:01:08 dns dnsmasq[18991]: DNS service limited to local subnets Sep 4 17:01:08 dns dnsmasq[18991]: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify dumpfile Sep 4 17:01:08 dns dnsmasq-dhcp[18991]: DHCP, IP range 192.168.1.80 -- 192.168.1.127, lease time 12h Sep 4 17:01:08 dns dnsmasq[18991]: using local addresses only for domain zbmc.eu Sep 4 17:01:08 dns dnsmasq[18991]: reading /run/dnsmasq/resolv.conf Sep 4 17:01:08 dns dnsmasq[18991]: using local addresses only for domain zbmc.eu Sep 4 17:01:08 dns dnsmasq[18991]: ignoring nameserver 192.168.1.2 - local interface Sep 4 17:01:08 dns dnsmasq[18991]: using nameserver 1.1.1.1#53 Sep 4 17:01:08 dns dnsmasq[18991]: using nameserver 212.159.13.49#53 Sep 4 17:01:08 dns dnsmasq[18991]: read /etc/hosts - 12 addresses Sep 4 17:01:08 dns dnsmasq[18992]: Too few arguments. Sep 4 17:01:08 dns systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server. Sep 4 17:02:17 dns dnsmasq[18991]: read /etc/hosts - 12 addresses Sep 4 17:05:05 dns dnsmasq-dhcp[18991]: DHCPREQUEST(eth0) 192.168.1.95 cc:ab:2c:39:69:2b Sep 4 17:05:05 dns dnsmasq-dhcp[18991]: DHCPACK(eth0) 192.168.1.95 cc:ab:2c:39:69:2b benYouview What does that error from process 18992 mean "Too few arguments."? Does it indicate any sort of problem? -- Chris Green ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] What's the "right" way to specify upstream servers?
On Sat, Sep 04, 2021 at 04:33:10PM +0200, Matus UHLAR - fantomas via Dnsmasq-discuss wrote: > On 03.09.21 17:13, Chris Green wrote: > > I know there probably isn't a "right" way to do this but, while I've > > been trying to sort out how to make my dns/dhcp more resilient, I have > > looked at my existing dnsmasq running on a Pi and it looks a bit odd > > to me. > > > > It's a pretty standard, off the shelf Raspberry Pi installation using > > the Lite version as it's headless. The dnsmasq.conf file has been > > changed quite a lot over the years though and I wonder if it's still > > optimal. > > > > The upstream servers *seem* to be specified in /etc/dhcpcd.conf as > > follows:- > > > ># Example static IP configuration: > >interface eth0 > >static ip_address=192.168.1.2/24 > >#static ip6_address=fd51:42f8:caae:d92e::ff/64 > >static routers=192.168.1.1 > >static domain_name_servers=192.168.1.2 1.1.1.1 212.159.13.49 > > this is dhcp client configuration, not dhcp server. > > iiuc it tells dhcp client not to use IP address, default route nor servers > that DHCP server provided. > This *is* the DHCP server for my LAN so these are the upstream DNS servers it gives to its clients. > I really wonder why you run dhcp client in this case. > > > /etc/resolv.conf is:- > > > ># Generated by resolvconf > >nameserver 127.0.0.1 > > this means local clients query something running on localhost, apparently > dnsmasq. > > > So, is the above OK? Is it the "right" way to do it? etc. > > I recomment using nameservers the DHCP server provided, not override it > unless you really know why. > As I said this *is* the DHCP server. The second upstream server is the one I get from my ISP (212.159.13.49 that is). > Also, I would put upstream nameservers to resolv.conf, so the resolving > works even if dnsmasq fails, crashes or is killed. > > > The /etc/resolv.conf is written by /etc/init.d/dnsmasq and is, I > > believe, correct so that dnsmasq does local cacheing. However I'm not > > sure about the upstream servers in /etc/dhcpcd.conf including the > > local host as well. > > I don't see dnsmasq configuration here. > > I assume it's configured but I am not familiar to raspberry configuration... Exactly my problem! It's an 'out of the box' installation of dnsmasq on a Raspberry Pi that I have changed to static IP so that it can act as my local DNS/DHCP server. -- Chris Green ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] What's this error in syslog mean?
On 9/4/2021 6:14 PM, Chris Green wrote: When [re]starting dnsmasq I see the following in syslog:- Sep 4 17:01:08 dns systemd[1]: dnsmasq.service: Succeeded. Sep 4 17:01:08 dns systemd[1]: Stopped dnsmasq - A lightweight DHCP and caching DNS server. Sep 4 17:01:08 dns systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server... Sep 4 17:01:08 dns dnsmasq[18982]: dnsmasq: syntax check OK. Sep 4 17:01:08 dns dnsmasq[18991]: started, version 2.80 cachesize 150 Sep 4 17:01:08 dns dnsmasq[18991]: DNS service limited to local subnets Sep 4 17:01:08 dns dnsmasq[18991]: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify dumpfile Sep 4 17:01:08 dns dnsmasq-dhcp[18991]: DHCP, IP range 192.168.1.80 -- 192.168.1.127, lease time 12h Sep 4 17:01:08 dns dnsmasq[18991]: using local addresses only for domain zbmc.eu Sep 4 17:01:08 dns dnsmasq[18991]: reading /run/dnsmasq/resolv.conf Sep 4 17:01:08 dns dnsmasq[18991]: using local addresses only for domain zbmc.eu Sep 4 17:01:08 dns dnsmasq[18991]: ignoring nameserver 192.168.1.2 - local interface Sep 4 17:01:08 dns dnsmasq[18991]: using nameserver 1.1.1.1#53 Sep 4 17:01:08 dns dnsmasq[18991]: using nameserver 212.159.13.49#53 Sep 4 17:01:08 dns dnsmasq[18991]: read /etc/hosts - 12 addresses Sep 4 17:01:08 dns dnsmasq[18992]: Too few arguments. Sep 4 17:01:08 dns systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server. Sep 4 17:02:17 dns dnsmasq[18991]: read /etc/hosts - 12 addresses Sep 4 17:05:05 dns dnsmasq-dhcp[18991]: DHCPREQUEST(eth0) 192.168.1.95 cc:ab:2c:39:69:2b Sep 4 17:05:05 dns dnsmasq-dhcp[18991]: DHCPACK(eth0) 192.168.1.95 cc:ab:2c:39:69:2b benYouview What does that error from process 18992 mean "Too few arguments."? Does it indicate any sort of problem? Would be better if you could increase the log verbosity to troubleshoot this... -- 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] Question about --all-servers in man page
Hey Masanari, On Fri, 2021-09-03 at 19:26 +0900, Masanari Iida wrote: > dnsmasq-2.85 (Fedora 33, x86_64) > multiple upstream DNS servers in config file. > No --strict-order, No --all-server setting . > > Symptom > Explanation about --all-servers in dnsmasq(8) man page could > be different from actual dnsmasq behavior. > > In man page, it is written that > "By default, when dnsmasq has more than one upstream server > available, it will send queries to just one server" > > But actual behavior is, it sends queries to _ALL_ upstream DNS > servers in config at once. > And if I set --strict-order in dnsmasq.conf, then it send a query to > one > server at a time. This is expected behavior, the man page explains this somewhat hidden in the option --strict-order: > By default, dnsmasq will send queries to any of the upstream servers it knows about and tries to favour servers that are known to be up. This probing of the fastest happens every now and then, to be precise every 50 queries or every 20 seconds, see https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/config.h;h=30e23d8e8fb6a0b78d479f77ea021fe126e0670c;hb=HEAD#l27 and the line below. The default probing could likely be made less often, but else than that, I don't think there is an inconsistency here. 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] Details of the --dhcp-optsdir= option
On Sat, Sep 04, 2021 at 03:34:59PM +0100, Ed W wrote: > On 04/09/2021 12:07, Chris Green wrote: > > On Sat, Sep 04, 2021 at 11:29:32AM +0100, Ed W wrote: > >> On 04/09/2021 09:15, Chris Green wrote: > >> > >>> I was aiming to synchronise the lease file in /var between the two > >>> systems as well as the configuration. > >>> > >> Did you see my suggestion to cross post the events to each machine using > >> a script? I replied in one > >> of your other threads re this situation? I think you could make a > >> simple/imperfect > cluster setup > >> like this fairly easily? (good enough for a small home lan) > >> > > Yes, but I'm not quite clear what you mean by "cross post the events"? > > Do you mean something more than just synchronising the > > /var/lib/misc/dnsmasq.leases > > file between the two systems? > > Hi, yes, dnsmasq emits a dbus event when a lease is created and has a dbus > method to add a lease to > it's db. > > Both can be scripted (examples given), so you can effectively "do something" > every time a lease is > handed out and poke the details of that lease into the other system *live*, > ie it goes directly into > its in memory db (which eventually will filter out to the on disk db) > > This gives you your optimal solution in that both machines have an in sync > view of the lease table, > ie promoting the second machine will immediately know the state of all > the leases handed out by the > first > > I speculate (without proof) that it might even work "well enough" to have > both machines online and > fighting to hand out dhcp leases... It's definitely *wrong*, but on a small > network it might not > break... > I think I can probably just use syncthing to synchronise the lease file across systems. Since the normal case will be that only one system is changing the file it's a simple sync requirement. If/when a system fails sync is no longer doing anything. Trying to run both DHCP servers seems just a bit risky! :-) -- Chris Green ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] What's this error in syslog mean?
On Sat, Sep 04, 2021 at 07:09:30PM +0200, john doe wrote: > On 9/4/2021 6:14 PM, Chris Green wrote: > > When [re]starting dnsmasq I see the following in syslog:- > > > > Sep 4 17:01:08 dns systemd[1]: dnsmasq.service: Succeeded. > > Sep 4 17:01:08 dns systemd[1]: Stopped dnsmasq - A lightweight DHCP and > caching DNS server. > > Sep 4 17:01:08 dns systemd[1]: Starting dnsmasq - A lightweight DHCP > and caching DNS server... > > Sep 4 17:01:08 dns dnsmasq[18982]: dnsmasq: syntax check OK. > > Sep 4 17:01:08 dns dnsmasq[18991]: started, version 2.80 cachesize 150 > > Sep 4 17:01:08 dns dnsmasq[18991]: DNS service limited to local > > subnets > > Sep 4 17:01:08 dns dnsmasq[18991]: compile time options: IPv6 GNU-getopt > DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect > inotify dumpfile > > Sep 4 17:01:08 dns dnsmasq-dhcp[18991]: DHCP, IP range 192.168.1.80 -- > 192.168.1.127, lease time 12h > > Sep 4 17:01:08 dns dnsmasq[18991]: using local addresses only for > > domain zbmc.eu > > Sep 4 17:01:08 dns dnsmasq[18991]: reading /run/dnsmasq/resolv.conf > > Sep 4 17:01:08 dns dnsmasq[18991]: using local addresses only for > > domain zbmc.eu > > Sep 4 17:01:08 dns dnsmasq[18991]: ignoring nameserver 192.168.1.2 - > > local interface > > Sep 4 17:01:08 dns dnsmasq[18991]: using nameserver 1.1.1.1#53 > > Sep 4 17:01:08 dns dnsmasq[18991]: using nameserver 212.159.13.49#53 > > Sep 4 17:01:08 dns dnsmasq[18991]: read /etc/hosts - 12 addresses > > Sep 4 17:01:08 dns dnsmasq[18992]: Too few arguments. > > Sep 4 17:01:08 dns systemd[1]: Started dnsmasq - A lightweight DHCP and > caching DNS server. > > Sep 4 17:02:17 dns dnsmasq[18991]: read /etc/hosts - 12 addresses > > Sep 4 17:05:05 dns dnsmasq-dhcp[18991]: DHCPREQUEST(eth0) > > 192.168.1.95 cc:ab:2c:39:69:2b > > Sep 4 17:05:05 dns dnsmasq-dhcp[18991]: DHCPACK(eth0) 192.168.1.95 > > cc:ab:2c:39:69:2b > benYouview > > > > What does that error from process 18992 mean "Too few arguments."? Does it > > indicate > > any sort of problem? > > > > Would be better if you could increase the log verbosity to troubleshoot > this... > Well, I've turned on the extra logging and it looks much the same:- Sep 4 20:12:55 dns systemd[1]: dnsmasq.service: Succeeded. Sep 4 20:12:55 dns systemd[1]: Stopped dnsmasq - A lightweight DHCP and caching DNS server. Sep 4 20:12:55 dns systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server... Sep 4 20:12:55 dns dnsmasq[1735]: dnsmasq: syntax check OK. Sep 4 20:12:56 dns dnsmasq[1744]: started, version 2.80 cachesize 150 Sep 4 20:12:56 dns dnsmasq[1744]: DNS service limited to local subnets Sep 4 20:12:56 dns dnsmasq[1744]: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify dumpfile Sep 4 20:12:56 dns dnsmasq-dhcp[1744]: DHCP, IP range 192.168.1.80 -- 192.168.1.127, lease time 12h Sep 4 20:12:56 dns dnsmasq[1744]: using local addresses only for domain zbmc.eu Sep 4 20:12:56 dns dnsmasq[1744]: reading /run/dnsmasq/resolv.conf Sep 4 20:12:56 dns dnsmasq[1744]: using local addresses only for domain zbmc.eu Sep 4 20:12:56 dns dnsmasq[1744]: ignoring nameserver 192.168.1.2 - local interface Sep 4 20:12:56 dns dnsmasq[1744]: using nameserver 1.1.1.1#53 Sep 4 20:12:56 dns dnsmasq[1744]: using nameserver 212.159.13.49#53 Sep 4 20:12:56 dns dnsmasq[1744]: read /etc/hosts - 12 addresses Sep 4 20:12:56 dns dnsmasq[1745]: Too few arguments. Sep 4 20:12:56 dns systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server. Sep 4 20:13:21 dns dnsmasq[1744]: 1 192.168.1.96/1424 query[] graph.facebook.com from 192.168.1.96 Sep 4 20:13:21 dns dnsmasq[1744]: 1 192.168.1.96/1424 forwarded graph.facebook.com to 1.1.1.1 Sep 4 20:13:21 dns dnsmasq[1744]: 1 192.168.1.96/1424 forwarded graph.facebook.com to 212.159.13.49 This is with log-queries=extra and log-dhcp set. Is there anything else I can do to get more diagnostics? -- Chris Green ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] What's this error in syslog mean?
On Sat, Sep 04, 2021 at 08:16:44PM +0100, Chris Green wrote: > On Sat, Sep 04, 2021 at 07:09:30PM +0200, john doe wrote: > > On 9/4/2021 6:14 PM, Chris Green wrote: > > > When [re]starting dnsmasq I see the following in syslog:- > > > > > > Sep 4 17:01:08 dns dnsmasq[18991]: started, version 2.80 cachesize 150 > > > Sep 4 17:01:08 dns dnsmasq[18991]: DNS service limited to local subnets 91 > > > Sep 4 17:01:08 dns dnsmasq[18991]: read /etc/hosts - 12 addresses > > > Sep 4 17:01:08 dns dnsmasq[18992]: Too few arguments. 92 > > > Sep 4 17:01:08 dns systemd[1]: Started dnsmasq - A lightweight DHCP and > > > caching DNS server. > > > Sep 4 17:02:17 dns dnsmasq[18991]: read /etc/hosts - 12 addresses > > > Sep 4 17:05:05 dns dnsmasq-dhcp[18991]: DHCPREQUEST(eth0) 192.168.1.95 > > > cc:ab:2c:39:69:2b > > > Sep 4 17:05:05 dns dnsmasq-dhcp[18991]: DHCPACK(eth0) 192.168.1.95 > > > cc:ab:2c:39:69:2b benYouview > > > > > > What does that error from process 18992 mean "Too few arguments."? > > > Does it indicate any sort of problem? > > > > > > > Would be better if you could increase the log verbosity > > to troubleshoot this... > > > Well, I've turned on the extra logging and it looks much the same:- ;-) > Sep 4 20:12:56 dns dnsmasq[1744]: started, version 2.80 cachesize 150 > Sep 4 20:12:56 dns dnsmasq[1744]: DNS service limited to local subnets 44 > Sep 4 20:12:56 dns dnsmasq[1745]: Too few arguments. 45 > This is with log-queries=extra and log-dhcp set. And how is dnsmasq started? What is in configuration file? > Is there anything else I can do to get more diagnostics? Do see already that dnsmasq is started (with some PID) And there is another dnsmasq, probably a dnsmasq script, with another PID. Answering "And how is dnsmasq started? What is in configuration file?" might reveal what is the other dnsmasq (script). Groeten Geert Stappers PID: Process IDentifer -- 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
Re: [Dnsmasq-discuss] What's this error in syslog mean?
On 04/09/2021 17:14, Chris Green wrote: > When [re]starting dnsmasq I see the following in syslog:- > > Sep 4 17:01:08 dns systemd[1]: dnsmasq.service: Succeeded. > Sep 4 17:01:08 dns systemd[1]: Stopped dnsmasq - A lightweight DHCP and > caching DNS server. > Sep 4 17:01:08 dns systemd[1]: Starting dnsmasq - A lightweight DHCP and > caching DNS server... > Sep 4 17:01:08 dns dnsmasq[18982]: dnsmasq: syntax check OK. > Sep 4 17:01:08 dns dnsmasq[18991]: started, version 2.80 cachesize 150 > Sep 4 17:01:08 dns dnsmasq[18991]: DNS service limited to local subnets > Sep 4 17:01:08 dns dnsmasq[18991]: compile time options: IPv6 GNU-getopt > DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect > inotify dumpfile > Sep 4 17:01:08 dns dnsmasq-dhcp[18991]: DHCP, IP range 192.168.1.80 -- > 192.168.1.127, lease time 12h > Sep 4 17:01:08 dns dnsmasq[18991]: using local addresses only for domain > zbmc.eu > Sep 4 17:01:08 dns dnsmasq[18991]: reading /run/dnsmasq/resolv.conf > Sep 4 17:01:08 dns dnsmasq[18991]: using local addresses only for domain > zbmc.eu > Sep 4 17:01:08 dns dnsmasq[18991]: ignoring nameserver 192.168.1.2 - > local interface > Sep 4 17:01:08 dns dnsmasq[18991]: using nameserver 1.1.1.1#53 > Sep 4 17:01:08 dns dnsmasq[18991]: using nameserver 212.159.13.49#53 > Sep 4 17:01:08 dns dnsmasq[18991]: read /etc/hosts - 12 addresses > Sep 4 17:01:08 dns dnsmasq[18992]: Too few arguments. > Sep 4 17:01:08 dns systemd[1]: Started dnsmasq - A lightweight DHCP and > caching DNS server. > Sep 4 17:02:17 dns dnsmasq[18991]: read /etc/hosts - 12 addresses > Sep 4 17:05:05 dns dnsmasq-dhcp[18991]: DHCPREQUEST(eth0) 192.168.1.95 > cc:ab:2c:39:69:2b > Sep 4 17:05:05 dns dnsmasq-dhcp[18991]: DHCPACK(eth0) 192.168.1.95 > cc:ab:2c:39:69:2b benYouview > > What does that error from process 18992 mean "Too few arguments."? Does it > indicate > any sort of problem? > The PID of the process is different, so I'd guess that it's coming from a dhcp-script invocation. 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] What's this error in syslog mean?
On 04/09/2021 21:19, Geert Stappers via Dnsmasq-discuss wrote: > On Sat, Sep 04, 2021 at 08:16:44PM +0100, Chris Green wrote: >> On Sat, Sep 04, 2021 at 07:09:30PM +0200, john doe wrote: >>> On 9/4/2021 6:14 PM, Chris Green wrote: When [re]starting dnsmasq I see the following in syslog:- Sep 4 17:01:08 dns dnsmasq[18991]: started, version 2.80 cachesize 150 Sep 4 17:01:08 dns dnsmasq[18991]: DNS service limited to local subnets > 91 > Sep 4 17:01:08 dns dnsmasq[18991]: read /etc/hosts - 12 addresses Sep 4 17:01:08 dns dnsmasq[18992]: Too few arguments. > 92 > Sep 4 17:01:08 dns systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server. Sep 4 17:02:17 dns dnsmasq[18991]: read /etc/hosts - 12 addresses Sep 4 17:05:05 dns dnsmasq-dhcp[18991]: DHCPREQUEST(eth0) 192.168.1.95 cc:ab:2c:39:69:2b Sep 4 17:05:05 dns dnsmasq-dhcp[18991]: DHCPACK(eth0) 192.168.1.95 cc:ab:2c:39:69:2b benYouview What does that error from process 18992 mean "Too few arguments."? Does it indicate any sort of problem? >>> >>> Would be better if you could increase the log verbosity >>> to troubleshoot this... >>> >> Well, I've turned on the extra logging and it looks much the same:- > ;-) > >> Sep 4 20:12:56 dns dnsmasq[1744]: started, version 2.80 cachesize 150 >> Sep 4 20:12:56 dns dnsmasq[1744]: DNS service limited to local subnets > 44 > >> Sep 4 20:12:56 dns dnsmasq[1745]: Too few arguments. > 45 > > > >> This is with log-queries=extra and log-dhcp set. > > And how is dnsmasq started? What is in configuration file? > > >> Is there anything else I can do to get more diagnostics? > > Do see already that dnsmasq is started (with some PID) > And there is another dnsmasq, probably a dnsmasq script, > with another PID. > > Answering "And how is dnsmasq started? What is in configuration file?" > might reveal what is the other dnsmasq (script). > > When using the DHCP-script, a dnsmasq daemon actually consists of two processes, which normally end up with consecutive PIDs, so this is probably npt a case of dnsmasq being invoked twice, but an error during the running of the script by the second process which exists to do exactly that. Simon. > > Groeten > Geert Stappers > > PID: Process IDentifer > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] 2.86rc1
I think if these go in now, we'd need to push back 2.86 for a week or two for testing. I've been through them and not found any show-stoppers, so I'm in a quandary about delaying 2.86 or pushing them to 2.87. Dominik, you were the one pushing for 2.86. Thoughts? 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
Re: [Dnsmasq-discuss] Patch with option to filter A records
On 02/09/2021 21:18, Trey Sis wrote: > On 7/9/2021 17:46, Geert Stappers via Dnsmasq-discuss wrote: >> On Fri, Jul 09, 2021 at 02:35:29PM +0200, Petr Menšík wrote: >>> On 6/16/21 1:26 PM, Trey Sis wrote: On 6/14/2021 1:43, Trey Sis wrote: > On 6/13/2021 22:01, Geert Stappers wrote: >> warning: 1 line adds whitespace errors. > My bad! Fixed. Find the new patch attached to this message. > Hello everyone, I was wondering if anyone has any suggestions or objections for the patch? I still think it would be very valuable for many setups out there to drop A records. Most OS don't query for if there is no IPv6 connection. But none don't query for A if there is no IPv4. That often causes problems with applications that did not (yet) implement happy eyeballs. Getting this upstream would make it much easier to handle IPv6-only environments. What do you think? >>> Hi Trey, >>> >>> Are there any specific applications requiring this patch? It seems to me >>> most of work should be spent on applications not handling IPv4 addresses >>> correctly. Also, I would implement filtering of both address families if >>> it is required. >>> >>> Are there specific applications, where we can help escalate the problem >>> on their side instead? As you have already said, when they ask for A >>> address, they should receive one. Whether it is useful or not, clients >>> should be able to process it. And skipping to IPv6 in case of no IPv4 >>> connectivity should be immediate. We lack full IPv6 connectivity at >>> office, so far I know only svn is not able to switch to IPv4 only. Which >>> is solved by switching to git. Filtering of record would have >>> solved it too. >>> >>> >> Quoting post that started this email thread: >> >> } I have created a patch that adds an option to dnsmasq to filter >> } out A record requests. This is particularly suitable for IPv6-only >> } environments. Some software (especially NodeJS) will reorder DNS >> } requests giving priority to A records, irrespective of IPv4 >> } connectivity of the host. My patch filters A records, while >> } records are returned. >> >> Short answer to >>> Do you have examples of applications, where this change would help? >> NodeJS > > Alright, so I have found the time now to rebase this patch against the > current branch. > > I can only repeat that it would be make a lot of folks happy to have > this patch included, even if they're not on this mailing list. It's > mostly NodeJS applications, but other apps as well. It's often not clear > what would work. So this patch would also be helpful in development > environments when testing IPv6 compatibility with software. > > I would really love to have some feedback if you are missing some detail. > > Cheers, > So, this patch looks for questions which are for an A record, and always returns a NODATA answer. That's not strictly correct. If we have a domain which doesn't exist, say no-such-domain.example.com The answer to a query for that will be NXDOMAIN, which means that the domain doesn't exist, and queries for any type of RR will always fail. A sensible DNS client which sees that will not repeat queries for that name with other RR types. With this patch, a query for A no-such-domain.example.com will get a NODATA response, which implies that there's no A record, but there are other records, so the client will try for other types. That's inefficient, but worse, if the client then tries for an record (for instance) it will get an NXDOMAIN response. At this point the client is seeing inconsistent responses from the DNS and all bets are off. Always returning an NXDOMAIN response is worse, of course, since if that happens with a domain which does have other RR types, they will effectively deleted by the wrong NXDOMAIN. The correct way to do this is to send the query upstream, and then when the reply comes back, delete any A records from the reply before it's returned to the original requestor, (and before it's cached.) The hard work of doing this has been done in src/rrfilter.c, it just needs another mode which deletes A records from the answer section only. A patch which does that (and has an option to do the same thing for records) and has suitable man page additions, I'd certainly take. It's in the dnsmasq tradition of providing tools to usefully edit the view of the DNS seen by downstream clients. Cheers, 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] Add RFC 4833 DHCP timezone options
On 03/09/2021 13:13, Dominik DL6ER wrote: > Hey Simon, > > this small patch adds the DHCP options "posix-timezone" and "tzdb- > timezone" as defined in RFC 4833, Section 2: > https://datatracker.ietf.org/doc/html/rfc4833#section-2 > > Examples for valid options are > >> dhcp-option = option:posix-timezone,"CEST- > 1CET,M3.2.0/2:00:00,M11.1.0/2:00:00" > > and > >> dhcp-option = option:tzdb-timezone,"Europe/Berlin" > > Best, > Dominik > Patch applied. Thanks. Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
