{sigh} So of course, today (2019-02-10) I can't reproduce the error. I even went up to the Extreme (762213 entries) pak, and increased the DNS cache to 10000, and it's humming along perfectly.
It is increasing the first lookup speed from ~50-70ms to ~400-500ms, but I would consider that reasonable for a local lookup against 762213 entries! If you would, keep the case open another day, and I'll leave it running. Tomorrow it will be under greater load. Thanks!!! P.S. One question: When added via: conf-file=/etc/dnsmasq.d/hosts/hosts.block.dnsmasq.conf are those entries added to an in memory cache (separate from the lookup-cache I'm assuming?), or at first-lookup does the application read the file (or a hashed temp file it creates?) if the entry isn't already cached? The Extreme file is 29MB, yet my current memory usage is: total used free shared buff/cache available Mem: 16361824 401040 14150104 2052 1810680 15776944 Here's a dig lookup example: dig library.usc.edu @192.168.1.1 ; <<>> DiG 9.10.3-P4-Debian <<>> library.usc.edu @192.168.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14105 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1452 ;; QUESTION SECTION: ;library.usc.edu. IN A ;; ANSWER SECTION: library.usc.edu. 3600 IN CNAME usclibraries.usc.edu. usclibraries.usc.edu. 3600 IN A 128.125.183.98 ;; Query time: 559 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sun Feb 10 12:42:49 EST 2019 ;; MSG SIZE rcvd: 87 On Sun, Feb 10, 2019 at 8:17 AM Bernhard Übelacker <bernha...@mailbox.org> wrote: > Hello Zac Morris, > > >> Yeah, I didn't know how to update the case. Is there a web front-end for > >> updating/tracking the cases? I couldn't figure out how to do it via > email. > > You just need to send the answers also to 921...@bugs.debian.org > as receiver or CC. Then all the information is collected in this page: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921310 > > >> The dmesg output was: segfault error 4 (memory?) > > Is this the complete line in dmesg output? > > > Forwarding the information to the bug. > > Kind regards, > Bernhard > > > -------- Weitergeleitete Nachricht -------- > Betreff: Re: Bug#921310: dnsmasq "segment fault" bug when total conf > files size is too large > Datum: Sat, 9 Feb 2019 15:31:52 -0500 > Von: Zac Morris <z...@zacwolf.com> > An: Bernhard Übelacker <bernha...@mailbox.org> > > > > Yeah, I didn't know how to update the case. Is there a web front-end for > updating/tracking the cases? I couldn't figure out how to do it via email. > > The dmesg output was: segfault error 4 (memory?) > > So hopefully walking you through it might help? > > When I use the conf-file=parm in my config file to point to any of the > dnsmasq formatted block lists provided by https://energized.pro/#packs, > using anything larger than Basic (which contains about 466000 entries) > causes the segfault error 4 after just a few DNS queries. > > Using Basic doesn't cause the segfault, but from the machine running > dnsmasq, when I use a dig (using the Basic dnsmasq format file added via > conf-file= ) it adds over 500ms to the lookup. (I got 4 seconds once, > but haven't been able to replicate that again). I didn't use this setup > very long so it may have caused the segfault as well after some time. > > What I ended up doing is using the /etc/hosts version of the energized > files. > #my local static network devices > addn-hosts=/etc/dnsmasq.d/hosts/hosts.local > #Basic etc/hosts formated file provided by Energized.pro > addn-hosts=/etc/dnsmasq.d/hosts/hosts.block > > When I do that I'm getting an average new domain lookup of 23ms > non-dnssec, 65ms with dnssec), with 0ms on subsequent (cached, as > expected) lookups either way. > > I understand that dnsmasq is geared more towards small memory devices, > so this may not be a priority. > > It would seem that loading large address=based conf files causes a > segfault error 4 if it's too larger, but if it's large (but not too > larger) it adds substantial time to a lookup, but why would > using addn-hosts= with the the same huge ~466000 entries add no time to > the lookup nor cause an error 4? > > > I'm attaching my current lan.conf which is loaded from the default > /etc/dnsmasq.conf > > THANKS!!! > >