John C Klensin asked:
>>
So what are you suggesting?
Robert A. Rosenberg wrote:
1) Require that any IPv6 MTA MUST be pointed to by an EXPLICATE MX record.
Translation:
EXPLICIT MX - it must have a MX record which exposes mail host A records.
2) Require that any IMPLICATE MX record that is built due to the absence
of an EXPLICATE MX record follow the EXPLICATE MX RFC 3484 rules for an
IPv4-ONLY stack (ie: Ignore all AAAA records found for foo.example.com
IN A/AAAA).
This is not consistent with #1 - mandating a successful MX record.
First, the term used in 2821 is implicit MX.
I always thought it was a convoluted description which walks, smells and
talks as if there is a presumption the SMTP client has its own DNS
resolver or a API/OS DNS resolver that will perform this "IMPLICIT MX"
concept for the SMTP client.
if so. NOPE.
In lieu of a specific and/or special DNS RESOLVER that will inherently
(automatically) add an A record to the result of a MX query, the
"IMPLICIT MX" is generally a manual step of the requesting software -
SMTP client - where it sees NO records are returned and it will now
check the A record of the email address domain part. Whether it done in
the DNS resolver or in the SMTP client this process is called the
Implicit MX.
Otherwise, the response of a MX request is always successful which is
not always true in MX queries and this may be important in the logic
used for SMTP client retries.
To prove the point, use a DNS client like NSLOOKUP and it will not
return the domain A record if a MX query has no records.
This simple set of rules allows A-Fallback to continue to work by simply
requiring that an IMPLICATE MX that is created is treated the Stack as
if it were an IPv4-Only Stack even when it is actually a Dual Stack or
an IPv6-Only stack.
OK, it sounds to me that what you are advocating is that RESOLVERS learn
how to do an inherent "Implicit MX" default logic for all MX queries.
Is that a correct statement?
If so, this is not realistic and I personally will not want a backend
DNS resolver to do making "assumptions" or making up records that may
not exist.
Keep in mind that the doing a MX query is only the 1st step in the TOTAL
MX EXPANSION process.
A MX query returns A records which need to be then expanded into IP
addresses by looking up all the A records to get the IP addresses.
So if we have an DNS resolver automatically and inherently adding a fake
zero preference A record representing the domain, you don't even now
yet if the A record actually exist unless it went out and actually
checked for the A record.
This is NOT always desirable for two key reasons:
1) The binary result of a MX whether is MXDOMAIN, SERVFAIL or SOA
may be important in how a mail client does its retries.
2) There are strategies where you do not want the A record
expansion to take place immediately because the IP
addresses attempted may by limited by the mail client.
Note: If the DNS client is hitting a cache server, it may
return the IP addresses as part the total result.
A good example is a large inbound farm network where there are a lot of
MX A records. For example, YAHOO.COM which will spit out a random set
of A records. Using our own DNS resolver against my home ISP server
(via my NAT):
V:\wc7beta\>wcdns yahoo.com -qt=mx -dbg
- MX Expand Multi-Home: No
- MX Delay Lookup : No
-- [yahoo.com] --
DNS> Total DNS Servers: 1
DNS> DNS Servers #1 192.168.1.3
DNS> ********** GetDNSRecordsPrim() ***********
DNS> address : yahoo.com
DNS> dnsdomain: 192.168.1.3
DNS> rtype : MX (15)
DNS> socket : UDP
DNS> timeout : 10
DNS> records : 7 aa: 0 an: 7 ns: 0 ar: 0 qd: 1 qr: 1 rcode: 0
DNS> query host: [yahoo.com]
DNS> RR MX ttl=4251 pre=1 | yahoo.com | d.mx.mail.yahoo.com
DNS> RR MX ttl=4251 pre=1 | yahoo.com | e.mx.mail.yahoo.com
DNS> RR MX ttl=4251 pre=1 | yahoo.com | f.mx.mail.yahoo.com
DNS> RR MX ttl=4251 pre=1 | yahoo.com | g.mx.mail.yahoo.com
DNS> RR MX ttl=4251 pre=1 | yahoo.com | a.mx.mail.yahoo.com
DNS> RR MX ttl=4251 pre=1 | yahoo.com | b.mx.mail.yahoo.com
DNS> RR MX ttl=4251 pre=1 | yahoo.com | c.mx.mail.yahoo.com
DNS> host: d.mx.mail.yahoo.com iplist: 0.0.0.0
DNS> host: e.mx.mail.yahoo.com iplist: 0.0.0.0
DNS> host: f.mx.mail.yahoo.com iplist: 0.0.0.0
DNS> host: g.mx.mail.yahoo.com iplist: 0.0.0.0
DNS> host: a.mx.mail.yahoo.com iplist: 0.0.0.0
DNS> host: b.mx.mail.yahoo.com iplist: 0.0.0.0
DNS> host: c.mx.mail.yahoo.com iplist: 0.0.0.0
DNS> total mx: 7 tagged: 7
count : 7
MX *0 | 4251 | 1 | 0.0.0.0 | c.mx.mail.yahoo.com |
MX *1 | 4251 | 1 | 0.0.0.0 | b.mx.mail.yahoo.com |
MX *2 | 4251 | 1 | 0.0.0.0 | a.mx.mail.yahoo.com |
MX *3 | 4251 | 1 | 0.0.0.0 | g.mx.mail.yahoo.com |
MX *4 | 4251 | 1 | 0.0.0.0 | f.mx.mail.yahoo.com |
MX *5 | 4251 | 1 | 0.0.0.0 | e.mx.mail.yahoo.com |
MX *6 | 4251 | 1 | 0.0.0.0 | d.mx.mail.yahoo.com |
If I do this against our company DNS primary server at 208.247.131.10
which also has an uplink cache server, I will get the IP records:
V:\wc7beta\wcdns yahoo.com -qt=mx -dbg -dns=208.247.131.10
- MX Expand Multi-Home: No
- MX Delay Lookup : No
-- [yahoo.com] --
DNS> ********** GetDNSRecordsPrim() ***********
DNS> address : yahoo.com
DNS> dnsdomain: 208.247.131.10
DNS> rtype : MX (15)
DNS> socket : UDP
DNS> timeout : 10
DNS> records : 17 aa: 0 an: 7 ns: 0 ar: 10 qd: 1 qr: 1 rcode: 0
DNS> query host: [yahoo.com]
DNS> RR MX ttl=5211 pre=1 | yahoo.com | d.mx.mail.yahoo.com
DNS> RR MX ttl=5211 pre=1 | yahoo.com | e.mx.mail.yahoo.com
DNS> RR MX ttl=5211 pre=1 | yahoo.com | f.mx.mail.yahoo.com
DNS> RR MX ttl=5211 pre=1 | yahoo.com | g.mx.mail.yahoo.com
DNS> RR MX ttl=5211 pre=1 | yahoo.com | a.mx.mail.yahoo.com
DNS> RR MX ttl=5211 pre=1 | yahoo.com | b.mx.mail.yahoo.com
DNS> RR MX ttl=5211 pre=1 | yahoo.com | c.mx.mail.yahoo.com
DNS> RR A ttl=1522 | 216.39.53.1 | e.mx.mail.yahoo.com
DNS> RR A ttl=1531 | 209.191.88.247 | f.mx.mail.yahoo.com
DNS> RR A ttl=1531 | 68.142.202.247 | f.mx.mail.yahoo.com
DNS> RR A ttl=1531 | 209.191.88.239 | g.mx.mail.yahoo.com
DNS> RR A ttl=1531 | 206.190.53.191 | g.mx.mail.yahoo.com
DNS> RR A ttl=1531 | 209.191.118.103 | a.mx.mail.yahoo.com
DNS> RR A ttl=1502 | 66.196.97.250 | b.mx.mail.yahoo.com
DNS> RR A ttl=1531 | 216.39.53.2 | c.mx.mail.yahoo.com
DNS> RR A ttl=1531 | 216.39.53.3 | c.mx.mail.yahoo.com
DNS> RR A ttl=1531 | 66.196.82.7 | d.mx.mail.yahoo.com
DNS> total mx: 10 tagged: 0
count : 10
MX 0 | 5211 | 1 | 66.196.82.7 | d.mx.mail.yahoo.com |
MX 1 | 5211 | 1 | 216.39.53.1 | e.mx.mail.yahoo.com |
MX 2 | 5211 | 1 | 209.191.88.247 | f.mx.mail.yahoo.com |
MX 3 | 5211 | 1 | 68.142.202.247 | f.mx.mail.yahoo.com |
MX 4 | 5211 | 1 | 209.191.88.239 | g.mx.mail.yahoo.com |
MX 5 | 5211 | 1 | 206.190.53.191 | g.mx.mail.yahoo.com |
MX 6 | 5211 | 1 | 209.191.118.103 | a.mx.mail.yahoo.com |
MX 7 | 5211 | 1 | 66.196.97.250 | b.mx.mail.yahoo.com |
MX 8 | 5211 | 1 | 216.39.53.2 | c.mx.mail.yahoo.com |
MX 9 | 5211 | 1 | 216.39.53.3 | c.mx.mail.yahoo.com |
There is no HARD CORE rule that suggest that a mail client MUST use all
the expanded IP addresses in its total retry strategy. It might choose
to use just 5 IPs or 10 ips or whatever. But what is important that the
IP addresses may or may not be part of the result.
So some clients, like ours, will only expand the A to X number IPs for
retries.
Is this correct or am I missing something here?
I always assumed it was well understood that an MX query and the
implicit MX idea was essentially a two step concept whether its done by
the resolver or smtp client, but the end result is the same.
The different here from what I am reading is that there seems to be this
notion that the DNS resolver is always independent from the SMTP and its
results drive the SMTP client - i.e, the SMTP client is not in the
picture. I don't believe that concept can be presumed to be always true.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com