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.
Here is the answer I got from Scott (dnsreport.com):
-------------
>FYI I included a packet dump and the mail server log what's going on
>here. I could not show you now dnsreport.com, as you are using now
>www.dnsreport.com, which responds quick.
Thank you -- this really helps in identifying the exact nature of the problem.
>You can clearly see now that using example.com requires VERY lengthy
>DNS conversation (because no A or MX record?)
No. It doesn't require a very lengthy DNS conversation.
It shows SIMS requesting the MX record for example.com at 1:35:19,
1:35:20, 1:35:21, and 1:35:23 (packets 34, 36, 37, 38), and finally
getting a response back from the DNS server at 1:35:23 (packet 39,
just under 4 seconds after the first request).
The first indication of a problem is that SIMS is making the request
4 times in less than 4 seconds, which is doesn't seem right (but, not
really worth worry about, since it doesn't affect the situation).
After 4 seconds, packet #39 is from your local DNS server (the one
SIMS does its lookups against, 194.134.5.5 dns.euro.net). That
packet is a "nodata" response, indicating that the example.com zone
exists, but that there are no MX records for it (it says "no error",
has 0 answers, and has the SOA record for example.com). At this
point, SIMS has all the information it needs.
But, you'll see what happens:
Packet #34- MX example.com Timestamp: 01:35:19.683224 11/03/01
Packet #36- MX example.com Timestamp: 01:35:20.165219 11/03/01
Packet #37- MX example.com Timestamp: 01:35:21.119568 11/03/01
Packet #38- MX example.com Timestamp: 01:35:23.015921 11/03/01
Packet #39- Answers MX Timestamp: 01:35:23.279129 11/03/01
This is the section we just covered.
Packet #40- MX example.com Timestamp: 01:35:26.852110 11/03/01
Packet #41- Answers MX Timestamp: 01:35:26.885453 11/03/01
Here, SIMS is asking one of example.com's nameservers for the MX
record for example.com -- but it shouldn't be doing this. It already
knows the answer.
But let's assume that for some reasons SIMS wanted an authoritative
answer. example.com's nameserver returns the same answer: a "nodata"
answer. SIMS definitely should stop here -- it has all the
information it can possibly get. But what happens next?
Packet #42 -MX example.com Timestamp: 01:35:34.463010 11/03/01
Packet #43 -Answers MX Timestamp: 01:35:34.662082 11/03/01
Again, it goes to example.com's nameserver, asks for the MX record
for example.com, and gets the same response. And then:
Packet #44 -MX example.com Timestamp: 01:35:34.944507 11/03/01
Packet #45 -Answers MX Timestamp: 01:35:35.145838 11/03/01
Packet #46 -MX example.com Timestamp: 01:35:35.898047 11/03/01
Packet #47 -Answers MX Timestamp: 01:35:36.084107 11/03/01
Packet #48 -MX example.com Timestamp: 01:35:37.796716 11/03/01
Packet #49 -Answers MX Timestamp: 01:35:37.994776 11/03/01
Packet #50 -MX example.com Timestamp: 01:35:41.601547 11/03/01
Packet #51 -Answers MX Timestamp: 01:35:41.784567 11/03/01
It's an infinite loop; fortunately, SIMS (or the DNS engine) has a
timeout to get out of the infinite loop.
Packet #52 -SIMS 471 response Timestamp: 01:35:49.196125 11/03/01
At this point, SIMS realizes there was an error, and returns the
"471" response.
Packets 40-41 indicate unusual (but possibly valid) behavior.
Packets 42-51 show the problem loop. SIMS' DNS engine is getting
back a "no data" response from the DNS server, and treating it as a
referral (it is going to one of the nameservers for the domain, even
if it is the same nameserver it just talked to).
Feel free to pass this on to the support people, along with the
output of your packet sniffer, as this should definitely help them
understand the problem. Specifically if they look at packet #39 (the
one that they seem to originally be misinterpreting as a referral).
But packet #42 clearly shows how the loop forms.
-Scott
-------------------
I don't understand why SIMS (or the server Mac) is going into the
infinite loop, but maybe somebody can shed some light on it.
Fokko van Duin
#############################################################
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]>
