kannan@manhandler.oar.net (Kannan Varadhan) (08/07/90)
We are trying to represent a multi-homed machine in a zone file as a machine having multiple A records. We'd like to be aware of the implications this might have on different application programs like telnet and ftp. My understanding is that sendmail, if it detects multiple MXs of equal weight, picks up one RR at random, and pops the mail over to that machine. Is there some such load-balancing feature built onto telnet, ftp, mail transfer agents etc. when multiple A records for the same FQDN are seen? Or, do they pick up the first A record (call it the primary Address), try it, if it fails, then try the other addresses in the order specified in the zone file? Can we rely on named returning all the addresses for a given machine in the order specified? Does the answer depend on the version of telnet, ftp, mail transport agent, named etc. one uses? The reasoning is that we'd like not to have any load-balancing built in. We'd like users to try the primary address. If that fails for some reasons in the underlying network, we'd like the application to then try the secondary addresse(es) until all of the addresses have been exhaustively tried. For the record, the named that will answer for the multiple A records will be BIND 4.8.2, the one with the UofToronto mods. At this point, I cannot say much about the versions of other application software out there in the void, but I suspect a little of everything. Any pointers on which RFCs to look at would be appreciated too, Please mail me the answers....I'll summarise the replies within a week. I would actually be trying some of this by experimentation too, so I'll post whatever I find to the tcp-ip list, Kannan
kannan@manhandler.oar.net (Kannan Varadhan) (08/29/90)
After an interminable delay, for which I apologise, here's a summary of
what I found on appications connecting to multi-homed hosts.
The question (paraphrased) was:
How do applications like telnet and ftp handle multiple addresses to a
given host? Do they, should they, try the different addresses?
Can one, as the one who manages a machine, specify the order in which
users will see the different addresses, say, via named and the DNS?
Basically, the consensus is that
a) named is not required or guaranteed to return multiple addresses
in the given order. [RFC 1034, Page 30]
b) It is upto to the resolver to specify the order in which
addresses are to be preferred. [RFC 1034 Pg 30, RFC 1123 sections 2.3, 6.1.3.4]
This can be done via an `address' line in the resolv.conf file,
a sortlist in your named.boot file, for bind software, or some
`logical' something incantations for VMS systems. Other
machines, software etc., I expect have this too, though I
didn't get into gory details.
c) 4.2 BSD based (or older) software will only return or use one address
per name, because of a static host table concept.
4.3 BSD based software, and other miscellaneous software use
multiple addresses, if given them. PC based applications
typically do not use the multiple addresses. PCIP from FTP
software orders the addresses, and uses then picks one up.
d) There is no load-balancing etc. of the network numbers
involved. Applications are not also required to try all the different
addresses. [RFC1034]
e) The relevant RFCs are Page 30 of RFC 1034, Sections 2.3, 5.3.4
and 6.1.3.4 of RFC 1123, the HRRFC. I have placed sections of the RFC
at the end of this message, FYC.
Thanks go to
jbvb@vax.ftp.com (James Van Bokkelen)
emv@math.lsa.umich.edu (Edward Vielmetti)
kim@lut.fi (Kimmo Suominen)
braden@venera.isi.edu
Kraig R. Meyer <kmeyer@wrl.dec.com>
MARC@UNB.CA
Mark Towfigh <towfiq@interlan.interlan.com>
and John Chanbers <ll-xn!minya!jc@ima.ima.isc.com>
Kannan
-----
I have copies of the responses I received. In case anyone is
interested, send me some mail, and I'll forward them to you.
-----
Bob Braden and Kriag Meyers pointed me to sections of the RFC, which
follow...
From [RFC 1034], Domain Concepts and Facilities, Page 30
based function. Given a character string, the caller wants
one or more 32 bit IP addresses. Under the DNS, it
translates into a request for type A RRs. Since the DNS does
not preserve the order of RRs, this function may choose to
sort the returned addresses or select the "best" address if
the service returns only one choice to the client. Note that
a multiple address return is recommended, but a single
address may be the only way to emulate prior HOSTS.TXT
services.
And, from the HRRFC, [RFC1123], APPLICATIONS LAYER -- GENERAL,
2.3 Applications on Multihomed hosts
When the remote host is multihomed, the name-to-address
translation will return a list of alternative IP addresses. As
specified in Section 6.1.3.4, this list should be in order of
decreasing preference. Application protocol implementations
SHOULD be prepared to try multiple addresses from the list until
success is obtained. More specific requirements for SMTP are
given in Section 5.3.4.
When the local host is multihomed, a UDP-based request/response
application SHOULD send the response with an IP source address
that is the same as the specific destination address of the UDP
request datagram. The "specific destination address" is defined
in the "IP Addressing" section of the companion RFC [INTRO:1].
Similarly, a server application that opens multiple TCP
connections to the same client SHOULD use the same local IP
address for all.
5.3.4 Reliable Mail Transmission
When it succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address,
because of (a) multiple MX records, (b) multihoming, or both.
To provide reliable mail transmission, the sender-SMTP MUST be
able to try (and retry) each of the addresses in this list in
order, until a delivery attempt succeeds. However, there MAY
also be a configurable limit on the number of alternate
addresses that can be tried. In any case, a host SHOULD try at
least two addresses.
The following information is to be used to rank the host
addresses:
(1) Multiple MX Records -- these contain a preference
indication that should be used in sorting. If there are
multiple destinations with the same preference and there
is no clear reason to favor one (e.g., by address
preference), then the sender-SMTP SHOULD pick one at
random to spread the load across multiple mail exchanges
for a specific organization; note that this is a
refinement of the procedure in [DNS:3].
(2) Multihomed host -- The destination host (perhaps taken
from the preferred MX record) may be multihomed, in which
case the domain name resolver will return a list of
alternative IP addresses. It is the responsibility of the
domain name resolver interface (see Section 6.1.3.4 below)
to have ordered this list by decreasing preference, and
SMTP MUST try them in the order presented.
6.1.3.4 Multihomed Hosts
When the host name-to-address function encounters a host
with multiple addresses, it SHOULD rank or sort the
addresses using knowledge of the immediately connected
network number(s) and any other applicable performance or
history information.
DISCUSSION:
The different addresses of a multihomed host generally
imply different Internet paths, and some paths may be
preferable to others in performance, reliability, or
administrative restrictions. There is no general way
for the domain system to determine the best path. A
recommended approach is to base this decision on local
configuration information set by the system
administrator.
IMPLEMENTATION:
The following scheme has been used successfully:
(a) Incorporate into the host configuration data a
Network-Preference List, that is simply a list of
networks in preferred order. This list may be
empty if there is no preference.
(b) When a host name is mapped into a list of IP
addresses, these addresses should be sorted by
network number, into the same order as the
corresponding networks in the Network-Preference
List. IP addresses whose networks do not appear
in the Network-Preference List should be placed at
the end of the list.