Home / Blogs

Is Industry Underestimating the Ending Dot?

Richard M. Smith

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?

By Richard M. Smith, Computer & Internet Security Expert

Related topics: DNS, Domain Names, Spam, Whois

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:

Comments

Re: Is Industry Underestimating the Ending Dot? Karl Auerbach  –  Oct 16, 2003 11:25 AM PST

The Windoz community seems to have skipped the class titled "Introduction to the Internet"

Software that doesn't handle fully qualified domain names (FQDN), i.e. names ending in a dot, is, in a word, broken.  And broken software should a) have been better tested before it was released and b) fixed.

Anyone who ever builds a DNS "zone" file quickly learns to be careful about whether there is a trailing dot or not.

By-the-way, the notion of FQDN and trailing dots exists only at the human interface level.  The names carried in DNS query and response packets are always fully qualified.

Re: Is Industry Underestimating the Ending Dot? Matthias Leisi  –  Jan 07, 2004 11:07 AM PST

Maybe the most visible dot-error: Try http://www.google.com./search?q=ending+dot and then look at the links for the "Images", "Groups" etc. tabs: http://groups.com./groups?q=ending+dot&hl=en&lr=&ie=UTF-8&sa=N&tab=wg

To post comments, please login or create an account.

Related Blogs

Related News

Topics

Industry Updates – Sponsored Posts

Top Level Domain Holdings Raises $14M for New gTLDs

.ORG COO Discusses Priorities With DailyVista, Pursuit of .NGO Domain

StarHub to Acquire '.starhub' New Top-Level Domain

ARI Registry Services Signs 21 Contracts in the First Week of New TLD Applications

MarkMonitor to Exhibit at Internet Tech Policy Exhibition and Reception to be Held on Capitol Hill

Sedari Signs With Dot Moscow Bidders

.ORG, The Public Interest Registry Welcomes Nancy Gofus As Chief Operating Officer

Minds+Machines Works with .bayern

The New Domain For Japan, JP.NET, Launches With Exclusive Invitation to Trademark Owners

Being a .PRO When Choosing a Registry Services Partner

UK Cabinet Office Looks to BlueCat Networks' Expertise and Best Practices for Securing PSN

Afilias Acquires Registry Services Corporation, .PRO

Thoughts on Applying for a Generic Top-Level Domain

Sedari Launches "Guess the Numbers Game" for New TLD Program

dot Brand Makes Its Debut: Afilias Advises Companies to Act Now for Successful TLD Applications

BlueCat Networks Helps Organizations Transition to IPv6 with HP

BlueCat Networks to Host Webinar on DNS, DHCP and IPAM Featuring Independent Research Firm

Facets of gTLD Registry Technical Operations - Registry Services

Technology and Finance Industries to Dominate New gTLD Applications

.CO Internet Selects Sedo to Broker Previously Unreleased .CO Domain Names

Hot Topics

Afilias

DNSSEC

Sponsored by
Afilias
dotMobi

Mobile

Sponsored by
dotMobi
Minds + Machines

Top-Level Domains

Sponsored by
Minds + Machines
Neustar UltraDNS

DNS

Sponsored by
Neustar UltraDNS
Verisign

Security

Sponsored by
Verisign