On Mon, 05 Jan 2004 03:26:08 EST, Hector Santos said:
count : 11
MX 0 | 15 | 205.188.156.185 | mailin-01.mx.aol.com |
MX 1 | 15 | 205.188.158.121 | mailin-01.mx.aol.com |
MX 2 | 15 | 205.188.159.57 | mailin-01.mx.aol.com |
MX 3 | 15 | 64.12.137.89 | mailin-01.mx.aol.com |
MX 4 | 15 | 64.12.137.184 | mailin-01.mx.aol.com |
MX 5 | 15 | 64.12.138.57 | mailin-01.mx.aol.com |
MX 6 | 15 | 64.12.138.152 | mailin-01.mx.aol.com |
MX 7 | 15 | 64.12.138.89 | mailin-02.mx.aol.com |
MX 8 | 15 | 64.12.138.120 | mailin-02.mx.aol.com |
MX *9 | 15 | 0.0.0.0 | mailin-04.mx.aol.com |
MX *10 | 15 | 0.0.0.0 | mailin-03.mx.aol.com |
Here there are 4 MX with equal preference. mailin-04 and mailin-03 has no A
records, so they end up at towards the bottom of the final list (indicated
with the asterisk). So what will happen in the sender is that if he sees
an IP of zero, it will then perform the A record lookup at the point.
I believe this is the "clever" logic you suggested. Right?
That's a good first cut. The "even more clever" version is to fire off your
second round of DNS lookups when you get to entry 7 or 8 so that you get
the answer back in time to start trying the yet-to-be-filled-in entry at 9
without delaying 9, and without wasting resources if one of the first 6 or 7
entries in the table works. If you were *really* smart, you recorded how long
the first lookup took, and use that info to decide if you fire the second DNS
when you start 7, when you start 8, or when you're N seconds from deciding
that 8 is dead - if the first query took 2 seconds, you can wait till 3-4
seconds
before you think you need to start 9, if the first query took 30 seconds, you
need
to fire the DNS lookups 35-40 seconds ahead.
I have to give credit for much of that idea to Thom O'Connor and Motonori
Nakamura, both of whom have spent a lot more time analyzing the DNS issues of
SMTP for scaling high-volume delivery than I have.
Oh, and another not-yet-mentioned piece of wisdom from Motonori: When dealing
with delivery of a message to multiple sites, having a truly asynchronous
multi-threaded resolver is an incredible win (if the mail is going to 40
places, launching all 40 DNS queries at once means that you can start
delivering mail as soon as you get the FIRST DNS reply packet back - even if
you're doing MX piggybacking(*), you're still in the clear as long as any
additional replies indicating piggybacking arrive in time for you to merge in
their RCPT TO: (basically, as long as you haven't gotten to the DATA command).
In other words, if your mail is going to AOL and Yahoo, waiting for both sets of
DNS queries to finish before you connect to anybody can kill your performance...
pgpMGYe1QvmLS.pgp
Description: PGP signature