From mboxrd@z Thu Jan 1 00:00:00 1970 From: "R. W. Rodolico" To: development@lists.ipfire.org Subject: Re: [PATCH] dnsmasq 2.75: next patch... (No.50) Date: Wed, 20 Jan 2016 21:39:39 -0600 Message-ID: <56A052FB.6050006@dailydata.net> In-Reply-To: <1453333881.585.9.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9198368842241496641==" List-Id: --===============9198368842241496641== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well, I don't know what a recursor is but you can use .194. It is currently not being used. Is this permanent, ie do I label it as "testing" or do you need it for a more permanent basis. If you need it permanently, that is fine; I just need to know how to label it in our database. On 01/20/2016 05:51 PM, Michael Tremer wrote: > Hi, > > I don't think that this is just *your* problem. > > So far we have had random crashes of dnsmasq on random machines. > Sometimes that happens three times in a row within 10 minutes. > Sometimes that doesn't happen for a few months. We have had this > with many name servers. Some of which have been reported to "work > better". Some of which have been reported to work "worse". That > also includes 8.8.8.8 and the LWL name servers. > > So it is just you who is having the troubles more often than > usual. Maybe that will go away soon. > > I am not fully convinced that the type of server plays a big role > in here. It might be something like the timing of the replies, etc. > What leads me to that idea is that the crashes are usually not > reproducible by a single query that goes wrong. > > I can set up a recursor on the machine you set up for me. Just give > it an additional IP address and I will setup the resolver. I am > maintaining a few already, so this won't hurt at all. > > Best, -Michael > > On Wed, 2016-01-20 at 12:58 -0600, R. W. Rodolico wrote: >> Ok. I just want to make sure this is not a local problem. >> >> Am I the only one who is having issues? If so, then all this work >> has been for nothing. I was under the impression that there were >> several reports of this issue, but if I'm the only one having the >> problem, then I'll rebuild the test router (my home office >> router) and we'll put effort into something else. >> >> Again, if several people are reporting it, it is something that >> needs to be fixed. But if I'm the only one with the issue, then >> it is probably *MY* problem, not a problem with something else. >> >> Fred, I agree, it looks like it is a problem with dnsmaq and >> certain DNS providers, but I'm using Google and Level 3 for my >> tests and it fails every couple of weeks. I'm suspicious of the >> DNS servers which make money off their services by putting ads up >> (which it appears Level 3 does. If you put an invalid domain name >> up, it comes up with an ad to purchase it. I have not looked at >> their traffic patterns to see what it is, but I had absolute no >> issues when I was using the German servers. >> >> So, if you think this is a one off, let's get off the issue and >> I'll work on *MY* problem. >> >> Let me know. >> >> Rod >> >> On 01/20/2016 12:23 PM, Kienker, Fred wrote: >>> The last update to dnsmasq has run fine on all of our IPFire >>> systems with the Google and Level 3 DNS servers for an extended >>> period of time. Could all of the issues be a conflict with the >>> dnsmasq code and *certain* DNS providers? If so this seems like >>> a much harder problem to fix. >>> >>> Fred >>> >>> -----Original Message----- From: Matthias Fischer >>> [mailto:matthias.fischer(a)ipfire.org] Sent: Tuesday, January 19, >>> 2016 2:59 PM To: development(a)lists.ipfire.org Subject: Re: >>> [PATCH] dnsmasq 2.75: next patch... (No.50) >>> >>> Hi, >>> >>> On 19.01.2016 08:39, R. W. Rodolico wrote: >>>> I installed this package yesterday and dnsmasq broke a few >>>> minutes >>> ago. >>>> About 24 hours. >>> >>> Worked for 24 hours and then crashed? Weird. But thinking of >>> it, this could be one of the reasons why its not crashing >>> *here*. Every 24 hours my ISP cuts the connection, and our >>> router gets a new IP and 'dnsmasq' restarts! >>> >>>> Strange thing: when I was using the servers you recommended >>>> 84.200.69.80, 84.200.70.40 I did not have any problems even >>>> though you >>> >>>> have been updating very frequently. However, I reverted to >>>> the old DNS >>> >>>> servers 209.244.0.3 8.8.4.4 and in less than a few days (I >>>> think I did it with the 15th or 14th update), it broke again. >>>> Those servers are, respectively, resolver1.level3.net and one >>>> of the google ones. >>> >>> So as I understand you, its related with the DNS servers you >>> use!? With your ISP servers, it crashes and with the german >>> servers, it doesn't? >>> >>>> Let me know if you want me to use the 84 DNS servers. Hell, I >>>> may just >>> >>>> decide to build my own caching DNS servers!!! >>> >>> Ok, solution found - that was easy... ;-)) >>> >>> But as long as I'm working on this, I'm more and more sure >>> that these intermediate crashes are really a combination >>> between the DNS servers and 'dnsmasq' itself. Sad to say, I >>> haven't got the (C-)skills to debug this. >>> >>> Right now, I'm trying to compile 'dnsmasq' with patches >>> 051-053: it now crashes in 'forward.c' during compilation if I >>> activate the DNSSEC-option (-e 's|/\* #define HAVE_DNSSEC >>> \*/|#define HAVE_DNSSEC|g' \). Reason: patch No.053, I think. >>> >>> In contrast, the '2.76test6'-version compiles without *any* >>> error, if I delete and disable *all* of our adjustments. >>> >>> As Simon wrote: "Conditional combination has a nasty >>> combinatorial explosion. I should hack up a regression test to >>> build all possible variants." >>> >>> But obviously this wasn't done yet. If I leave everything as it >>> is, its building... >>> >>> Perhaps I'll try another request on the dnsmasq-list during >>> the next days. The last one had no effect, no answers, >>> nothing. >>> >>> Best, Matthias >>> >>> >>> - -- Rod Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 http://www.dailydata.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlagUvsACgkQuVY3UpYMlTSyCQCfTczs4yUYQnVp4q0SDG04JlMT +4IAn3A0OXavE5z+nfvMB7G0xo05to+c =3XWJ -----END PGP SIGNATURE----- --===============9198368842241496641==--