>That seems like a good choice. Taking as long as you seem to take to >do the successful resolution indicates a problem in DNS somewhere. >Note that you found the A record in the same second that you failed >to find the MX. > >(I really wish you had not munged the log lines. It would be useful >to be able to tell whether their DNS was the slow bit...)
Thanks, Bill. I will try to determine if there's anything wrong with the DNS servers I've been using, including my own. Meantime, regarding the munging, you can substitute "psych.stanford" for "psych.bigschool" and "stmp1.stanford"/"smtp2.stanford" for "smtp.bigschool" in the example I gave To provide some more info (as much as I can right now, since I'm at home), mprinc.com had (in order) itself (63.75.20.124), two nameservers from our ISP, and one other nameserver. The last, as it turns out, was no longer functional, but that doesn't necessarily mean it was the (sole) culprit. To keep things simple I didn't mention in my previous note that after timing out on mprinc.com, Stanford's mail servers were trying mx2.mprinc.com, usually with the same result. Except in that case, the delay was only 40-some seconds. mx2.mprinc.com has three DNS servers in its TCP/IP control panel. In order, they are two from the ISP that mx2.mprinc.com is connected to, then 63.75.20.124. So the only common factor in DNS is 63.75.20.124, yet the delay still works out to roughly 14 seconds per DNS server. --Elliot Wilen ############################################################# 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]>
