>that out of rotation, prodding every so often to see >if it's back online
>I'm sure implementation might not be. I'm sure it is implemented. Read all changelogs for the last years! To see how it works - switch on 'DNSResponseLog' and set 'MaintenanceLog' to diagnostic.. >Why have 3x the DNS workload? SPEED !? I agree, 3 or more times the workload is too much - 2 time would be enough. I like the idea to limit the number of nameservers used, instead of using all nameservers all times. This makes it possible to define for example 5 DNS-server or even more, but limit the usage to the still in time fastest 2 or 1 or any other number (hmmm... one is not nice). Assume we limit to two DNS-server. As long as any of the both is answering - fine - but the first worker, that detects a DNS problem, will force the recheck and reordering of the all defined nameserver. Per default, assp checks all defined nameservers once in a minute. Thomas Von: K Post <nntp.p...@gmail.com> An: ASSP development mailing list <assp-test@lists.sourceforge.net> Datum: 21.05.2015 21:29 Betreff: Re: [Assp-test] More MX and A record lookup issues >>an optimization in my opinion of network resources >>I don't care about your network resources - or any other resources - any longer. This time has gone. Ouch. You are the expert, I can only ask questions and seek your advice - and sometimes that spurs a new way of thinking or doing things for ASSP. You've made some significant (to me) changes to ASSP based on some of my (incessant) prodding. Thank you for that. I don't believe that you don't care about network resources, mine or otherwise. I simply don't buy it. Maybe you want me to shut up about this, or take a break, but you know that network resources are important, especially when they're limited for a charity for example. If we don't have to work servers any more than >>necessary<< we shouldn't - you can't possibly disagree with that. Why have 3x the DNS workload? If a server goes down for maintenance, we try another and take that out of rotation, prodding every so often to see if it's back online. Simple concept, I'm sure implementation might not be. I'll stop, but I have a feeling that upon review, you'll see that what I'm saying IN CONCEPT makes sense. Whether that's something you want to do, is up to you. On Thu, May 21, 2015 at 9:42 AM, Thomas Eckardt <thomas.ecka...@thockar.com> wrote: > >I had turned off the reuse > > this is no longer required with latest dev build. > > >and only enabled when the > admin knows that the DNS servers are local > > If I would trust the knowledge of the assp admins, the core code of assp > would be the half. > > >Are you seeing situations where >internal< dns > servers regularly are failing? > > Yes - for example, simply some downtime. > > >Maybe you could consider giving us the > option to first query the fastest responding server > > No. The reason is simple. In truth, assp uses three different DNS-engines, > each one optimized for its usage and speed. Each one working a bit > different. > > >an optimization in my opinion of network resources > > I don't care about your network resources - or any other resources - any > longer. This time has gone. > > Thomas > > > > > > Von: K Post <nntp.p...@gmail.com> > An: ASSP development mailing list <assp-test@lists.sourceforge.net> > Datum: 21.05.2015 15:09 > Betreff: Re: [Assp-test] More MX and A record lookup issues > > > > Thanks for the explanation. I had turned off the reuse of the dns > connections (as per your suggestion when I saw the problem) and it's still > querying all 3 servers fyi. > > No question, ASSP needs fast and reliable DNS servers. If you're using > dns > servers external to the organization or with latency issues due, I could > see trying multiple at once in the interest of speed and reliability - > ASSP > needs to come first - a way higher priority that keeping DNS queries low. > But, if all DNS servers are internal and reliable, why cause what I'm > calling "extra traffic?" Redundant dns queries inside the network cause > additional internal traffic (which I don't care about), but then sends > additional dns traffic outside when those internal servers query the root > servers and ultimately the authoritative servers for each hostname. > > No one has ever complained to me about the DNS server load caused by ASSP, > so we're good there - and believe me, i would hear it if I was doing > anything to cause an unreasonable load. I just hate waste and feel like > we > could reduce the number of queries by approximately (N-1)/N where N is the > number of dns servers assuming more than 1 in an environment where all > servers are internal, reliable, and of similar fast speed. > > A couple weeks ago I asked about retrying DNS if there's no result, and > now > I know why you said it was so silly, because we're already trying multiple > times to each DNS server!! Why not just try once and if there's not a > reply in a reasonable amount of time, then try the other servers, maybe > even at the same time? Are you seeing situations where >internal< dns > servers regularly are failing? Maybe you could consider giving us the > option to first query the fastest responding server (which you said ASSP > already keeps track of) and if that doesn't reply, time the others and use > their results?? Periodically query all N to check on speed. That would > be > an optimization in my opinion of network resources and I don't >>think<< > it > would slow down ASSP if implemented properly and only enabled when the > admin knows that the DNS servers are local, reliable, and fast. > > With 100k messages, why have as least 3 million queries total with 3 DNS > servers, when we could reduce that average to as low as 1 million? I > don't > think ASSP would be negatively impacted. You do? > > On Thu, May 21, 2015 at 4:38 AM, Thomas Eckardt > <thomas.ecka...@thockar.com> > wrote: > > > >(round robin or randomly selected) > > > > ASSP is smarter - it knows how fast the DNS-servers are answering and > uses > > the fastest first. If a name server can't be reached - it is removed > from > > the querylist for some time. > > As long as the nameserver order is not changed, it tries to use > permanent > > sockets. Because DNS-queries are also done by many other Perl modules > > (Mail::SPF for example), it redirects there calls to its own DNS-engine > > instead using the default Perl DNS implementation. > > > > > > >would be a more standard implementation of DNS queries > > > > What a standard - what RFC? Not the OS, the applications makes the > rules. > > Each app may handle DNS queries different. By the way, the Net::DNS > module > > in Perl works the same way. > > ASSP V2 is designed to be as fast as possible - it has not the time to > > wait for slow DNS-servers. > > As an ASSP admin you have to know, that assp will produce up to 100 DNS > > queries for a single mail (depends on the enabled features and there > > configuration). > > So if your assp handles 100.000 mails a day, the used DNS-Servers must > be > > able to answer 10.000.000 queries a day (but at least 1.000.000 !) > > > > An day has 86400 seconds and the default DNS-Timeout is two seconds - I > > think the numbers are selfexplaining. > > > > Thomas > > > > > > > > > > > > > > > > Von: K Post <nntp.p...@gmail.com> > > An: ASSP development mailing list <assp-test@lists.sourceforge.net> > > Datum: 21.05.2015 06:05 > > Betreff: Re: [Assp-test] More MX and A record lookup issues > > > > > > > > I ask if it's normal because I don't (or didn't know). It's illogical > to > > me that it does, so I find the question perfectly reasonable. > > > > I assumed that we'd want ASSP to try one of the DNS servers at a time, > > especially if we're using internal DNS servers. If for some reason that > > selected DNS server (round robin or randomly selected) times out, remove > > it > > from the rotation for a while so it's not a source of constant delay, > and > > try the next dns server. ASSP shouldn't be using internal dns servers > > that > > aren't reliable. I specify multiple just so that a single point of > > failure > > doesn't bring down ASSP. > > > > Querying one at a time would allow multiple DNS servers listed for > backup > > purposes only without increasing the DNS query load unnecessarily* I > > would think that would be a more standard implementation of DNS queries > in > > general. Isn't that the way Windows and Linux workstations and servers > > operate normally? If you've got 3 dns servers in windows and do a dns > > lookup, it asks one server (as far as I understand it). If that times > > out, > > it moves on to the next. I can't say that I've ever seen (or noticed) a > > server querying every DNS server it is assigned to use with the same > query > > every time. > > > > *I say "unecessarily" becuase >>I<< don't think it's necessary, but > if > > I'm off base on this concept I'd love to understand why. > > > > Anyway, I'm glad that my incessant questions keep finding these minor > yet > > potentially impactful bugs that your continually able to diagnose and > fix > > - > > and quickly. Thanks so much for that. > > > > > > On Wed, May 20, 2015 at 10:34 AM, Thomas Eckardt > > <thomas.ecka...@thockar.com > > > wrote: > > > > > >is it normal for each query > > > to ask each server?? > > > > > > You should be able to answer this question yourself!!! > > > > > > Yes - what else makes sense? > > > > > > The logic is: query all-> wait - use the first result - repeat all if > > > failed. - max time = DNSTimeout * DNSretry > > > > > > Otherwise it would be: query the first NS -> wait for result > (NO-result) > > > -> query next NS -> wait .... Next....Next ... LAST -> repeat all if > > > failed - max time = DNSTimeout * Nameserver * DNSretry > > > > > > But I found a BUG in assp. Because DNS uses UDP the order of the > answers > > > of a DNS server must not be the same like the order of the queries, if > > > multiple queries are done using the same socket. > > > This is currently not expected by assp - it ignores the DNS header-ID, > > if > > > the DNS sockets are reused. The next build will fix this. > > > > > > Thomas > > > > > > > > > > > > Von: K Post <nntp.p...@gmail.com> > > > An: ASSP development mailing list > <assp-test@lists.sourceforge.net> > > > Datum: 19.05.2015 23:19 > > > Betreff: Re: [Assp-test] More MX and A record lookup issues > > > > > > > > > > > > Thomas, I'll disable the reuse socket option. is it normal for each > > query > > > to ask each server?? > > > > > > The self loader was removed a long time ago. > > > > > > On Tue, May 19, 2015 at 5:16 PM, K Post <nntp.p...@gmail.com> wrote: > > > > > > > Thanks for the question Bob, but nope, they're straight WIndows 2012 > > R2 > > > > DNS servers. no dnsmasq. > > > > > > > > On Tue, May 19, 2015 at 1:08 PM, Robert K Coffman Jr. -Info From > Data > > > > Corp. <bcoff...@infofromdata.com> wrote: > > > > > > > >> > > > >> > May-19-15 11:41:26 Info: sent DNS query for > '_dmarc.my.orbitz.com' > > > type > > > >> > 'TXT' to nameserver 172.23.0.52 > > > >> > May-19-15 11:41:26 Info: reuse DNS socket for 172.23.0.53 > > > >> > > > >> By any chance, are you running DNSMASQ on your DNS servers? > > > >> > > > >> - Bob > > > >> > > > >> > > > >> > > > >> > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > >> One dashboard for servers and applications across > > > Physical-Virtual-Cloud > > > >> Widest out-of-the-box monitoring support with 50+ applications > > > >> Performance metrics, stats and reports that give you Actionable > > > Insights > > > >> Deep dive visibility with transaction tracing using APM Insight. > > > >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > >> _______________________________________________ > > > >> Assp-test mailing list > > > >> Assp-test@lists.sourceforge.net > > > >> https://lists.sourceforge.net/lists/listinfo/assp-test > > > >> > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > One dashboard for servers and applications across > Physical-Virtual-Cloud > > > Widest out-of-the-box monitoring support with 50+ applications > > > Performance metrics, stats and reports that give you Actionable > Insights > > > Deep dive visibility with transaction tracing using APM Insight. > > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > _______________________________________________ > > > Assp-test mailing list > > > Assp-test@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/assp-test > > > > > > > > > > > > > > > > > > > > > DISCLAIMER: > > > ******************************************************* > > > This email and any files transmitted with it may be confidential, > > legally > > > privileged and protected in law and are intended solely for the use of > > the > > > > > > individual to whom it is addressed. > > > This email was multiple times scanned for viruses. There should be no > > > known virus in this email! > > > ******************************************************* > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > One dashboard for servers and applications across > Physical-Virtual-Cloud > > > Widest out-of-the-box monitoring support with 50+ applications > > > Performance metrics, stats and reports that give you Actionable > Insights > > > Deep dive visibility with transaction tracing using APM Insight. > > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > _______________________________________________ > > > Assp-test mailing list > > > Assp-test@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/assp-test > > > > > > > > > ------------------------------------------------------------------------------ > > One dashboard for servers and applications across Physical-Virtual-Cloud > > Widest out-of-the-box monitoring support with 50+ applications > > Performance metrics, stats and reports that give you Actionable Insights > > Deep dive visibility with transaction tracing using APM Insight. > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > _______________________________________________ > > Assp-test mailing list > > Assp-test@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/assp-test > > > > > > > > > > > > > > DISCLAIMER: > > ******************************************************* > > This email and any files transmitted with it may be confidential, > legally > > privileged and protected in law and are intended solely for the use of > the > > > > individual to whom it is addressed. > > This email was multiple times scanned for viruses. There should be no > > known virus in this email! > > ******************************************************* > > > > > > > > ------------------------------------------------------------------------------ > > One dashboard for servers and applications across Physical-Virtual-Cloud > > Widest out-of-the-box monitoring support with 50+ applications > > Performance metrics, stats and reports that give you Actionable Insights > > Deep dive visibility with transaction tracing using APM Insight. > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > _______________________________________________ > > Assp-test mailing list > > Assp-test@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/assp-test > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Assp-test mailing list > Assp-test@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/assp-test > > > > > > > DISCLAIMER: > ******************************************************* > This email and any files transmitted with it may be confidential, legally > privileged and protected in law and are intended solely for the use of the > > individual to whom it is addressed. > This email was multiple times scanned for viruses. There should be no > known virus in this email! > ******************************************************* > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Assp-test mailing list > Assp-test@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/assp-test > ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Assp-test mailing list Assp-test@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-test DISCLAIMER: ******************************************************* This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the individual to whom it is addressed. This email was multiple times scanned for viruses. There should be no known virus in this email! ******************************************************* ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Assp-test mailing list Assp-test@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-test
