According to RFC1034, “cnn.com” and “cnn.com.” should be the same domain names. However, it doesn’t appear that programmers always understand that trailing dots can be added to domain names.

For example, these two URLs both go to the CNN Web site in Internet Explorer:

- http://www.cnn.com/
- http://www.cnn.com./

According to RFC1034:

“Since a complete domain name ends with the root label, this leads to a printed form which ends in a dot. We use this property to distinguish between:

- a character string which represents a complete domain name (often called “absolute”). For example, “poneria.ISI.EDU.”

- a character string that represents the starting labels of a domain name which is incomplete, and should be completed by local software using knowledge of the local domain (often called “relative”). For example, “poneria” used in the ISI.EDU domain.”

However, Internet Explorer considers these two domain names to be different when it comes to cookies. “cnn.com.” gets a different cookie from “cnn.com”. This behavior of Internet Explorer appears to be a bug, but probably not a particularly bad one.

Here’s another example at Internic, which treats the query “com” different than “com.”.

- http://reports.internic.net/cgi/whois?whois_nic=com&type=domain
- http://reports.internic.net/cgi/whois?whois_nic=com.&type=domain

This issue might only be a minor problem on the edges, that’s of academic interest only. However, since so many different kinds of software work with domain names, it is hard to know for sure.

For example, here is a situation when bad things can happen—“WebShield SMTP infinite loop DoS Attack”:

“A DoS attack is very easy to implement on most WebShield SMTP setups. Sending E-mail with a “From: ” address that includes a period after the domain name will cause an infinite loop using up resources until the server will finally crash. When restarted, the machine will continue to crash until the offending E-mail is manually removed.

Details:

The problem occurs because WebShield SMTP does not recognize that “domain_name.com” and “domain_name.com.” are equivalent (both are valid forms of fully qualified domain names (FQDNs); with the period, it is referred to as a rooted FQDN). Both forms should work with all mail clients and servers. However, using the trailing “.” is rarely used (except in DNS maintenance).

When a WebShield SMTP server is set up to accept incoming mail, it is typically configured to recognize at least one local domain. This is necessary since WebShield SMTP is placed before the real SMTP server. For example, if you run the domain “domain_name.com”, you would configure WebShield SMTP to send all mail for “domain_name.com” to your real SMTP server.

The problem arises when mail is sent to “userdomain_name.com.”, which is an acceptable way to address the mail. WebShield SMTP does not recognize that “domain_name.com.” is a local address (even though it knows that “domain_name.com” is a local address). So, it looks up the MX record for “domain_name.com.”, which points to the WebShield SMTP server (it always will; that’s how the mail got there in the first place). It then sends itself a copy of the message, adding a “Received: ” line (per RFC821/RFC822). The message will continue to be sent to itself, growing each time as a new “Received: ” line is added. As the file gets larger (to several megabytes), lots of CPU time is required to process and scan the E-mail, and more and more disk space is used for the E-mail itself and log files.

In one example, a short E-mail was looped through the WebShield SMTP server over 37,000 times in under a day, growing to 4 megabytes. This was using WebShield v4.5. This can only be reproduced on a machine that has an MX record pointing to it (a test machine won’t normally be able to reproduce this).

The Attack:

Send an mail to “anythingdomain_name.com.”.

Work Around:

The workaround is simple. In delivery options for Remote Send, under the Direct Send option, add “domain_name.com.” as one of the domain names to route to the local mail server. Do this for every domain name your mail server handles.”

(Source: Archives.Neohapsis.Com)

Web servers also can’t seem to agree what to do with a period at the end of a host name. IIS, thttp, and Akamai’s Web server all get confused while Apache doesn’t seem to care.

So here are the key questions:

- How much other software behaves incorrectly because of a trailing period on a domain name?
- Can spam-filtering software be bypassed with dotted email addresses?