Re: [Dnsmasq-discuss] spin-off: dictionary order import of addn-hosts dirs?
On Thu, Aug 12, 2021 at 07:30:59PM +0200, john doe wrote: > On 8/12/2021 5:04 PM, Simon Kelley wrote: > > On 11/08/2021 00:25, Ed W wrote: > > > On 10/08/2021 23:12, Simon Kelley wrote: > > > > On 08/08/2021 14:02, Ed W wrote: > > > > > On 19/07/2021 18:52, Ed W wrote: > > [snip] > > > --dhcp-hostsdir --dhcp-optsdir and --hostsdir work in much the same way > > as when the first three options are given a directory; the files are > > read at start-up and when SIGHUP is received. BUT any file which is > > modified or created gets read asynchronously, without needing SIGHUP to > > be sent. Note that the old data from the files is not discarded when > > this is done: if a file gets modified, then it gets re-read but data > > from the previous version of the file is not deleted. This means that > > Why is deleting not happening when the file is reread? Expensive operation. Reading a file and adding / updating each entry in memory is simple algorithm. Going through memory entries and all entries in all files and keeping track which entries should remain is a way more complex algorithm. > > this facility is useful for adding hosts to the configuration without > > the upheaval of a full SIGHUP re-read. Anytime you want to delete stuff, > > SIGHUP is still needed. > > > > In other words, > what is the reasoning behind requiring SIGHUP to delete stuff? SIGHUP is actual "flush all and reread all" Between flush all and all reread, there can be DNS queries which then can't be answered as when all have been rereaded. > John Doe 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
Re: [Dnsmasq-discuss] feature: dictionary order import of addn-hosts dirs?
On 8/12/2021 5:04 PM, Simon Kelley wrote: On 11/08/2021 00:25, Ed W wrote: On 10/08/2021 23:12, Simon Kelley wrote: On 08/08/2021 14:02, Ed W wrote: On 19/07/2021 18:52, Ed W wrote: [snip] --dhcp-hostsdir --dhcp-optsdir and --hostsdir work in much the same way as when the first three options are given a directory; the files are read at start-up and when SIGHUP is received. BUT any file which is modified or created gets read asynchronously, without needing SIGHUP to be sent. Note that the old data from the files is not discarded when this is done: if a file gets modified, then it gets re-read but data from the previous version of the file is not deleted. This means that Why is deleting not happening when the file is reread? this facility is useful for adding hosts to the configuration without the upheaval of a full SIGHUP re-read. Anytime you want to delete stuff, SIGHUP is still needed. In other words, what is the reasoning behind requiring SIGHUP to delete stuff? -- 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] feature: dictionary order import of addn-hosts dirs?
On 12/08/2021 16:04, Simon Kelley wrote: > On 11/08/2021 00:25, Ed W wrote: >> On 10/08/2021 23:12, Simon Kelley wrote: >>> On 08/08/2021 14:02, Ed W wrote: On 19/07/2021 18:52, Ed W wrote: > Hi, around 2.82 someone posted a little patch to import the config files > in dictionary order, which > is very useful for situations where you have overlapping definitions. I'm > using an addn-hosts stanza > pointing to a directory and files currently import in a somewhat random > order (suppose inode > order?), which can lead to unexpected reverse host definitions in some > cases > > Could we have a dictionary order import for add-hosts files please? > > Ed W Hi, I have developed the attached patch without really being sure that this is the best approach. I would be grateful for some feedback. I have used scandir without understanding if this is portable across systems that we support with dnsmasq. Also I am trying to copy the existing coding style, but surely I have failed. >>> I'll look in more detail soon, but this certainly looks like the right >>> way to go. >>> I'm also unclear that it still works as advertised in the case that I don't have inotify enabled? Any help? >>> Since the whole point of the inotify stuff is that individual files get >>> read as they change, imposing or relying on a particular order doesn't >>> make much sense. I'd therefore not make any changes to inotify.c. >>> >>> The man page then needs to note that --dhcp-hostsdir --dhcp-optsdir and >>> --hostsdir DON'T offer any ordering of files read, but >>> --dhcp-hostsfile --dhcp-optsfile and --addn-hosts with directory >>> arguments DO. >> >> >> Aha, then I might have gone off the rails here then... >> >> It's the changes in inotify.c which affect my --addn-hosts directives? I >> left the top part of the >> patch to option.c in there as it seemed like it probably affected >> (hostsdir?), and seemed useful yet >> without any real cost? > > > That's not my understanding. > > --dhcp-hostsfile --dhcp-optsfile and --addn-hosts have nothing to do > with inotify. The argument to any of them can be a directory, rather a > file, and then all the files in the directory get read. Reading these > files ONLY happens at start-up and when SIGHUP is received, at which > times _all_ the files get read. It makes sense to define the order of > reading these files within a directory. When SIGHUP is received, the old > data from the files in discarded, and they are all re-read. > > --dhcp-hostsdir --dhcp-optsdir and --hostsdir work in much the same way > as when the first three options are given a directory; the files are > read at start-up and when SIGHUP is received. BUT any file which is > modified or created gets read asynchronously, without needing SIGHUP to > be sent. Note that the old data from the files is not discarded when > this is done: if a file gets modified, then it gets re-read but data > from the previous version of the file is not deleted. This means that > this facility is useful for adding hosts to the configuration without > the upheaval of a full SIGHUP re-read. Anytime you want to delete stuff, > SIGHUP is still needed. > > Given the above, defining the order in which files in those directories > are read is a bit pointless: sure, you can define and order for startup > and SIGHUP, but then as soon as file is touched or added, the order > depends on that. > > If you're using --addn-hosts, then the inotify code isn't affecting what > you're doing: you must be sending SIGHUP to re-read any changes to the > files. > > The inotify code can be omitted entirely and --addn-hosts will still > work, but --dhcp-hostsdir --dhcp-optsdir and --hostsdir options will be > errored. > > Given that, I propose to take your patch to expand_filelist(), which > will define the order for --dhcp-hostsfile --dhcp-optsfile and > --addn-hosts when they take directories, but not the changes in > inotify.c, which are not needed for that. > > Change now committed. I started with your patch to expand_filelist() and made the following changes. 1) Moved the editor-file filter code into a filter callback for scandir, just to avoid allocating memory for then-ignored files. 2) Linked-list horribleness to avoid inverting the order of files retrieved from scandir. 3) Made things clear in the manpage for the options which are affected by this, and the inotify ones which aren't. https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=2f2d59b35c3338ffa20361d409f07ef340987d1b 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] feature: dictionary order import of addn-hosts dirs?
On 11/08/2021 00:25, Ed W wrote: > On 10/08/2021 23:12, Simon Kelley wrote: >> On 08/08/2021 14:02, Ed W wrote: >>> On 19/07/2021 18:52, Ed W wrote: Hi, around 2.82 someone posted a little patch to import the config files in dictionary order, which is very useful for situations where you have overlapping definitions. I'm using an addn-hosts stanza pointing to a directory and files currently import in a somewhat random order (suppose inode order?), which can lead to unexpected reverse host definitions in some cases Could we have a dictionary order import for add-hosts files please? Ed W >>> >>> Hi, I have developed the attached patch without really being sure that this >>> is the best approach. I >>> would be grateful for some feedback. I have used scandir without >>> understanding if this is portable >>> across systems that we support with dnsmasq. Also I am trying to copy the >>> existing coding style, but >>> surely I have failed. >>> >> I'll look in more detail soon, but this certainly looks like the right >> way to go. >> >>> I'm also unclear that it still works as advertised in the case that I don't >>> have inotify enabled? >>> Any help? >> Since the whole point of the inotify stuff is that individual files get >> read as they change, imposing or relying on a particular order doesn't >> make much sense. I'd therefore not make any changes to inotify.c. >> >> The man page then needs to note that --dhcp-hostsdir --dhcp-optsdir and >> --hostsdir DON'T offer any ordering of files read, but >> --dhcp-hostsfile --dhcp-optsfile and --addn-hosts with directory >> arguments DO. > > > Aha, then I might have gone off the rails here then... > > It's the changes in inotify.c which affect my --addn-hosts directives? I left > the top part of the > patch to option.c in there as it seemed like it probably affected > (hostsdir?), and seemed useful yet > without any real cost? That's not my understanding. --dhcp-hostsfile --dhcp-optsfile and --addn-hosts have nothing to do with inotify. The argument to any of them can be a directory, rather a file, and then all the files in the directory get read. Reading these files ONLY happens at start-up and when SIGHUP is received, at which times _all_ the files get read. It makes sense to define the order of reading these files within a directory. When SIGHUP is received, the old data from the files in discarded, and they are all re-read. --dhcp-hostsdir --dhcp-optsdir and --hostsdir work in much the same way as when the first three options are given a directory; the files are read at start-up and when SIGHUP is received. BUT any file which is modified or created gets read asynchronously, without needing SIGHUP to be sent. Note that the old data from the files is not discarded when this is done: if a file gets modified, then it gets re-read but data from the previous version of the file is not deleted. This means that this facility is useful for adding hosts to the configuration without the upheaval of a full SIGHUP re-read. Anytime you want to delete stuff, SIGHUP is still needed. Given the above, defining the order in which files in those directories are read is a bit pointless: sure, you can define and order for startup and SIGHUP, but then as soon as file is touched or added, the order depends on that. If you're using --addn-hosts, then the inotify code isn't affecting what you're doing: you must be sending SIGHUP to re-read any changes to the files. The inotify code can be omitted entirely and --addn-hosts will still work, but --dhcp-hostsdir --dhcp-optsdir and --hostsdir options will be errored. Given that, I propose to take your patch to expand_filelist(), which will define the order for --dhcp-hostsfile --dhcp-optsfile and --addn-hosts when they take directories, but not the changes in inotify.c, which are not needed for that. Cheers, Simon. > Could it be that when inotify fires that it pulls in all files in > --addn-hosts? In which case the > dictionary order functions, even though we have inotify? > > 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] dnsmasq v2.86?
On 12/08/2021 13:34, Simon Kelley wrote: On 12/08/2021 12:23, Andre Heider wrote: Hm, works if I disable dnssec on dnsmask: dig thekelleys.org.uk ; <<>> DiG 9.16.15-Debian <<>> thekelleys.org.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7599 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ;; QUESTION SECTION: ;thekelleys.org.uk. IN A ;; ANSWER SECTION: thekelleys.org.uk. 36717 IN A 85.119.82.65 ;; Query time: 3 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Thu Aug 12 13:12:28 CEST 2021 ;; MSG SIZE rcvd: 62 But with it enabled: dig thekelleys.org.uk ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.16.15-Debian <<>> thekelleys.org.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 34170 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; EDE: 14 (Not Ready) ;; QUESTION SECTION: ;thekelleys.org.uk. IN A ;; Query time: 7 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Thu Aug 12 13:13:18 CEST 2021 ;; MSG SIZE rcvd: 52 It works with dnssec enabled but 'ednspacket_max 1280' removed... This may be getting closer to the original problem. What do the query logs look like when that fails? Also is stubby handling queries on TCP OK? dnsmasq[20540]: query[A] thekelleys.org.uk from 192.168.0.40 dnsmasq[20540]: forwarded thekelleys.org.uk to 127.0.0.1 dnsmasq[20540]: dnssec-query[DS] uk to 127.0.0.1 dnsmasq[20540]: dnssec-query[DNSKEY] . to 127.0.0.1 dnsmasq[20540]: reply . is DNSKEY keytag 26838, algo 8 dnsmasq[20540]: reply . is DNSKEY keytag 20326, algo 8 dnsmasq[20540]: reply uk is DS keytag 43876, algo 8, digest 2 dnsmasq[20540]: dnssec-query[DS] org.uk to 127.0.0.1 dnsmasq[20540]: dnssec-query[DNSKEY] uk to 127.0.0.1 dnsmasq[20540]: reply uk is DNSKEY keytag 43056, algo 8 dnsmasq[20540]: reply uk is DNSKEY keytag 43876, algo 8 dnsmasq[20540]: reply org.uk is DS keytag 41523, algo 8, digest 2 dnsmasq[20540]: dnssec-query[DS] thekelleys.org.uk to 127.0.0.1 dnsmasq[20540]: dnssec-query[DNSKEY] org.uk to 127.0.0.1 dnsmasq[20540]: reply org.uk is DNSKEY keytag 41523, algo 8 dnsmasq[20540]: reply thekelleys.org.uk is DS keytag 60318, algo 10, digest 2 dnsmasq[20540]: reply thekelleys.org.uk is DS keytag 7713, algo 10, digest 2 dnsmasq[20540]: dnssec-query[DNSKEY] thekelleys.org.uk to 127.0.0.1 dnsmasq[20540]: reply thekelleys.org.uk is 85.119.82.65 dig @127.0.0.1 -p 5453 +vc thekelleys.org.uk ; <<>> DiG 9.17.13 <<>> @127.0.0.1 -p 5453 +vc thekelleys.org.uk ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9671 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;thekelleys.org.uk. IN A ;; ANSWER SECTION: thekelleys.org.uk. 34162 IN A 85.119.82.65 ;; Query time: 170 msec ;; SERVER: 127.0.0.1#5453(127.0.0.1) (TCP) ;; WHEN: Thu Aug 12 13:55:03 CEST 2021 ;; MSG SIZE rcvd: 62 To be honest I'm not sure why I added --edns-packet-max=1280. It may have been just because of dnsmasq logging about reducing packet sizes to syslog over and over again? ___ 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 v2.86?
On 12/08/2021 12:23, Andre Heider wrote: >> Hm, works if I disable dnssec on dnsmask: >> >> dig thekelleys.org.uk >> >> ; <<>> DiG 9.16.15-Debian <<>> thekelleys.org.uk >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7599 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 1280 >> ;; QUESTION SECTION: >> ;thekelleys.org.uk. IN A >> >> ;; ANSWER SECTION: >> thekelleys.org.uk. 36717 IN A 85.119.82.65 >> >> ;; Query time: 3 msec >> ;; SERVER: 192.168.0.1#53(192.168.0.1) >> ;; WHEN: Thu Aug 12 13:12:28 CEST 2021 >> ;; MSG SIZE rcvd: 62 >> >> >> But with it enabled: >> >> dig thekelleys.org.uk >> ;; Truncated, retrying in TCP mode. >> >> ; <<>> DiG 9.16.15-Debian <<>> thekelleys.org.uk >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 34170 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ; EDE: 14 (Not Ready) >> ;; QUESTION SECTION: >> ;thekelleys.org.uk. IN A >> >> ;; Query time: 7 msec >> ;; SERVER: 192.168.0.1#53(192.168.0.1) >> ;; WHEN: Thu Aug 12 13:13:18 CEST 2021 >> ;; MSG SIZE rcvd: 52 > > It works with dnssec enabled but 'ednspacket_max 1280' removed... > This may be getting closer to the original problem. What do the query logs look like when that fails? Also is stubby handling queries on TCP OK? dig @127.0.0.1 -p 5453 +vc thekelleys.org.uk 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] dnsmasq v2.86?
On 12/08/2021 10:48, Kevin Darbyshire-Bryant wrote: > > # RFC6761 included configuration file for dnsmasq > # > # includes a list of domains that should not be forwarded to Internet name > servers > # to reduce burden on them, asking questions that they won't know the answer > to. > > server=/bind/ > server=/invalid/ > server=/local/ > server=/localhost/ > server=/onion/ > server=/test/ > > I wrote it :-) > That's what I see on my systems. I just wondered of arpa had got in there on Andre's. 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] dnsmasq v2.86?
On 12/08/2021 13:17, Andre Heider wrote: On 12/08/2021 12:58, Simon Kelley wrote: On 12/08/2021 11:34, Andre Heider wrote: On 12/08/2021 11:33, Simon Kelley wrote: On 12/08/2021 09:50, Dominik wrote: Hey Andre, Do you have a chance to run latest master code or are you bound to test tags on your system? I just tagged the latest code as 2.86test7, in case that helps. It may? But your httpd seems down, at least for me? Working here, and no evidence of problems in the logs. Are you still seeing errors? Hm, works if I disable dnssec on dnsmask: dig thekelleys.org.uk ; <<>> DiG 9.16.15-Debian <<>> thekelleys.org.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7599 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ;; QUESTION SECTION: ;thekelleys.org.uk. IN A ;; ANSWER SECTION: thekelleys.org.uk. 36717 IN A 85.119.82.65 ;; Query time: 3 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Thu Aug 12 13:12:28 CEST 2021 ;; MSG SIZE rcvd: 62 But with it enabled: dig thekelleys.org.uk ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.16.15-Debian <<>> thekelleys.org.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 34170 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; EDE: 14 (Not Ready) ;; QUESTION SECTION: ;thekelleys.org.uk. IN A ;; Query time: 7 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Thu Aug 12 13:13:18 CEST 2021 ;; MSG SIZE rcvd: 52 It works with dnssec enabled but 'ednspacket_max 1280' removed... ___ 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 v2.86?
On 12/08/2021 12:58, Simon Kelley wrote: On 12/08/2021 11:34, Andre Heider wrote: On 12/08/2021 11:33, Simon Kelley wrote: On 12/08/2021 09:50, Dominik wrote: Hey Andre, Do you have a chance to run latest master code or are you bound to test tags on your system? I just tagged the latest code as 2.86test7, in case that helps. It may? But your httpd seems down, at least for me? Working here, and no evidence of problems in the logs. Are you still seeing errors? Hm, works if I disable dnssec on dnsmask: dig thekelleys.org.uk ; <<>> DiG 9.16.15-Debian <<>> thekelleys.org.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7599 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ;; QUESTION SECTION: ;thekelleys.org.uk. IN A ;; ANSWER SECTION: thekelleys.org.uk. 36717 IN A 85.119.82.65 ;; Query time: 3 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Thu Aug 12 13:12:28 CEST 2021 ;; MSG SIZE rcvd: 62 But with it enabled: dig thekelleys.org.uk ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.16.15-Debian <<>> thekelleys.org.uk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 34170 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; EDE: 14 (Not Ready) ;; QUESTION SECTION: ;thekelleys.org.uk. IN A ;; Query time: 7 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Thu Aug 12 13:13:18 CEST 2021 ;; MSG SIZE rcvd: 52 ___ 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 v2.86?
On 12/08/2021 11:33, Simon Kelley wrote: On 12/08/2021 09:50, Dominik wrote: Hey Andre, Do you have a chance to run latest master code or are you bound to test tags on your system? I just tagged the latest code as 2.86test7, in case that helps. It may? But your httpd seems down, at least for me? 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
Re: [Dnsmasq-discuss] dnsmasq v2.86?
On 12/08/2021 11:06, Simon Kelley wrote:
This is useful information, but the backtraces are puzzling: the code
isn't in tight loop, certainly.
I wonder if the v4only.arpa thing is not a coincidence?
Some things to try, please.
1) When the dnsmasq process is faulted, run
strace -p
Will do, so far I haven't been able to reproduce the issue today...
2) Try doing a query on ipv4only.arpa to dnsmasq directly, just in case
that's the whole trigger.
3) Same but straight to stubby
dig @127.0.0.1 -p 5453 ipv4only.arpa
Both work just fine, so maybe that was just a red herring.
4) Take a look in /usr/share/dnsmasq/rfc6761.conf
Is .arpa mentioned in there?
Nope, it's the default file as Kevin pasted
Cheers,
Simon.
On 11/08/2021 15:50, Andre Heider wrote:
On 11/08/2021 16:19, Andre Heider wrote:
Hi there,
it seems I can trigger this semi-reliably while powering up 2 KVM
windows instances in parallel.
This is the tail of log-queries:
dnsmasq[6591]: query[A] foo.internal from 192.168.0.foo
dnsmasq[6591]: DHCP foo.internal is 192.168.0.foo
dnsmasq[6591]: query[] foo.internal from 192.168.0.foo
dnsmasq[6591]: config foo.internal is NODATA-IPv6
dnsmasq[6591]: query[A] ipv4only.arpa from 192.168.0.foo
And this is where dnsmasq stop replying altogether and hogs the cpu.
Note that foo.internal is the kvm host with the ip 192.168.0.foo.
Using gdbserver doesn't yield too much info, looks like because of lto
maybe (which OpenWrt does for dnsmasq)?
(gdb) info threads
Id Target Id Frame
* 1 Thread 6591.6591 "dnsmasq" 0x555715f1 in forward_query.lto_priv ()
(gdb) bt full
#0 0x555715f1 in forward_query.lto_priv ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)
Without LTO, another hang with the last log-queries 'dnsmasq[6842]:
query[A] ipv4only.arpa from 192.168.0.foo' again:
#0 0x55568969 in forward_query (udpfd=,
udpaddr=0x7fffbab8, dst_addr=0x7fffbaa8, dst_iface=15,
header=0x5561c080, plen=31, limit=0x5561c280 "", now=958007,
forward=0x5563e8e0, ad_reqd=0, do_bit=0) at forward.c:319
is_sign = 1432469663
pheader = 0x0
flags = 0
fwd_flags =
is_dnssec = 0
master =
gotname = 128
hash = 0x55624a10
oph = 0x0
old_src =
first = 1432469663
last = 12
start = 0
subnet = 0
cacheable = 1431977952
forwarded = 0
edns0_len = 1431725623
pheader = 0x80088
ede = -1
#1 0x5556947d in receive_query (listen=0x5561f5c0, now=958007) at
forward.c:1640
ad_reqd = 0
header = 0x5561c080
source_addr = {sa = {sa_family = 2, sa_data =
"\306d\300\250\000(\000\000\000\000\000\000\000"}, in = {sin_family = 2,
sin_port = 50788, sin_addr = {s_addr = 3232235560}, sin_zero =
"\000\000\000\000\000\000\000"}, in6 = {sin6_family = 2, sin6_port =
50788, sin6_flowinfo = 3232235560, sin6_addr = {
__in6_union = {__s6_addr =
"\000\000\000\000\000\000\000\000\000\000\001Ww\347", , __s6_addr16 = {0, 0, 0, 0, 0, 343, 30695, 3824},
__s6_addr32 = {0, 0, 343, 2011631344}}}, sin6_scope_id = 8162}}
pheader = 0x7fffbb68 "UZ?\340w\373+x"
type = 1
udp_size =
dst_addr = {addr4 = {s_addr = 3232235521}, addr6 = {__in6_union
= {__s6_addr =
"\300\250\000\001a\023\340\345\000\004\024\231w\354\066\240",
__s6_addr16 = {49320, 1, 24851, 57573, 4, 5273, 30700, 13984},
__s6_addr32 = {3232235521, 1628692709, 267417, 2011969184}}}, cname =
{target = {cache = 0xc0a80001,
name = 0xc0a80001 }, uid = 1628692709, is_name_ptr = 267417}, key = {keydata =
0xc0a80001, keylen = 24851, flags = 57573, keytag = 4, algo = 20
'\024'}, ds = {keydata = 0xc0a80001, keylen = 24851, keytag = 57573,
algo = 0 '\000', digest = 4 '\004'},
srv = {target = 0xc0a80001, targetlen = 24851, srvport =
57573, priority = 4, weight = 5273}, log = {keytag = 49320, algo = 1,
digest = 24851, rcode = 57573, ede = 267417}}
netmask = {s_addr = }
dst_addr_4 = {s_addr = 3232235521}
m = 0
n = 31
if_index = 15
auth_dns = 0
do_bit = 0
have_pseudoheader = 0
mark = 0
have_mark = 0
is_single_query =
allowed =
local_auth =
iov = {{iov_base = 0x5561c080, iov_len = 1280}}
msg = {msg_name = 0x7fffbab8, msg_namelen = 16, msg_iov =
0x7fffbaa0, msg_iovlen = 1, msg_control = 0x7fffbad4, msg_controllen =
24, msg_flags = 0}
cmptr =
control_u = {align = {cmsg_len = 24, cmsg_level = 0, cmsg_type =
8}, control6 =
"\000\000\000\030\000\000\000\000\000\000\000\b\000\000\000\017\300\250\000\001\300\250\000\001\000\000\000\030\000\000\000",
control =
"\000\000\000\030\000\000\000\000\000\000\000\b\000\000\000\017\300\250\000\001\300\250\000\001"}
family =
check_dst =
#2
Re: [Dnsmasq-discuss] dnsmasq v2.86?
On 12/08/2021 11:34, Andre Heider wrote: > On 12/08/2021 11:33, Simon Kelley wrote: >> >> >> On 12/08/2021 09:50, Dominik wrote: >>> Hey Andre, >>> >> >>> Do you have a chance to run latest master code or are you bound to test >>> tags on your system? >> >> I just tagged the latest code as 2.86test7, in case that helps. > > It may? But your httpd seems down, at least for me? > Working here, and no evidence of problems in the logs. Are you still seeing errors? 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] dnsmasq v2.86?
> On 12 Aug 2021, at 10:06, Simon Kelley wrote: > > This is useful information, but the backtraces are puzzling: the code > isn't in tight loop, certainly. > > > I wonder if the v4only.arpa thing is not a coincidence? > > Some things to try, please. > > 1) When the dnsmasq process is faulted, run > > strace -p > > 2) Try doing a query on ipv4only.arpa to dnsmasq directly, just in case > that's the whole trigger. > > 3) Same but straight to stubby > > dig @127.0.0.1 -p 5453 ipv4only.arpa > > > 4) Take a look in /usr/share/dnsmasq/rfc6761.conf > > Is .arpa mentioned in there? For reference, the default content is # RFC6761 included configuration file for dnsmasq # # includes a list of domains that should not be forwarded to Internet name servers # to reduce burden on them, asking questions that they won't know the answer to. server=/bind/ server=/invalid/ server=/local/ server=/localhost/ server=/onion/ server=/test/ I wrote it :-) Kevin signature.asc Description: Message signed with OpenPGP ___ 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 v2.86?
On 12/08/2021 09:50, Dominik wrote: > Hey Andre, > > Do you have a chance to run latest master code or are you bound to test > tags on your system? I just tagged the latest code as 2.86test7, in case that helps. 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] dnsmasq v2.86?
This is useful information, but the backtraces are puzzling: the code
isn't in tight loop, certainly.
I wonder if the v4only.arpa thing is not a coincidence?
Some things to try, please.
1) When the dnsmasq process is faulted, run
strace -p
2) Try doing a query on ipv4only.arpa to dnsmasq directly, just in case
that's the whole trigger.
3) Same but straight to stubby
dig @127.0.0.1 -p 5453 ipv4only.arpa
4) Take a look in /usr/share/dnsmasq/rfc6761.conf
Is .arpa mentioned in there?
Cheers,
Simon.
On 11/08/2021 15:50, Andre Heider wrote:
> On 11/08/2021 16:19, Andre Heider wrote:
>> Hi there,
>>
>> it seems I can trigger this semi-reliably while powering up 2 KVM
>> windows instances in parallel.
>>
>> This is the tail of log-queries:
>> dnsmasq[6591]: query[A] foo.internal from 192.168.0.foo
>> dnsmasq[6591]: DHCP foo.internal is 192.168.0.foo
>> dnsmasq[6591]: query[] foo.internal from 192.168.0.foo
>> dnsmasq[6591]: config foo.internal is NODATA-IPv6
>> dnsmasq[6591]: query[A] ipv4only.arpa from 192.168.0.foo
>>
>> And this is where dnsmasq stop replying altogether and hogs the cpu.
>> Note that foo.internal is the kvm host with the ip 192.168.0.foo.
>>
>> Using gdbserver doesn't yield too much info, looks like because of lto
>> maybe (which OpenWrt does for dnsmasq)?
>> (gdb) info threads
>> Id Target Id Frame
>> * 1 Thread 6591.6591 "dnsmasq" 0x555715f1 in forward_query.lto_priv ()
>> (gdb) bt full
>> #0 0x555715f1 in forward_query.lto_priv ()
>> No symbol table info available.
>> Backtrace stopped: previous frame identical to this frame (corrupt
>> stack?)
>
> Without LTO, another hang with the last log-queries 'dnsmasq[6842]:
> query[A] ipv4only.arpa from 192.168.0.foo' again:
>
> #0 0x55568969 in forward_query (udpfd=,
> udpaddr=0x7fffbab8, dst_addr=0x7fffbaa8, dst_iface=15,
> header=0x5561c080, plen=31, limit=0x5561c280 "", now=958007,
> forward=0x5563e8e0, ad_reqd=0, do_bit=0) at forward.c:319
> is_sign = 1432469663
> pheader = 0x0
> flags = 0
> fwd_flags =
> is_dnssec = 0
> master =
> gotname = 128
> hash = 0x55624a10
> oph = 0x0
> old_src =
> first = 1432469663
> last = 12
> start = 0
> subnet = 0
> cacheable = 1431977952
> forwarded = 0
> edns0_len = 1431725623
> pheader = 0x80088
> ede = -1
> #1 0x5556947d in receive_query (listen=0x5561f5c0, now=958007) at
> forward.c:1640
> ad_reqd = 0
> header = 0x5561c080
> source_addr = {sa = {sa_family = 2, sa_data =
> "\306d\300\250\000(\000\000\000\000\000\000\000"}, in = {sin_family = 2,
> sin_port = 50788, sin_addr = {s_addr = 3232235560}, sin_zero =
> "\000\000\000\000\000\000\000"}, in6 = {sin6_family = 2, sin6_port =
> 50788, sin6_flowinfo = 3232235560, sin6_addr = {
> __in6_union = {__s6_addr =
> "\000\000\000\000\000\000\000\000\000\000\001Ww\347", sequence \360>, __s6_addr16 = {0, 0, 0, 0, 0, 343, 30695, 3824},
> __s6_addr32 = {0, 0, 343, 2011631344}}}, sin6_scope_id = 8162}}
> pheader = 0x7fffbb68 "UZ?\340w\373+x"
> type = 1
> udp_size =
> dst_addr = {addr4 = {s_addr = 3232235521}, addr6 = {__in6_union
> = {__s6_addr =
> "\300\250\000\001a\023\340\345\000\004\024\231w\354\066\240",
> __s6_addr16 = {49320, 1, 24851, 57573, 4, 5273, 30700, 13984},
> __s6_addr32 = {3232235521, 1628692709, 267417, 2011969184}}}, cname =
> {target = {cache = 0xc0a80001,
> name = 0xc0a80001 0xc0a80001>}, uid = 1628692709, is_name_ptr = 267417}, key = {keydata =
> 0xc0a80001, keylen = 24851, flags = 57573, keytag = 4, algo = 20
> '\024'}, ds = {keydata = 0xc0a80001, keylen = 24851, keytag = 57573,
> algo = 0 '\000', digest = 4 '\004'},
> srv = {target = 0xc0a80001, targetlen = 24851, srvport =
> 57573, priority = 4, weight = 5273}, log = {keytag = 49320, algo = 1,
> digest = 24851, rcode = 57573, ede = 267417}}
> netmask = {s_addr = }
> dst_addr_4 = {s_addr = 3232235521}
> m = 0
> n = 31
> if_index = 15
> auth_dns = 0
> do_bit = 0
> have_pseudoheader = 0
> mark = 0
> have_mark = 0
> is_single_query =
> allowed =
> local_auth =
> iov = {{iov_base = 0x5561c080, iov_len = 1280}}
> msg = {msg_name = 0x7fffbab8, msg_namelen = 16, msg_iov =
> 0x7fffbaa0, msg_iovlen = 1, msg_control = 0x7fffbad4, msg_controllen =
> 24, msg_flags = 0}
> cmptr =
> control_u = {align = {cmsg_len = 24, cmsg_level = 0, cmsg_type =
> 8}, control6 =
> "\000\000\000\030\000\000\000\000\000\000\000\b\000\000\000\017\300\250\000\001\300\250\000\001\000\000\000\030\000\000\000",
>
> control =
> "\000\000\000\030\000\000\000\000\000\000\000\b\000\000\000\017\300\250\000\001\300\250\000\001"}
>
> family =
> check_dst =
> #2 0x5556c853 in
Re: [Dnsmasq-discuss] dnsmasq v2.86?
Hey Andre,
On Wed, 2021-08-11 at 16:50 +0200, Andre Heider wrote:
> Continuing and breaking again about 30 times mostly yields line 319 as
> above (which is 'difftime(now, master->forwardtime) > FORWARD_TIME ||')
>
> A few times it hits 341 though ('while (forward->blocking_query)'):
Do you have a chance to run latest master code or are you bound to test
tags on your system?
I don't (yet) think there is a loop going nuts, could you add a
breakpoint to the call to forward_query() in receive_query() and check
if the function is just repeatedly called? And, if so, do it one
further level down in the backtrace (break in check_dns_listeners()
where receive_query() is called, etc.) so we can see where the issue
is.
When you got the right one, there should be no CPU core spinning as you
will always end up in the breakpoint immediately.
Best,
Dominik
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
