In SIMS Digest #1532, Fokko van Duin <[EMAIL PROTECTED]> wrote: >The long wait we see on some HELO actions, is also happens at other places. I >noticed it while testing dnsreport.com. After a lengthy conversation with the >guy of dnsreport, I decided to log a SIMS <-> dnsreport.com session with a >packet sniffer in order to show him what is really going on. The sniffer log >file is not shown here as it is lengthy, but can be obtained from me, just let >me know.
Fokko saw my response on the list, and forwarded the EtherPeek trace to me. I took a look at the EtherPeek trace, and the 30-second delay is when SIMS attempts to find a Mail Exchanger after receiving: "RCPT TO: [EMAIL PROTECTED]" Since SIMS is not "example.com" (or, if it is, it is misconfigured!), it attempts to determine if that mail can be forwarded to its proper place. The answer _is_ a "NODATA (TYPE 2)" response, indicating that there IS no mail exchanger for "example.com". What the sniffer trace also shows is that this query/response continues. Since I am not familiar with the internal SIMS<->OpenTransport communication for resolving domain names, (but would love to learn more), I cannot say whether it is SIMS or the resolver in OpenTransport that does not understand the response and continues to issue queries. I'm not so convinced that the delays (and extra processing involved) in this case aren't the problem of the sender, rather than SIMS/OT attempting to find a Mail Exchanger for a bogus return address. Also, while the guy at DNS report seems to think that negative caching would help alleviate this problem, if the querier does not understand the response and happens to be on the same machine as your (negative-response- caching) DNS server, you'd merely move the problem to that machine (and effectively lock it up for 30 seconds!). As I stated in my last post, the actions of the offending DNS responder are dictated by an RFC that is not yet an Internet Standard, and until the results of such implementations can be made to be backward compatible with existing standard practice (i.e., following existing IETF standards), it is MHO that their implementation should be limited to "test beds", not foisted upon "The Rest of Us"..... On the other hand, it might be nice if Stalker (SIMS) and/or Apple (OT) -- whichever is the responsible party (or both, if that's the case) -- would correctly handle the "NODATA (TYPE 2)" response the same as it currently does a "NXDOMAIN" response, if RFC2038 _does_ appear to be close to becoming an IETF STD or the number of DNS servers exhibiting this behaviour becomes commonplace on the 'net. Michael A. Pasek Pasek Consulting, Inc. 9741 Foley Boulevard NW Coon Rapids, MN 55433-5616 (612) 597-5977 [EMAIL PROTECTED] ############################################################# This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
