Hector Santos <hsantos(_at_)santronics(_dot_)com> writes:
It appears to me that Microsoft wishes virtualize IPv6 (and IPv4) from
an application viewpoint. i.e, separate the communication layer.
Up-front disclaimer: I am purely and exclusively a UNIX developer and
wouldn't know what to do with a Windows system without a fair bit of
study. The last time I used Windows for long enough to understand what it
was doing was Windows 3.1. So I can only really answer from the
perspective of how the APIs are implemented on UNIX or Linux and what's in
RFC 3493.
When its all said and done, an SMTP client would never need to know
about MX, A or AAAA records or any other record current or future for
that matter.
If you want to send mail or even just check for SMTP hosting, all you need
is two variables possible three, and the getaddrinfo() function call.
- host name
- service port
- flags for IPv4 only, IPv6 or both (passive mode).
Passive mode is used by servers that want to listen to an interfaces, and
it's orthogonal to IPv4 or IPv6. You can have any combination of
AI_PASSIVE and family hints; one doesn't imply the other.
If done correctly, ideally the SMTP client will never need to worry
explicit MX or implicit MX records.
Am I on track?
Well, at least with the getaddrinfo implementation on UNIX, this doesn't
work for SMTP because getaddrinfo doesn't handle service-specific DNS
resolution. I suppose in theory it *could* given that you tell it what
service you want to use, but that's just not how the code works or how the
APIs are specified (and hence probably isn't how the code can ever work in
the absence of a new hint flag). The service (either specified as a
number or as a symbolic name) only does service resolution and fills in
the port element of the structure. It doesn't do SRV or MX lookups or
anything of the type.
So, to connect to the mail server for a given address, the IPv6-enabled
client still has to follow the same logic as an existing IPv4-only client,
namely try to resolve the MX record, use the hostname in the
lowest-priority (bleh) MX record if one is found (and possibly iterate if
the first one fails), and fall back to trying to connect directly to the
RHS if that fails. The MX lookup isn't done for you in getaddrinfo.
If so, my next question has to do with what are the requirements to make
it work.
More specifically, right now our smtp code is using level 1 socket
commands. We have our own DNS resolver.
Would a first step be to port over to level 2, and removing or rather
replace our GetDNSRecord() function with getaddrinfo() but use a IPv4
only flag?
getaddrinfo, at least in the UNIX world, is a replacement for
gethostbyname and doesn't do anything more fancy DNS-wise than
gethostbyname does other than support AAAA records. It still doesn't do
an MX lookup and you still have to do that separately, usually using a
more sophisticated DNS API that allows you to look for arbitrary record
types.
Or should I go ahead and make it passive, and we will still not have
problems if the customer has an OS with no IPv6 stacks installed?
AI_PASSIVE is only for servers and is unrelated to this problem.
I think the flag that you're looking for is AI_ADDRCONFIG, which tells
getaddrinfo to not return addresses using protocols for which there is no
configured local interface. (So if you don't have an IPv4 interface, you
won't get IPv4 addresses, and if you don't have an IPv6 interface, you
won't get IPv6 addresses.)
PS: if you prefer to go offlist, I wouldn't mind that. :-)
We probably should for further discussion, as I think we're moving farther
afield from the purpose of the list.
--
Russ Allbery (rra(_at_)stanford(_dot_)edu)
<http://www.eyrie.org/~eagle/>