Using example domains

People have put example domains in all kinds of programs and servers, often using example.com, example.net, or example.org – along with such as test.com, anywhere.com, anywho.com, somewhere.com, anytownusa.com, and so on.

All of these are domains that resolve and have actual servers up and running on the Internet. Of those mentioned previously, only example.com, example.net and example.org are preserved for testing purposes by IANA in RFC 2606.

Better yet, when using example email addresses avoid any surprises by using one of these domains specified in RFC 2606:

  • .example (for documentation)
  • .test (for testing purposes)
  • .localhost (for sending to the local host)
  • .invalid (for creating guaranteed invalid domain names)

If you use these domains, you won’t have to worry about mail going out that wasn’t supposed to go out. I’ve seen this happen before – a configuration file sent out with an open source server sends mail to an example address – which address turns out to go to a valid domain on the Internet, where it is accepted by the mail host.

Don’t get caught by this mistake! Use the RFC 2606 domains wherever needed, and don’t make one up of your own.

The Domain Name System (DNS), Internationalization, and More

The DNS service has been in the news recently, most specifically when ICANN held the 36th ICANN Conference in Seoul, South Korea and decided to allow internationalized country code top-level domains (abbreviated as ccTLDs). The Russians and the Chinese have been after ICANN to do this for some time – and not with any real resistance from ICANN either. Over at the CircleID blog, they have a nice recap of the meeting.

The biggest problem was technological, and over the last several years ICANN and the DNS powers-that-be have worked diligently to implement a method of supporting Unicode domains – the approved method was the Internationalizing Domain Names in Applications (IDNA).

The biggest problem – which unfortunately hits the Russians and other users of the Cyrillic alphabet hardest – is that some of the domains will look like Roman (alphabet) domains. The most prominent example is the counterpart to the current .ru domain; the equivalent cyrillic example would be .py (which is the Republic of Paraguay). Of course the computer has no problems – the letters are different – but the human user could confuse the two, making a new angle to phishing attacks.

The presence of new internationalized domains may make a difference to you if your company is international – especially if it is located in another country. Countries such as France and Canada and Mexico won’t be affected, but many others will be – Japan and China and many Middle Eastern countries come to mind (with Japanese, Chinese, Arabic, and Hebrew domains coming to mind).

Getting a new international domain will mean making sure that all programs can handle the internationalized domains – such as mail clients, mail servers, local DNS servers, and more. Unless a complete conversion is mandated, it can be done alongside of the current working DNS service. Make sure that you brainstorm and work with as many affected individuals as possible to make the new DNS domain work; this becomes especially critical during a total conversion.

On the heels of the wrap-up of the meeting in Seoul is Paul Vixie’s article in the ACM Queue entitled What DNS is Not. He talks about how DNS is not a policy-making protocol, but rather an expression of facts (mapping names to addresses).