- About Us
- Domain Name Registry Services
- New Top Level Domains
- Mobile & Web Services
- Managed DNS
- Contact Us
Afilias' specialized technology makes Internet addresses more accessible and useful through a wide range of applications, including Internet domain registry services, Managed DNS and award-winning mobile Web services.
Internationalized domain names (IDNs) have been available to Internet users for many years, but this year the first fully non-Latin IDN domains have become enabled by ICANN and country-code top-level domain registries. The recent success of the launch of Russia's .рф (.rf) ccTLD shows that there is an enormous demand for domain names in Internet users' native languages.
Afilias connects the world with reliable, secure, scalable and globally available technology that makes Internet addresses more accessible and useful. Afilias supports a wide range of applications, including Internet domain registry services, Managed DNS, and mobile Web services like goMobi® and DeviceAtlas®.
Our technology Afilias' technology ensures that your service works 100% of the time. Afilias powers key pieces of the Internet's infrastructure, including resolution of all .info, .org and .mobi domains. Afilias' registry and DNS technology is operated on a globally distributed, multi-layered, diverse infrastructure that delivers state-of-the-art security to ensure uptime and protect against malicious attacks. Afilias also supports new standards such as IPv6, DNSSEC, and Internationalized Domain Names. Learn more about our products and services.
Afilias supports an array of top-level domain (TLD) registry and corporate DNS customers. Afilias' customers place high value on staying current with rapidly evolving technology. Our systems are on the leading edge of proven technologies, ensuring that our customers are ready for innovations dictating the future of the Internet. Learn more about the customers Afilias supports around the world.
AFRINIC 18 takes place from 15 to 21 June 2013 during the Africa Internet Summit 2013. The AFRINIC 18 Meeting starts with AFRINIC training sessions. This is followed by an Africa Operators Day and the Social Event. The Meeting ends with the AFRINIC plenaries.
On June 19, 2012, the Chinese Academy of Sciences (CAS) conducted the first public multilingual Internationalized Domain Name (IDN) email trials -- and Afilias was one of the sponsoring participants. IDN email allows people to use almost any language in their email addresses for their user name, second-level IDN domain name and top-level IDN.
The AfriNIC 16 event will take place in Serekunda, The Gambia. The AfriNIC 16 Public Policy Meeting will be held from May 12-18, 2012 during which Internet development related training workshops and policy discussion sessions will be organised.
Afilias is a Silver Sponsor of the upcoming Global INET Conference in Geneva, Switzerland.
Dr. Leonard Kleinrock, a legendary figure in Internet history will present his unique perspectives on the birth of the Internet, the formative period during its early days, and its profound impact on the world today. Dr. Kleinrock’s keynote address is scheduled for Monday morning, 23 April 2012, during the Opening Session of the Global INET.
Visionary keynotes, as industry leaders, Internet pioneers and futurists share their insights and inspirations.
Internationalized Domain Names (IDNs) were first launched in 2004 called IDNA, and now based on IETF standard RFC5890 published in 2010, which use the Punycode encoding algorithm to represent non-ASCII characters found in Arabic, Chinese, Cyrillic, Hindi and other languages, into ASCII (plain text characters and numbers) domain names that the DNS system can resolve. This allows Internet users to type a domain name in their local script using their native language, instead of an English translation.
What is Punycode and how does it work with the DNS?
The Punycode algorithm was adopted as part of international standards for converting non-English characters into ASCII.
To convert IDNs to ASCII, the international characters must first be mapped to a corresponding ASCII string of characters, e.g.: the ü in probestück.info is converted to the ASCII string "w9a." Then a specific prefix (as specified by the standard) "xn--" is added to the beginning of the entire domain name. So the resulting ASCII name for the IDN probestück.info is xn--probestck-w9a.info.
How does this process work with domain name registration?
To register a domain name using IDN characters, registrars use the Nameprep and Stringprep specifications from the IETF to translate the Internationalized name into its punycode equivalent, and submit that domain name to Afilias (or another registry operator) for registration within a TLD that supports IDN domains. The registry actually reserves the â€˜punycode' representation of the domain, and will display that ASCII domain in the WHOIS system.
In order to be registered, each language must be converted into a script "table" that dictates each letter's translation. Typically these language tables are developed and adopted by leading researchers at sovereign governments whose citizens represent a dominant or sole majority of a language.
Domain name registries adopt these "language tables" when they allow a new IDN script to be registered.
What is the difference between an IDN domain name and an IDN TLD?
For years, Internet users have been able to register domain names with International characters in the second level domain string - the part to the left of the last "dot" in the address. In our example above (probestück.info), info is the top-level domain and probestück is the second level.
Only recently has ICANN begun to allow IDN characters to be represented to the right of the last "dot," or at the top-level domain level. Currently, this process is only underway for country code top-level domains (ccTLDs).
For example, The Jordanian registry officially launched the Arabic version of its ccTLD as .alordon which translates to xn--mgbayh7gpa using the Punycode algorithm and is visible in Arabic as Ø§Ù„Ø§Ø±Ø¯Ù†.
A list of ccTLD that have requested their IDN string to ICANN, and their status is available here http://www.icann.org/en/topics/idn/fast-track/string-evaluation-completion-en.htm
User accessibility of IDN names through browsers
When a user types an IDN into a browser, the application must know how to convert the name into â€˜punycode' for it to be handled properly by the registry. Most current versions of commercial browsers are compliant with the international â€˜punycode' standard.
In these browsers, when a user types in an IDN name, e.g.: probestück.info, the browser uses the Nameprep and Stringprep specifications to translate the name into the â€˜punycode' string xn--probestck-w9a.info. The browser then sends this â€˜punycode' string to Afilias' .INFO TLD nameserver, where the name is looked up in the zone file like ASCII domains are today.
As in normal DNS queries to resolve ASCII domains, the TLD nameserver will respond with one of two answers: either "YES" this name exists, or "NO" this name does not exist (i.e.: NX domain record). If the name exists, the TLD nameserver will return the nameserver for the domain. The DNS resolver will then query that nameserver for the hostname. If the hostname exists, the IP address will be returned and the browser will be able to use it to connect to the web server and website for probestück.info. If the answer is NO, then the user will get a NX domain response or the error "this domain does not exist." Many browsers will return a 404 error, or may provide a redirected search page.
The following are the new set of RFC for IDN 2008.