PTR Records are called as the Pointer Records. These are called as the Reverse DNS Records as it is used for reverse DNS lookups. The DNS best practices suggest that every host on the Internet that has a A record assigned should have a PTR record assigned to its IP address.

As long as there is an A record is available for the host, it should be reacheable on the internet. But, systems like an email or a webserver checks for a PTR record and might refuse connections as a measure of security and or against SPAM. For example, a mail server for example.com can refuse connection to a SMTP sending server for mail.test.com if the either the server did not have a PTR record or if the Reverse DNS lookup did not match the hostname and the IP Address

Syntax:

1.1.168.192.IN-ADDR.ARPA IN PTR www.itsyourip.com

Where,

The first 4 fields seperated by decimal (.) symbols refer to the IP address of the host in reverse order.

IN-ADDR.ARPA is a special Internet domain like a .com domain assigned by IANA specifically for Internet Address to Hostname mapping lookups as per RFC 1035.

The reason for reversing the IP Address on the record is to facilitate the delegation of zones based on the class (Class A or Class B or Class C) of the IP. For example, 10.IN-ADDR.ARPA can be the zone for ARPANET.

PTR records are hosted by the Network Owner. In other words, if you own a whole Class C address space then you are authoritative. However, if you have a few IP addresses from your Internet Service Provider (ISP) then it is very likely that your ISP is authoritative and hence they need to host your PTR records. You would obviously host your internet private network PTR records

The following is an excert from the RFC 1035 (Section 3.5) about the IN-ADDR.ARPA domain (ARPA is Address Routing Parameter Area):

The Internet uses a special domain to support gateway location and Internet address to host mapping.  Other classes may employ a similar strategy in other domains.  The intent of this domain is to provide a guaranteed method to perform host address to host name mapping, and to facilitate queries to locate all gateways on a particular network in the Internet.

Note that both of these services are similar to functions that could be performed by inverse queries; the difference is that this part of the domain name space is structured according to address, and hence can guarantee that the appropriate data can be located without an exhaustive search of the domain space.

The domain begins at IN-ADDR.ARPA and has a substructure which follows the Internet addressing structure.

Domain names in the IN-ADDR.ARPA domain are defined to have up to four labels in addition to the IN-ADDR.ARPA suffix.  Each label represents one octet of an Internet address, and is expressed as a character string for a decimal value in the range 0-255 (with leading zeros omitted except in the case of a zero octet which is represented by a single zero).

Host addresses are represented by domain names that have all four labels specified.  Thus data for Internet address 10.2.0.52 is located at domain name 52.0.2.10.IN-ADDR.ARPA.  The reversal, though awkward to read, allows zones to be delegated which are exactly one network of address space.  For example, 10.IN-ADDR.ARPA can be a zone containing data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for MILNET.  Address nodes are used to hold pointers to primary host names in the normal domain space.

Network numbers correspond to some non-terminal nodes at various depths in the IN-ADDR.ARPA domain, since Internet network numbers are either 1, 2, or 3 octets.  Network nodes are used to hold pointers to the primary host names of gateways attached to that network.  Since a gateway is, by definition, on more than one network, it will typically have two or more network nodes which point at it.  Gateways will also have host level pointers at their fully qualified addresses.

Both the gateway pointers at network nodes and the normal host pointers at full address nodes use the PTR RR to point back to the primary domain names of the corresponding hosts.

For example, the IN-ADDR.ARPA domain will contain information about the ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's

SPF record is a Sender Policy Framework resource record. This is defined as a regular TXT record type.

The SPF record are used to avoid spam emails. SPF record validates the mail server that delivers the email for a domain to check if it is actually an authorised server before accepting any email from it.

For example, When Server X receives an email for a user in the domain xyz.com from a Server Y claiming to be sending an email from the domain abc.com

The receiving Server X checks the SPF records for the domain abc.com and if the Server Y is an authorised sender for this domain then it accepts the email, if it is not an authorised server then rejects the email. This way, the receiving server which checks for the SPF records can reduce the amount of SPAM without even passing them onto various spam checkers and other extensions to the email servers.

The SPF records are simple TXT records although some of the newer version of the DNS servers (BIND 9.4.0) does support a SPF record type. The RFC 4408 for the Sender Policy Framework recommends using a TXT record type or add a duplicate TXT record (if using a SPF record type) as the older version of the Nameserver software do not support the SPF record type.

The record format is as for a TXT record.

<Name> TTL class TXT <text with SPF arguements>

<Name> TTL class SPF <text with SPF arguements>

The text field contains the SPF data.

The SPF data is of the following format.

v=spf1 [<Qualifier><Mechanism>] [<Qualifier><Mechanism>] <optional Modifiers>

where,

v=spf1 defines the version of the SPF format. As of now there is just one version.
 
<qualifier><Mechanism> One of more pair of Qualifier:Mechanism pairs that describes the mailing hosts for the domain.

<modifiers> There can be only one modifer in a SPF record.

Qualifiers

The qualifiers are the paramters that define the action to perform on a match to a Mechanism. There are four Qualifiers:

+ Pass (default)
– Fail
~ SoftFail
? Neutral

Mechanism

The following are the mechanisms that describes the host that sends email for the domains:

all     – Match all
ipv4    – IPv4 Host or Network
ipv6    – IPv6 or Network
a       – Match A records
mx      – Match A records for the MX records
ptr     – Check PTR records
exist   – Check if the Domain checked resolves
include – Check for the SPF record for the domain checked

all

Always matches anything that is compared. Usually comes at the end of the record.

ip4

ip4:<ip4-address>
ip4:<ip4-network>/<prefix>

Checks the IPv4 host or the network range. If no prefix is given then it is assumed as a Host(/32).

ip6

ip6:<ip6-address>
ip6:<ip6-network>/<prefix>

Checks the IPv6 network range. If no prefix is given then it is assumed as a Host (/128).

a

a/<prefix>
a:<domain>
a:<domain>/<prefix>

All the A records for domain are tested and if the client IP is one of them then  this mechanism matches. If domain is not specified, the current-domain is used.

The A records have to match the client IP exactly, unless a "prefix" is provided, in which case each IP address returned by the A lookup will be expanded to its corresponding CIDR prefix, and the client IP will be sought within that subnet.

mx

mx
mx/<prefix>
mx:<domain>
mx:<domain>/<prefix>

The A records for all the MX records for domain are tested in order of MX priority. If the client IP is found among them, this mechanism matches. If domain is not specified, the current-domain is used.

The A records have to match the client IP exactly, unless a prefix is provided, in which case each IP address returned by the A lookup will be expanded to its corresponding CIDR prefix, and the client IP will be sought within that network range.

ptr

ptr
ptr:<domain>

The hostname or hostnames for the client IP are looked up using PTR queries. The hostnames are then validated: at least one of the A records for a PTR hostname must match the original client IP. Invalid hostnames are discarded. If a valid hostname ends in domain, this mechanism matches.

If domain is not specified, the current-domain is used.

exists

exists:<domain>

Perform an A query on the provided domain. If a result is found, this constitutes a match.

include

include:<domain>

The specified domain is searched for a match. If the lookup does not return a match or an error, processing proceeds to the next directive. Warning: If the domain does not have a valid SPF record, the result is a permanent error. Some mail receivers will reject based on a PermError.

Modifiers

Modifiers are optional. A modifier may appear only once per record.

The "redirect" modifier

redirect=<domain>

The SPF record for domain replace the current record.

The "exp" modifier

exp=<domain>

If a receiving receiver rejects a message, it can include an explanation. The SPF record can specify the explanation string that senders can see.

The domain is expanded; a TXT lookup is performed. The result of the TXT query is then macro-expanded and shown to the sender. Other macros can be used to provide an customized explanation.

Examples for SPF Resource Records:

v=spf1 ip4:192.168.0.1/16 -all

Allows any host from 192.168.0.0/16 network

v=spf1 mx -all

Allows only mx servers for the domain and discards anything else (-all)

v=spf1 ptr:example.com -all

Allows any host whose hostname ends as example.com

v=spf1 exists:example.com -all

Matches if the example.com domain resolves

v=spf1 include:example.com -all

Checks the SPF records for the example.com domain and follows the matches for that domain. Fails if there is no SPF record for example.com

To quickly generate a SPF record, plese use the wizard here

To check the SPF record for your domain, click here

A SRV record called as a Service record provides information on available services.

The SRV record has four fields. The naming convention of the SRV record is unique. Following is the naming syntax:

_<SERVICENAME>._<PROTOCOL>.<DOMAINNAME>

Where,

SERVICENAME is the name of the service

PROTOCOL is the name of the protocol ex: TCP

DOMAINNAME is the name of the domain.

An example would be,

_ftp._tcp.itsyourip.com.

The record itself has four fields in it namely,

1. Priority

2. Weight

3. Port

4. Hostname

An example record would look like the following:

_ftp._tcp.itsyourip.com. 86400 IN SRV 10 10 21 ftp.itsyourip.com.

DNS Records are the prime defining factor for a proper functioning of any Name Service. There are various records that can be defined for a Domain of which some carry much importance while the rest are just for information. These important Records are as follows:

NS Record

A Record

MX Record

PTR Record

CNAME Record

SOA Record

NS Record

NS Record Name Server Record which indicates the Authoritative Name Servers for a particular Domain. The NS records of the Authoritative Name Server for any given Domain will be listed on the Parent Server. These are called as the Delegation Records as these records on the Parent Server indicates the delegation of the domain to the Authoritative servers. The NS record will also be listed in the Zone records of the Authoritative Name Server itself. These records are called as the Authoritative Records. The NS records found on the Parent Server should match the NS records on the Authoritative Server as well. However, you can have NS records listed on the Authoritative server that is not listed in the Parent Server. This arrangement is normally used to configure Stealth Name Servers. NS Records syntax: itsyourip.com. IN NS ns1.beta.timdorr.com. where, IN indicates the Internet NS indicates the type of record which Name Server record The above indicates that the ns1.beta.timdorr is the authoritative server for the domain itsyourip.com

A Record

A record is the Address record which maps the domain / host to a valid IP Address. This is the record which indicates that the particular host can be reached at the given IP Address. There can be more than one IP Address to the same host by using multiple A Records. This becomes useful when there are more than one server hosting a domain or a website. A Record Syntax: Itsyourip.com. IN A 69.93.64.122 Where IN indicates Internet A indicates the Address record. The above example indicate that the IP Address for the domain itsyourip.com is 69.93.64.122

CNAME Record

CNAME stands for Canonical Name. CNAME Records are used mainly to assign an alias to an existing hostname. In simple words, a particular host can be referred by more than one Name. However, there should be a A record for the host with its original name (Canonical Name) and the rest of the names assigned to the host are pointing to the original or canonical name. CNAME Syntax: www.itsyourip.com. IN CNAME itsyourip.com. where, IN indicates Internet CNAME indicates CNAME record. The above indicates that www.itsyourip.com is nothing but itsyourip.com and hence, when you type www.itsyourip.com in the address bar of an internet explorer, you end up at itsyourip.com.

MX Record:

MX Record is the Main Exchanger Record. This is a service record which specifies where the mails for a particular domain are to be delivered. There can be more than one MX record for a given Domain. This is to have one or more backup servers to which the mails can be delivered in the event the default server has failed for some reason. The MX records have a field for Priority number. This is mainly to specify which is the first server to which a Domains emails should be delivered and which falls next in the queue in the event the 1st server is down and thereon. The server which has the lowest priority number will be the default server to which the mail is delivered. The next lower priority server will be the 1st backup and the next the 2nd backup server and so on. CNAME Syntax: Itsyourip.com. IN MX 0 mail.pcsupport.x-host.uni.cc Where, IN indicates Internet MX indicates the Mail Exchanger Record The above indicates that mails for itsyourip.com are being delivered to the server mail.pcsupport.x-host.uni.cc. Wilcards can be used in the MX records to allow mails for all the hosts to be delivered to a particular host. For example, *. Itsyourip.com. IN MX 0 mail.pcsupport.x-host.uni.cc indicates that all emails for all the hosts (or subdomains) of itsyourip.com will be delivered to mail.pcsupport.x-host.uni.cc

PTR Record:

PTR Records refer to Pointer Record. This is mostly used to have a particular host be recognized on the internet by using an IP Address instead of the hostname. These are also called Reverse DNS Lookup address. When used for Reverse DNS lookups, these records are exactly the reverse of the original A records with the exception that the address is reversed and added with a in-addr.arpa suffix. PTR Record Syntax: 122.64.93.64.in-addr.arpa. IN PTR itsyourip.com Here as you see the IP Address is reversed and added with in-addr.arpa and this has come to the left side while the actual domain name has gone to right side of IN PTR. This is mostly used as a security and an anti-spam measure wherein most of the webservers or the email servers do a reverse DNS lookup to check if the host is actually coming from where it claims to come from. It is always advisable to have a proper reverse DNS record (PTR) is been setup for your servers especially when you are running a mail / smtp server. SOA Records: SOA records stand for Start of Authority. This is the most important record for a domain. This server indicates the start of authority for the specified domain and will have more information init unlike other where there is only one specific information is provided. The SOA Record indicates the Primary Authoritative server for a Domain, a contact email address, the serial number and the various time related information. The Serial number is the key element which indicates if a Slave or a secondary server should update its information. Everytime a change was made to DNS records, this number is incremented only then when a slave DNS server contacts the primary server will know that there was a change made and hence have to update its record. For this case, the serial number is always used in the YYYYMMDDXX format where YYYYMMDD indicates the date of the day the changes were made and XX indicates the nth number of time the records were changed. SOA Record Syntax: itsyourip.com in SOA ns1.beta.timdorr.com. server.asmallorange.com. 2006011501 ; Serial14400 ; Refresh 7200 ; Retry 3600000 ; Expire 86400 ) ; Minimum Where, IN indicates Internet SOA indicates Start of Authority record ns1.beta.timdorr.com is the Primary Name Server Server.(@)asmallorange.com is the contact email Serial indicates the Serial Number Refresh indicates the time in which it should contact the Primary server for changes in the DNS records (Serial Number) Retry indicates the time in which the slave server should retry in the event a connection was refused by the Primary Server. Expire indicates when the local information that the slave server holds becomes invalid in the event it cannot refresh from the Primary server. Minimum indicates how long other DNS servers should hold this domains information in its cache.