|
How i-DNS Works
This section is technical and presupposes prior networking knowledge. General readers might find the FAQ or our article on Domain Names for beginners more useful.
How the Current DNS System Resolves Domain Name Queries
For example, we input i-DNS.net instead of 203.81.44.31.
Upon receipt of a query via a client/end user's browser, the DNS server checks its cache to see if there is any way to resolve the name, and returns the IP to the client if successful.
If it can't resolve from the data that is within its own server cache, it will send a request to a DNS root server. The latter will determine which Top Level Domain (TLD) or Country Code Top Level Domain (CCTLD) the domain name belongs to. The TLD or CCTLD domain server will then determine which server it should forward the data to for further resolving.
Once this particular domain is found, the IP is sent back via to the client (end-user's browser). The client can now access the desired information from the IP of choice.
Back to top
How i-DNS resolves Multilingual Domain Name Queries
i-DNS offers 3 solutions for resolving Multilingual Domain Name Queries, ranging from Client to Server to Client and Server Combined.
This is to ensure a comprehensive and flexible range of resolution offerings, meeting different requirements and needs.
1) Server-side Solution
Here, the end-user inputs  instead of i-DNS.net.
The client's browser will send the request to an i-DNS-compatible server (e.g. ISPs). Here, the multilingual string is first converted into a universal encoding type, Unicode (ISO/IEC 10646). It is then fed through a transformation process from the UCS-4 range to produce an ASCII/DNS Compatible Encoding (ACE). In this example, in UTF-5 (an encoding type that falls under ACE) is L6FDP645L316L7DFL40D.L16CL3F8. After transforming the multilingual string to an ASCII compatible encoding, the server will perform a DNS lookup and return the respective IP address, resolving the request.
2) Client-side Solution
The same conversion, transformation and DNS look-up process occurs for our Client-side solution, via the usage of our iClient software. It is just that the above process occurs at the client's computer, instead of an i-DNS compatible server.
Because the final domain name produced (for both the solution types) from the original UTF5 name by the series of transformations is within the ASCII range allowed by the current DNS, i-DNS is completely compatible with all standard Internet protocols and existing clients/servers. It also means that the current DNS designed for alphanumerical character set can be multilingual enabled and internationalized immediately. It works for everything from HTTP to SMTP and requires little or no change to the current system.
3) Client-side & Server-side combined Solution
The third solution is designed to only work for URL resolution in Internet Explorer (IE). The reason for this being we are using BHO approach which is specific for IE. The flow of the data is described as shown above. At a client side, a HTTP request containing multilingual domain name is transformed into a hex-encoded UTF8 string after which it is then sent to the iSearch Server as HTTP request for resolution. At the server side, if a possible ACE equivalent name can be generated from the received multilingual domain name, the iSearch server will replace the part with its ACE equivalent and do a URL forward on the resulting string.
* Based on Unicode, i-DNS supports all legacy encoding standard, including GBK, BIG5, Shift-JIS, EUC-KR (widely used in China, Taiwan, Japan and Korea respectively), ISO-8859 standard (used in European and Middle East) and Windows CodePages (used in localized Windows 3.1 and 95 system). In addition, it also supports UTF-8 (used in Windows 98/2000/ME, Internet Explorer, Netscape 6 & 7, Mozilla) and various others ACE such as RACE, LACE, DUDE, Punycode, AMC-ACE-Z and UTF-8.
Back to top
|
