Sender Policy Framework

The Domain Name System.

Table of Contents

• Intro
• Tree
• Node
• Label
• Domain
• Subdomain
• Delegation
• Zone
• Resource Record
• Underscore
• Caching
• Editing examples

Intro

Terms like domain and Record are often used in an inappropriate way. Please take some time to read this short tutorial. It is by no means complete; if you would like to know more please buy a good book or use your favorite search engine.

Tree (edit)

DNS is often shown as an upside down tree like structure, much like a family tree. The big difference is that in the DNS tree, there can be only one parent. All "family members" in the tree are called nodes.

Each node in the tree has a label.

A series of such labels form a domain.

Each node in the tree can, but does not have to, store Resource Records wherein information is stored.

The tree is divided in zones. Management of such a zone can be delegated to someone else, for instance you. All domains in such a zone are then under your control.

Node (edit)

There is one special node in DNS, called the root node. This is the one node that has no parents, at the top of the upside down tree. All other nodes have exactly one parent. The root node is also the only one that has an empty label.

Nodes can have zero or more children. There's nothing special about a node that has no children, although sometimes it is referred to as a Leaf Node.

Nodes that have the same parent are sometimes called sibblings. Such nodes cannot have the same label.

Label (edit)

Each node in DNS has a label. The root node has an empty label. All other nodes have a label of at least 1 character and at most 63 characters long. Examples are: "com", "org", "net", "example", "provider", and so on.

Nodes that have the same parent are sometimes called sibblings. Such nodes cannot have the same label. Example: if two nodes have the same parent node labeled "com", they cannot both be labeled "example".

Domain (edit)

Simply put, a domain name is the concatenation of all labels found when you start at a node and follow the tree right upto the top. Write down each label separated by a dot. This is a bit simplified. The dots are really only a way to represent label separators, but for our purpose you can just use what I said.

Example: start at a node labeled "www". Write down "www". Then notice this node has a parent, called "example". So far you have "www.example". Then follow the tree to the next parent, which is labeled "com". You have "www.example.com". Then there's one more parent, which is the root node. It has an empty label. Append it, and end up with "www.example.com.". As you may have understood, this name does not end with a dot. There's an empty label at the end, not a dot.

This last step, appending the root node, is often left out. You still need to remember about this node, it could be important if you are going to edit a zone. For example: in bind zone files you need to type "mail01.example.com." and not "mail01.example.com", or else bind will append "example.com." and you end up with "mail01.example.com.example.com." !

All domains used in SPF need to be Fully Qalified Domain Names and this renders the root node redundant. You can leave it out (in fact: it usually is).

Some misconceptions:

• A domain is not the part following "www".
• A domain is not what most people get from their provider. Most people get a zone.
• A domain is not a web site or an e-mail address.

Please let me explain:

A Domain Name is nothing more (or less) than a name for a node in the DNS system. Every node has such a name.

If you got "example.com" from your provider, with separate names for a webserver, an ftp server and a mail server, you have one zone with four domains (the number can vary), for instance: example.com, www.example.com, ftp.example.com and smtp.example.com

When us SPF people talk about domains, we talk about domains, not about zones. If you need to publish an SPF policy for a domain, that is a big difference. If we ask if domain www.example.com is used to send email, we ask about domain www.example.com, not about zone example.com ! Also see this common mistake.

Subdomain (edit)

There's not much different between subdomains and domains. Every subdomain is also a domain, and all but one domains are subdomains. The only domain that is not a subdomain, is the root domain.

It's better to say "... is a subdomain of ...".

• www.example.com. is a subdomain of example.com.
• www is not a subdomain.

Delegation (edit)

One reason to start with DNS was to be able to delegate authority over parts of the name space to others. Part of the tree can be separated from the rest and get its own keeper. This can be repeated. For instance, the keeper of the entire tree has delegated authority over "com." to someone else. This someone else has delegated authority over "example.com." to yet someone else.

Important to understand is this: the keeper of "example.com." does not have authority over domain "example.com." but over the entire zone "example.com.".

Zone (edit)

If delegation occurs, a new DNS Zone is formed. A zone starts at a particular domain and contains all of the partial tree below it, until another zone starts. This is best explained with an example: Zone "example.com." exists. The keeper of this zone has created the following domains:

 www.example.com.
 ftp.example.com.
 eu.example.com.
 us.example.com.
 mail.example.com.
 (in addition: domain example.com. also exists)

Then he delegates authority over "eu.example.com." and "us.example.com." elsewhere, meaning two new zones are formed.

 Zone "example.com." contains domains example.com. , www.example.com. , ftp.example.com. and mail.example.com.
 Zone "eu.example.com." contains domain "eu.example.com."
 Zone "us.example.com." contains domain "us.example.com."

Its respective keepers can create more domains in their own zone, for instance "www.eu.example.com." which is not part of zone "example.com." !

A new zone can be recognized because there will be a special Resource Record, a SOA record, defining authority over that part of the tree. There will also be NS records, pointing to servers serving this zone's data.

Resource Record (edit)

Resource Records are containers for data. There are several different types of records, each useful for another type of data. Quite often Resource Record is abbreviated to "RR" or "record".

Each node can hold zero or more RRs. It is perfectly OK to have a node with no records at all, this does not make the name disappear from the tree (despite what djbdns and powerdns would like you to believe).

Some frequently seen types are:

A

holding an address (like 192.0.2.1)

MX

holding a Mail eXchange with preference number, such as "10 mail1.example.com." and "100 mail2.example.com."

CNAME

roughly saying: "this is not an official name. Look there instead." If a domain has a CNAME RR, there cannot be another kind of RR (there's one exception, which will not be discussed here). For e-mail, and thus for SPF, you will need to look at the official domain name. Example: "alias.example.org. CNAME canonicalname.example.org." means you need to define an SPF policy for canonicalname.example.org and not for alias.example.org.

SOA

Start Of Authority, see delegation.

NS

Name Server, see delegation.

TXT

can contain any kind of text. The SPF project uses (some say: abuses) this RR type for their own purpose

Also existing:

SPF

a new RR type, created for the SPF project. It will take some time for all DNS software manufacturers to implement this type.

N.B. You create an SPF policy, which can be stored in an SPF record and/or in a TXT record.

Underscore (edit)

Hostnames can only contain letters, digits and dashes. But domainnames can contain any character, including underscore. Quite often an underscore is used to avoid misinterpreting a domainname for a hostname.

Example: domain "_spf.example.org." could exist. There's no chance that this would collide with an existing host. This domain could hold an SPF policy which customers of provider "example" can include.

In the past not all DNS software could handle underscores in DNS, but things have changed rapidly. Chances are you can use it in your user interface.

Caching (edit)

When DNS records are queried, the answer contains a Time To Live (TTL) value. This is the amount of time, in seconds, that the answer should be remembered. If the same question is asked again during this time, a local copy of the answer is returned, the responsible DNS server is not queried again.

Make sure you don't get bitten by this when you modify your SPF record:

1. You test your existing record using one of the validators, or you look it up, whatever
2. You modify your SPF policy and publish a new record
3. You try testing your new policy. In stead you're looking at your previous policy.

Make sure you don't get bitten by this when you move to another provider:

1. You decide to change from cable to dsl. This means getting another IP address
2. You disconnect your host from one connection, connect it to the other. You give it the new IP address (or let DHCP take care of it)
3. You change your SPF policy and publish the new record, authorizing the new IP address.
4. You send mail to a relative. This relative's host still has your previous SPF record cached thus rejects your message.

Similar, but different:

1. You send mail, from your office, to a customer
2. There's a power failure at your office
3. You change your SPF policy so that it authorizes another location
4. You go to that other location
5. You send mail to that same customer. Your message is rejected, because the customer is still using the previous SPF record, not the new one

You've prepared for this failover situation. Your SPF record contains a hostname, not an IP address.

1. You send mail, from your office, to a customer
2. There's a power failure at your office
3. You change the hostname so that it points to another server at another location
4. You go to that other location
5. You send mail to that same customer. Your message is rejected, because the customer is still using the hostname's previous IP address, not the new one

Notice how remarkable similar these last two examples are... Using a hostname is not going to help.

Then what should you do?

• If you have a backup location to send your mail, authorize it in your policy before something happens, not after the problem occurs.
• If you are going through a planned change, make sure your DNS records have a low enough TTL value. Say the current TTL value is 86400 (one day). A little more than one day before the change, alter the number in 43200. A little more than half a day before the change, alter the number in 3600. One hour before the change, alter the number in 60. Do your changes, including changes in DNS. The entire world should know about the new situation within 60 seconds (30 on average). Test your new DNS settings. If they are wrong, fix them and it takes another 60 seconds for the world to know. Once you're happy with the new situation, change the value back to 86400.

Editing Examples (edit)

123-reg.co.uk

1. Log in to your 123-reg control panel and choose the appropriate zone.
2. Choose “Manage DNS”.
3. Under “Add new entry” enter “@” for the name, “TXT” for the type, and use your SPF policy for “Content”.
4. Don't forget to create and publish a policy for other domains in your zone (see FAQ/Common mistakes)

Based on information provided by Dave Cardwell