Transcript DNS best practices for Mail Servers

SPAM Prevention Using DNS Solutions
Implementing reverse domain name services
(rDNS) and planning for SPF Classic
Presented by: Ed Horley
Date: May 2005
Overview
•
SPAM prevention is the primary reason that rDNS and SPF Classic will
become de jure within approximately 1-2 years (IETF ratified)
•
Current methods for SPAM prevention are de facto solutions – filtering,
black/white lists, etc
•
Reverse DNS (rDNS) is a great quick check to determine if an MTA is
being run and maintained correctly but it can be spoofed
•
Sender Policy Framework (SPF v1) or SPF Classic is being used by
service providers to confirm that the mail servers they are receiving
mail from are authorized to do so on behalf of the sending domain,
these records are published by the sending domain
Overview Continued
• Future additional solutions for SPAM prevention are Yahoo’s
DomainKeys, Sender Verification and perhaps Microsoft’s
Puzzle Solution (unlikely)
• Sender ID has been rejected by the IETF as a proposed
standard (de jure) due to inclusion of patented technology by
Microsoft and Microsoft has modified it and resubmitted. It may
or may not make it through this time depending on the
dependencies the working committee see on the patented or
protected intellectual property
Current Solutions Overview
• Current de facto solutions
– Blacklists (IP and DNS based)
– rDNS (optional – see RFC2505 § 2.5)
– Anti-spam filtering (Bayesian and others)
– Anti-spam services (Brightmail, Postini, Commtouch, etc)
– Hardware appliance filters / services
– Custom built scripts and applications
– Sender Verification (Several different formats exist)
– Whitelists (IP and DNS based)
– SPF Classic (optional)
Solutions Used Today
•
Blacklists
– SpamCop
– MAPS
– ORDB
– SPAMhaus
– Spews
– SURBL
– Mail-abuse
– DSBL
– DNSBL
– DNSRBL
•
Client filters
– Audiotrieve InBoxer
– Cloudmark SpamNet
– Lyris MailShield
– McAfee SpamKiller
– Aladdin SpamCatcher
– Sunbelt IHateSpam
– SpamBayes (open source)
– Spam Bully
– MailFrontier Matador
– Cloudmark Spamnet
Solutions Used Today
• Server filters
– Exchange IMF (comes bundled
with Exchange)
– XWall
– Vircom modusGate
– Sophos PureMessage
– Proofpoint Protection
– SurfControl
– Symantec
– Trend Micro
– GFI MailEssentials
– Sybari Antigen (Microsoft Aquired
Feb 2005)
– Network Associates / Mcafee
– SpamAssassin (open source)
– Declude JunkMail
•
Hardware Appliances
•
Subscription Services
–
–
–
–
–
–
–
–
–
–
–
–
–
Barracuda 300
BorderWare MXtreme
CypherTrust IronMail
IronPort C60
Mail Foundry
Sendio ICE Box
Tumbleweed
Brightmail
Commtouch
Greenview Data
Katharion
Postini
PUREmail
The Proposed Solutions
• Short term solutions:
– Internet Engineering Task Force (IETF) draft rfc’s
– Sender Policy Framework (SPF Classic)
– Sender ID (SPF Classic + PRA) – Microsoft draft rfc
(maybe?)
– DomainKeys (Google and Yahoo have implemented)
• Long term solutions:
– Internet Research Task Force (IRTF)
– New version / next generation of SMTP?
What to do now?
• SMTP mail gateway filters (hardware or software)
• Consider a commercial service (depends on the amount and
type of traffic you except to see for your environment)
• Software e-mail client filters (Small business accounts)
• Blacklists / Whitelists (Enterprise and Service Providers)
• rDNS (anyone running an MTA that sends traffic to the Internet)
• SPF Classic (anyone running an MTA that sends traffic to the
Internet)
• DomainKeys (Service Providers)
What is rDNS?
• rDNS is an acronym for reverse DNS
• It is a method of name resolution in which an IP address is
resolved into a domain name
• It is the opposite of the typical resolution method of DNS which
resolves domain names into IP addresses
• It utilizes the existing DNS infrastructure by using a special
reserved domain name: in-addr.arpa.
• IP addresses are more specific left to right and domain names
are more specific right to left, therefore the rDNS IP listings are
reversed
• Example: 63.251.192.20 would have a reverse entry of
20.192.251.63.in-addr.arpa.
Why you should do rDNS now
• Easy to implement
• Because spammers often use invalid IP addresses (bogons) to
send e-mails, rDNS will determine the authenticity of a domain
name compared to the IP address from which it is originating
• It is used as one of several de facto methods to determine the
likelihood of a server being a SPAM relay
• Most Internet Service Providers are using this to determine
legitimate mail sources
• Reduces probability of legitimate mail servers being added to a
Blacklist
What is SPF Classic?
•
•
•
•
•
SPF Classic is used to identify mail servers that are explicitly permitted
to send mail for a particular domain (think outgoing)
Domain owners identify permitted sending mail servers in DNS using
TXT records
SMTP receivers verify the envelope sender address against the DNS
information and can distinguish legitimate mail servers before any
message data is transmitted
It is backward compatible with MTA’s that are not patched with SPF
filters or libraries (well, actually the old MTA just ignore it if that is
considered backward compatible!)
Remember – MX records publish which IP’s are to receive mail
(incoming) destined for your domain, SPF records says which IP’s are
allowed to send mail (outgoing) on behalf of your domain
Why you should do SPF now
• Easy to implement (publish TXT records in DNS)
• It is used by AOL, Symantec, EarthLink, Google and more as
one of several de facto methods to determine trustworthiness of
the mail sources
• Most Internet Service Providers are currently or starting to use
this to determine legitimate mail sources
• Will move your mail to priority queues for processing for many
providers including AOL, you can also submit to be added to the
Whitelist for AOL
• Reduces probability of being added to a Blacklist
• Oct 1st ,2004 Microsoft, MSN and Hotmail will all start using
Sender ID to prioritize incoming e-mail! (Sender ID is backward
compatible with SPF Classic)
What to know about SPF Classic
•
•
•
•
•
•
•
•
Meng Wong created SPF Classic. It used to be called “Sender Permitted From”
and was changed to “Sender Policy Framework”
SPF v1 (Classic) designates specific SMTP servers as being authorized to send
for a FQDN
Uses the TXT fields in DNS to publish relevant information
Each sub-domain must be configured specifically
SPF will become de jure within approximately 1-2 years – most popular filters
are flagging this already
Most MTA’s support SPF Classic or have plug-ins available
Backward compatible with existing technology
It breaks e-mail forwarding! You'll have to switch from forwarding, where the
envelope sender is preserved, to remailing, where the envelope sender is
changed – your MTA will have to support this
What to know about Sender ID
•
•
•
•
•
•
•
•
SPF Classic + PRA = Sender ID (basically now the MTA (think
Exchange) checks SPF AND the MUA (think Outlook) check the PRA
or Purported Responsible Address)
Meng Wong and Microsoft submitted a draft rfc merging both solutions
and called it “Sender ID” – was just turned down as a standard by the
IETF due to Microsoft patent issues – it is back on the table again!
Uses the TXT fields in DNS to publish relevant information – same as
SPF but uses a new version number
Each sub-domain must be configured specifically – just like SPF
Microsoft will be updating the MTA/MUA’s to support PRA (or Sender
ID) – think Outlook, Outlook Express and Exchange
Backward compatible with existing technology
It breaks e-mail forwarding! You'll have to switch from forwarding,
where the envelope sender is preserved, to remailing, where the
envelope sender is changed – just like SPF
SPF v2
What to know about PRA *
•
•
A purported responsible address is determined as the first from the
following list of items:
– the first Resent-Sender header in the message, unless (per the
rules of RFC2822) it is preceded by a Resent-From header and one
or more Received or Return-Path headers occur after said ResentFrom header and before the Resent-Sender header (see §3.6.6. of
RFC2822 for further information on Resent headers),
– the first mailbox in the first Resent-From header in the message,
– the Sender header in the message, and
– the first mailbox in the From header in the message
The purported responsible domain of a message is defined to be the
domain part of the message’s purported responsible address.
What is coming in a few years
•
DomainKeys
– A Yahoo! submitted draft rfc
• http://www.ietf.org/internet-drafts/draft-delany-domainkeysbase-00.txt
– Basically public/private keys for authenticating client mail and the
servers along the path
– Acts as a chain of custody from the source client machine to the
destination client machine
– Will require a major re-write of all MTA’s to work – 5 to 10 years if at
all?
– Backward compatible with existing technology
– Google and Yahoo have already deployed!
– Has promise to be a great standard if adoption is quick enough
What is coming continued *
•
Puzzle Solution
– Microsoft proposal
– Assumed for small businesses that cannot afford certificate
services
– Sending mail server has to perform time consuming calculation for
each mail sent
– Assumes spammers cannot afford the computational costs to send
out large bulk mailings or the cost of the bulk certificate services
– Will require a major re-write of all MTA’s to work – 5 to 10 years if at
all?
– Backward compatible with existing technology
– Solution has serious shortcomings
– Microsoft has little published on this solution
Future potential SPAM problems
•
Disposable domain names, certificates and registrars
•
Country Sanctioned Activity (Governments allowing for profit activity or
turning a blind eye to problem spammers) in order to generate $’s
•
Large Zombie Farms controlling clients with legit relay access (Think
large University or poorly managed corporate environments)
•
Spyware agents that provide relay capabilities similar to Zombie
configurations
•
IPv6 and Mobile IP devices becoming more prevalent
•
Potential exploits that could turn large peer-to-peer networks into relays
How rDNS works
MX: mx1.ispA.net ->1.1.1.1
MX: mx1.ispB.net -> 2.2.2.2
Public ISP SMTP servers
send e-mail to destination
Public SMTP servers receive
e-mail and check rDNS
ISP A
Internet
4
5
3
Internal SMTP servers
forwarding e-mail to
public ISP SMTP servers
2
ISP B
Public DNS servers supply
reverse entries
PTR: 1.1.1.1 -> mx1.ispA.net
PTR: 2.2.2.2 -> mx1.ispB.net
Internal SMTP servers
take client e-mail
1
Worker sends e-mail
to colleague
6
Colleague receives e-mail from
Public SMTP servers
7
How to request rDNS for sub /24
address blocks
•
You will have to contact your ISP to request rDNS delegation – do this
via e-mail so you have a written trail of correspondence
•
You will likely have to talk to several departments to figure out who can
actually do this for you, first contact your account manager
•
Typically, the DNS group handles the sub-delegation but not always –
sometimes it is the networking group
•
You will need to be patient but firm – inform them that you need it for
Anti-SPAM reasons for your mail server, to be RFC 2505 compliant
•
RFC 2317 describes standard methods for rDNS sub /24 delegation
formats, there is also the DeGroot hack from the book "DNS & Bind"
both work fine
Setting up RFC 2317 rDNS Delegation
•
Example of 64.94.106.40/29 configuration in the providers servers:
$ORIGIN 106.94.64.in-addr.arpa.
; zone delegation of 64.94.106.40/29
;
40-47.
IN
NS
40-47.
IN
NS
;
40.
IN
CNAME
41.
IN
CNAME
42.
IN
CNAME
43.
IN
CNAME
44.
IN
CNAME
45.
IN
CNAME
46.
IN
CNAME
47.
IN
CNAME
ns1.j2global.com.
ns2.j2global.com.
40.40-47.106.94.64.in-addr.arpa.
41.40-47.106.94.64.in-addr.arpa.
42.40-47.106.94.64.in-addr.arpa.
43.40-47.106.94.64.in-addr.arpa.
44.40-47.106.94.64.in-addr.arpa.
45.40-47.106.94.64.in-addr.arpa.
46.40-47.106.94.64.in-addr.arpa.
47.40-47.106.94.64.in-addr.arpa.
Setting up the rDNS Zone
•
Example of 64.94.106.40/29 configuration in your servers:
$ORIGIN 40-47.106.94.64.in-addr.arpa.
; zone delegation of 64.94.106.40/29
;
@
IN
NS
@
IN
NS
;
@
IN
TXT
;
40
IN
PTR
41
IN
PTR
42
IN
PTR
43
IN
PTR
44
IN
PTR
45
IN
PTR
46
IN
PTR
47
IN
PTR
ns1.j2global.com.
ns2.j2global.com.
"j2 Global Communications, Inc."
64.94.106.40.efax.com.
64.94.106.41.efax.com.
64.94.106.42.efax.com.
64.94.106.43.efax.com.
64.94.106.44.efax.com.
64.94.106.45.efax.com.
64.94.106.46.efax.com.
64.94.106.47.efax.com.
Checking the rDNS Zone
•
Example of checking the 64.94.106.40/29 configuration:
; <<>> DiG 2.1 <<>> @206.13.31.12 40.106.94.64.in-addr.arpa. PTR
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr rd ra; Ques: 1, Ans: 2, Auth: 2, Addit: 0
;; QUESTIONS:
;; 40.106.94.64.in-addr.arpa, type = PTR, class = IN
;; ANSWERS:
40.106.94.64.in-addr.arpa.
43200
CNAME
40.40-47.106.94.64.in-addr.arpa.
40.40-47.106.94.64.in-addr.arpa. 86400
PTR
64.94.106.40.efax.com.
;; AUTHORITY RECORDS:
40-47.106.94.64.in-addr.arpa.
86400
NS
ns2.j2global.com.
40-47.106.94.64.in-addr.arpa.
86400
NS
ns1.j2global.com.
;; Total query time: 48 msec
;; FROM: us.mirror.menandmice.com to SERVER: 206.13.31.12
;; WHEN: Tue Jul 20 01:20:09 2004
;; MSG SIZE sent: 43 rcvd: 146
MX: mx1.ispA.net ->1.1.1.1
TXT: "v=spf1 a mx -all"
Public ISP SMTP servers
send e-mail to destination
How SPF Classic works
ISP A
Internet
4
TXT: "v=spf1 a mx -all"
Public SMTP servers receive
e-mail - checks SPF info
ISP B
5
3
Internal SMTP servers
forwarding e-mail to
public ISP SMTP servers
Public DNS servers supply TXT,
MX and A records
MX: mx1.ispA.net
Internal SMTP servers
take client e-mail
1
Worker sends e-mail
to colleague
6
TXT: “v=spf1 a mx –all”
A: mx1.ispA.net -> 1.1.1.1
2
MX: mx1.ispB.net -> 2.2.2.2
Colleague receives e-mail from
Public SMTP servers
7
SPF Classic Syntax *
• Some common SPF options in the TXT field
a = the A record entry for example.com sends e-mail on behalf of example.com
mx = the published MX record entries for example.com do not only receive e-mail on behalf of
example.com but send e-mail also
ptr = approve any host that ends in example.com as part of its FQDN
a: = a list of A record entries that are permitted to send e-mail on behalf of example.com
mx: = a list of mx record entries that are permitted to send e-mail on behalf of example.com
ip4: = a list of ip addresses that are permitted to send e-mail on behalf of example.com (CIDR)
include: = a different domain that may send e-mail on behalf of example.com (relay through your
service provider)
-all: = (fail) everything in the SPF record are the ONLY hosts/networks permitted to send
(strictest policy – don’t do unless you know all the ramifications)
~all: = (soft fail) everything in the SPF record are the ONLY hosts/networks permitted to send
(middle ground)
?all: = not sure (technically neutral) if everything in the SPF record are the ONLY hosts/networks
permitted to send (start publishing with this one first as it is the most liberal policy)
Please see http://spf.pobox.com/mechanisms.html for a more detailed description and see
http://spf.pobox.com/whitepaper.pdf for an excellent whitepaper
Setting up SPF Classic
• Configuration of example.com SPF
$ORIGIN example.com.
; Leaving out the SOA info for space reasons
; NS records
@
IN
NS
@
IN
NS
; MX records
@
IN
MX 10
@
IN
MX 20
; A records
mx1
IN
A
mx2
IN
A
; TXT – SPF records
@
IN
TXT
mx1
IN
TXT
mx2
IN
TXT
ns1.example.com.
ns2.example.com.
mx1.example.com.
mx2.example.com.
1.1.1.1
2.2.2.2
"v=spf1 a mx -all"
"v=spf1 a -all"
"v=spf1 a -all"
Register your SPF domain
• Once you have configured SPF for your domain you should
confirm your configuration at:
• www.dnsstuff.com
• Then put the logo on your site!
Testing SPF Classic
• Testing of example.com SPF
– http://www.dnsstuff.com/pages/spf.htm
– Dummy Sample Output from dnsstuff:
SPF lookup of sender [email protected]. from IP 1.1.1.1:
SPF string used: v=spf1 mx -all.  Obtained the TXT record via DNS for example.com
Processing SPF string: v=spf1 mx -all.  Checking against the TXT record
Testing 'mx' on IP=1.1.1.1, target domain example.com, CIDR 32, default=PASS. MATCH!
Testing 'all' on IP=1.1.1.1, target domain example.com, CIDR 32, default=FAIL.
Result: PASS
Impact on the Internet
• These solutions will help reduce overall architecture problems of
Authentication, Authorization, and Accounting with e-mail (back
to AAA)
• 68B e-mails daily of which approx. 42.8B are spam or 69%
1
spam!
• Estimated $1,400 annual savings per employee from lost
2
productivity currently due to spam
1 – The Radicati Group and Brightmail
2 - Vircom
Resource Links
•
rDNS:
– http://www.ietf.org/rfc/rfc2317.txt
– http://www.ietf.org/rfc/rfc2505.txt
– http://www.arin.net/registration/lame_delegations/index.html
– http://kbase.menandmice.com/view.html?rec=31
– http://www.microsoft.com/windows2000/techinfo/reskit/enus/default.asp?url=/windows2000/techinfo/reskit/en-us/cnet/cncf_imp_dewg.asp
– http://dedicated.pacbell.net/custcare/dns_worksheet.html
•
DNS tools:
– http://www.dnsstuff.com/
– http://us.mirror.menandmice.com/cgi-bin/DoDig
– http://network-tools.com/
– http://www.squish.net/dnscheck/
– http://www.dns.net/dnsrd/tools.html
– http://www.dnsreport.com/
– http://www.samspade.org/t/
•
General references:
– http://www.spamanatomy.com/
– http://www.declude.com/Articles.asp?ID=97
Resource Links
•
SPF:
– http://spf.pobox.com/howworks.html
– http://spf.pobox.com/rfcs.html
– http://spf.pobox.com/wizard.html
– http://www.ietf.org/internet-drafts/draft-mengwong-spf-01.txt
– http://www.dnsstuff.com/pages/spf.htm
•
Microsoft’s PRA (E-mail Caller ID):
– http://www.microsoft.com/downloads/details.aspx?FamilyID=9a9e8a28-3e85-4d07-9d0f6daeabd3b71b&displaylang=en
•
Sender ID – the merged PRA and SPF:
– http://www.microsoft.com/presspass/press/2004/may04/05-25SPFCallerIDPR.asp
– http://www.microsoft.com/presspass/press/2004/jun04/06-24SIDSpecIETFPR.asp
– http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx
•
Yahoo! DomainKeys:
– http://antispam.yahoo.com/domainkeys
– http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-00.txt
– http://boycott-email-caller-id.org/
A look at some Service Provider’s records
•
aol.com.
300 IN
TXT "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24
ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24
ptr:mx.aol.com ?all“
aol.com.
300 IN
TXT "spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24
ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24
ptr:mx.aol.com ?all“
•
cisco.com.
86400 IN
•
earthlink.net.
?all“
1800
•
efax.com.
86400 IN
•
google.com.
•
hotmail.com.
3600 IN
TXT "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com
include:spf-c.hotmail.com include:spf-d.hotmail.com ~all“
•
microsoft.com.
•
msn.com.
900 IN
TXT "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com
include:spf-c.hotmail.com include:spf-d.hotmail.com ~all“
•
netzero.net.
•
symantec.com.
?all“
300
3600
600
TXT
IN
TXT
IN
IN
IN
"v=spf1 ptr"
"v=spf1 ip4:207.217.120.0/23 ip4:207.69.200.0/24 ip4:209.86.89.0/24
TXT
"v=spf1 ptr ?all"
TXT
"v=spf1 ptr ?all“
TXT
TXT
18000 IN
"v=spf1 mx redirect=_spf.microsoft.com"
"v=spf1 ptr:untd.com ptr:netzero.net ptr:juno.com ?all“
TXT
"v=spf1 ip4:198.6.49.0/24 ip4:65.125.29.0/25 ip4:206.204.57.47
Questions and Answers
About Ed Horley
•
Ed Horley is a Sr. Network Engineer for j2 Global Communications, better
known as eFax. Ed currently designs, supports and maintains j2's 58+
international and domestic collocation sites along with j2's core data center IP
infrastructure. He is experienced in e-commerce web content delivery, large
scale e-mail delivery, firewalls, IPSec VPN's, and specializes in routing and
switching and DNS issues.
•
Ed is a Cisco Certified Network Professional (CCNP), a Microsoft Certified
Professional (MCP) and a Microsoft Most Valuable Professional (MVP). Ed
graduated from the University of the Pacific in 1992 with a BS in Civil
Engineering.
•
When he is not playing on network gear you can find him out on the lacrosse
field as an Umpire for Women's Lacrosse. He is currently married to his
wonderful wife Krys and has two children, Briana and Aisha. He lives and works
in Walnut Creek, CA.
Contact Info
Ed Horley
[email protected]