INTERNET-DRAFT Gary Bajaj
<draft-bajaj-mail-srv-00.txt> May 2003
Use of SRV records for POP3, POP3S, IMAP and IMAPS.
Status of this Memo
This document is an Internet-Draft and is subject to all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Comments should be sent to the author.
This draft expires in November 2003.
Abstract
DNS records for the mail services POP3, POP3S, IMAP and IMAPS do
not currently provide failover switching as do the DNS MX records
for SMTP. This document looks at the issues involved and
recommends a solution using SRV records.
Introduction
Mail servers that require high availability might be multi-homed
with upstream connectivity to two or more ISPs. This is
traditionally accomplished by running BGP4 such that each upstream
provider would route to the site's own IP block. If connectivity
to one ISP fails, incoming connections would seamlessly be routed
through the other ISP. For various reasons including IP
allocation constraints, cost and networking expertise, running
BGP4 is impratical for most small ISPs. If using DNS only, SMTP
can be made fault tolerant by using multiple MX records, one for
each IP serviced by the mail server so that each MX record is
tried in turn until an IP responds. Such failover protection
using DNS is not currently possible for POP3 and IMAP connections.
Expires November 2003 [Page 1]
Using SRV [RFC2782] records seems to be the obvious solution to
making POP3, POP3S, IMAP and IMAPS redundant. SRV records also
provide for load balancing when using multiple servers that have
access to mail spool on a shared mass storage device such as NAS.
Examples:
SRV RRs:
_pop3._tcp SRV 1 0 110 host1.example.com.
_pop3._tcp SRV 1 0 110 host2.example.com.
_pop3._tcp SRV 0 0 110 host3.example.com.
_imap._tcp SRV 1 0 143 host1.example.com.
_imap._tcp SRV 1 0 143 host2.example.com.
_imap._tcp SRV 0 0 143 host3.example.com.
_pop3s._tcp SRV 0 3 995 host1.example.com.
_pop3s._tcp SRV 0 1 995 host2.example.com.
_imaps._tcp SRV 0 3 993 host1.example.com.
_imaps._tcp SRV 0 1 993 host2.example.com.
A RRs:
host1 A 10.0.0.2
host2 A 172.16.1.2
host3 A 172.16.1.3
host1 and host2 are the same multi-homed host that can accept both
insecure (pop3, imap) and secure (pop3s, imaps) connections.
host3 is a separate host that is not multi-homed and does not
accept secure connections.
Connect to either 10.0.0.2 or 172.16.1.2 if either is available
(the probability of being selected is 75% for 10.0.0.2 and 25% for
172.16.1.2) to download mail over a secure POP3 or IMAP connection
Connect to 172.16.1.3 and if not available connect to either of
10.0.0.2 or 172.16.1.2 to download mail over an insecure POP3 or
IMAP connection.
Transitioning Considerations
When transitioning from using a non-SRV solution to using an SRV
based solution, old non-SRV aware clients (mail user agents) will
continue to look for A records. These will not benefit from
redundancy until updated, but will continue to work.
IANA Considerations
Well known labels have to be allocated for the first label of the
SRV records. This document has used _pop3, _imap, _pop3s and
_imaps.
References
[RFC2782]
A DNS RR for specifying the location of services (DNS SRV). A. Gul
brandsen, P. Vixie, L. Esibov. February 2000. RFC 2782.
Expres November 2003 [Page 2]
Author's Address
Gary Bajaj
BITNETS
58065-12621 118 Ave NW
Edmonton, Alberta T5L 4Z4
Canada
+1 (780) 418-4477
BEAMERS-Support@BITNETS.com
Expires November 2003 [Page 3]