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
