User:David MacQuigg/Forward-confirmed reverse DNS: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>David MacQuigg
(New page: '''Edit status:''' '''Definition:''' Method for authenticating an association of a domain name with an IP address. {{TOC|right}} This article is a subtopic in a group of articles under [...)
 
imported>David MacQuigg
No edit summary
Line 6: Line 6:
This article is a subtopic in a group of articles under [[Email system]]. We assume the reader understands the parent article, its terminology, and the roles of different agents in the system.  The reader should also be familiar with the basics of [[Email authentication]] and with the article on [[Reverse DNS]].
This article is a subtopic in a group of articles under [[Email system]]. We assume the reader understands the parent article, its terminology, and the roles of different agents in the system.  The reader should also be familiar with the basics of [[Email authentication]] and with the article on [[Reverse DNS]].


'''Forward-Confirmed reverse DNS''' (FCrDNS) is an email authentication method that uses the [[IP address|source IP address]] in a [[TCP]] connection to tie together various identities associated with an email message.  A Pass result provides assurance that as many as three agents agree that a particular name is associated with the address.
'''Forward-Confirmed reverse DNS''' (FCrDNS) is an email authentication method that uses the [[IP address|source IP address]] in a [[TCP]] connection to verify a domain name.  A receiver does a [[Reverse DNS]] query on the IP address to learn the "IP name" assigned to that address by the network owner.  If a normal forward DNS query on that name gives a matching IP address, then we have strong assurance that the network owner and the domain owner agree that the IP address and domain name are connected.


=== Limitations ===
=== Limitations ===


The PTR method says nothing about the '''authorization''' of an IP address to send email.  There must be some external information, perhaps a "PTR term" in an [[Sender Policy Framework|SPF]] record, saying in effect "Trust our PTR records. We're not as sloppy as everyone else."  Otherwise, a Pass result might only show that a network provider set up PTR records for all addresses in his entire IP blcok, including dynamic addresses assigned to home computers.
FCrDNS says nothing about the '''authorization''' of an IP address to send email.  There must be some external information, perhaps a "PTR term" in an [[Sender Policy Framework|SPF]] record, saying in effect "Trust our PTR records. We're not as sloppy as everyone else."  Otherwise, a Pass result might only mean that a network provider set up PTR records for all addresses in his entire IP block, including dynamic addresses assigned to home computers.  Often these network owners are large telecommunication companies, and not responsive to domain owners who want to set up their own PTR records.


The PTR method is one of the most confusing of the email authentication methods.  It can provide robust authentication, but seldom does because of the confusion. There is no standard on how the method should work.  PTR records were defined prior to the massive abuse we see now.  Because of the widespread confusion and mis-configuration by senders, few receivers rely on PTR as having any value by itself.  It is mostly used as a heuristic check along with other inputs to a statistical analysis by a spam filter.
The FCrDNS method is one of the least reliable of the email authentication methods.  It can provide robust authentication, but seldom does because of the confusion and miscommunication surrounding PTR records.<ref>See the Internet Draft by Senie and Sullivan for detailed discussion of the problems with DNS Reverse Mapping.</ref> Few receivers rely on FCrDNS as having any value by itself.  It is mostly used as a heuristic check along with other inputs to a statistical analysis by a spam filter.


=== How it works ===
=== How it works ===


To explain the method, let's assume we have three different agents involved in handling the mail on the [[Email system|sender's side]].  These could all be the same agent, or sometimes the Network Owner and Domain Owner are the same, but the Transmitter Operator is a bad guy controlling a zombie within the network.
See the email authentication example in [[Reverse DNS]].
 
Transmitter Operator  :  Network Owner    :    Domain Owner
    ties                      ties                  ties
    HELO name                IP name              Domain Name   
    to                        to                    to
    IP Address                IP address            IP Address
    using                      using                using
    Xmtr setup                Reverse DNS          Normal DNS
 
The steps for a receiver to perform a PTR authentication are:
 
1) Look at the session request (HELO/EHLO command) to get the "HELO name" assigned by the Transmitter Operator.
 
2) Do a [[Reverse DNS]] query to get the "IP name" assigned by the Network Owner.  Compare to the HELO name.
 
3) Do a normal DNS query on the HELO name to get the IP addresses assigned by the Domain Owner to that name.  Compare to the IP address from the TCP connection.
 
=== Bibliography ===

Revision as of 13:57, 28 October 2009

Edit status:

Definition: Method for authenticating an association of a domain name with an IP address.

This article is a subtopic in a group of articles under Email system. We assume the reader understands the parent article, its terminology, and the roles of different agents in the system. The reader should also be familiar with the basics of Email authentication and with the article on Reverse DNS.

Forward-Confirmed reverse DNS (FCrDNS) is an email authentication method that uses the source IP address in a TCP connection to verify a domain name. A receiver does a Reverse DNS query on the IP address to learn the "IP name" assigned to that address by the network owner. If a normal forward DNS query on that name gives a matching IP address, then we have strong assurance that the network owner and the domain owner agree that the IP address and domain name are connected.

Limitations

FCrDNS says nothing about the authorization of an IP address to send email. There must be some external information, perhaps a "PTR term" in an SPF record, saying in effect "Trust our PTR records. We're not as sloppy as everyone else." Otherwise, a Pass result might only mean that a network provider set up PTR records for all addresses in his entire IP block, including dynamic addresses assigned to home computers. Often these network owners are large telecommunication companies, and not responsive to domain owners who want to set up their own PTR records.

The FCrDNS method is one of the least reliable of the email authentication methods. It can provide robust authentication, but seldom does because of the confusion and miscommunication surrounding PTR records.[1] Few receivers rely on FCrDNS as having any value by itself. It is mostly used as a heuristic check along with other inputs to a statistical analysis by a spam filter.

How it works

See the email authentication example in Reverse DNS.

  1. ↑ See the Internet Draft by Senie and Sullivan for detailed discussion of the problems with DNS Reverse Mapping.
Retrieved from "https://citizendium.org/wiki/index.php?title=User:David_MacQuigg/Forward-confirmed_reverse_DNS&oldid=701588"