Training Example: InterNIC – Review the Data, Give Your Score & Compare to the Real AI Evaluation

Home
Registrars
Whois
FAQ

[H2] InterNIC—Public
Information Regarding Internet Domain Name Registration Services

Do you have a complaint or dispute?
Your Registrar or Domain Name:
Domain Name Transfer Dispute
Unsolicited Renewal or Transfer Solicitation
Your Registrar is Not on the Accredited List
Unauthorized Transfer of Your Domain Name
Trademark Infringement
Registrar Services Dispute
Failure to answer phones or respond to email messages
Financial Transaction Issues

Uniform Domain Name Dispute Resolution (UDRP) Intake Report System

Inaccurate Whois Information
Spam or Viruses
IP Address Issues
Content on a Website

Information about Registrars
Search Accredited Registrar Directory
Have a Problem with a Registrar?
Complaint Form
Helpful Hints

Information about Whois

Search Whois
Report Inaccurate Whois Listing

FAQs and Information
FAQs (ICANN)
Domain Transfer FAQs
Explanation of Domain Name System
Glossary
of Terms

InterNIC is a registered
service mark of the U.S. Department of Commerce. It is licensed
to the Internet Corporation for
Assigned Names and Numbers, which
operates this web site.

[H3] InterNIC
FAQs

[H2] Please note: You are viewing archival ICANN material. Links and information may be outdated or incorrect. Visit ICANN's main website for current information.

[H3] The Domain Name
System: A Non-Technical Explanation – Why Universal Resolvability
Is Important

What is the Domain Name
System?
The Domain Name System (DNS)
helps users to find their way around the Internet. Every computer on
the Internet has a unique address – just like a telephone number
– which is a rather complicated string of numbers. It is called
its "IP address" (IP stands for "Internet Protocol").

But it is hard to remember
everyone's IP address. The DNS makes it easier by allowing a familiar
string of letters (the "domain name") to be used instead of
the arcane IP address. So instead of typing 192.0.34.65, you can type
www.icann.org. It is a "mnemonic"
device that makes addresses easier to remember.
Translating the name into
the IP address is called "resolving the domain name." The
goal of the DNS is for any Internet user any place in the world to reach
a specific website IP address by entering its domain name. Domain names
are also used for reaching e-mail addresses and for other Internet applications.

What is universal resolvability
and why is it important to users?
Think of the phone system . . .
when you dial a number, it rings at a particular location because there
is a central numbering plan that ensures that each telephone number
is unique. The DNS works in a similar way. If telephone numbers or domain
names were not globally unique, phone calls or e-mail intended for one
person might go to someone else with the same number or domain name.
Without uniqueness, both systems would be unpredictable and therefore
unreliable.
Ensuring predictable results
from any place on the Internet is called "universal resolvability."
It is a critical design feature of the DNS, one that makes the Internet
the helpful, global resource that it is today. Without it, the same
domain name might map to different Internet locations under different
circumstances, which would only cause confusion.
When you send an e-mail to
your Aunt Sally, do you care who receives it?
Do you care if it goes to
your Uncle Juan instead? Wait a minute…do you have an Uncle Juan?
Then whose Uncle Juan received it? Do you care if it reaches Aunt Sally
if you send it from work but my Uncle Juan if you send it from home?

Of course you care who receives
it . . . that's why you wrote it in the first place.
Whether you're doing business or sending personal correspondence, you
want to be certain that your message gets to the intended addressee.
If at any point the DNS must
make a choice between two identical domain names with different IP addresses,
the DNS would not function. It would not know how to resolve the domain
name. When a DNS computer queries another computer and asks, "are
you the intended recipient of this message?", "yes" and
"no" are acceptable answers, but "maybe" is not.

Where does ICANN come
in?
This is where ICANN comes
in . . . ICANN is responsible for managing and coordinating
the DNS to ensure universal resolvability.
ICANN is the global, non-profit,
private-sector coordinating body acting in the public interest. ICANN
ensures that the DNS continues to function effectively – by
overseeing the distribution of unique numeric IP addresses and domain
names. Among its other responsibilities, ICANN oversees the processes
and systems that ensure that each domain name maps to the correct IP
address.
What goes on behind the
scenes?
Behind the scenes, the story
becomes a little more complicated.
In an Internet address –
such as icann.org – the .org part is known as a Top Level Domain,
or TLD. So-called "TLD registry" organizations house online
databases that contain information about the domain names in that TLD.
The .org registry database, for example, contains the Internet whereabouts
– or IP address – of icann.org. So in trying to find the Internet
address of icann.org your computer must first find the .org registry
database. How is this done?
At the heart of the DNS are
13 special computers, called root servers. They are coordinated by ICANN
and are distributed around the world. All 13 contain the same vital
information – this is to spread the workload and back each other
up.
Why are these root servers
so important? The root servers contain the IP addresses of all the TLD
registries – both the global registries such as .com, .org, etc.
and the 244 country-specific registries such as .fr (France), .cn (China),
etc. This is critical information. If the information is not 100% correct
or if it is ambiguous, it might not be possible to locate a key registry
on the Internet. In DNS parlance, the information must be unique and
authentic. Let us look at how this information is used.
Scattered across the Internet
are thousands of computers – called "Domain Name Resolvers"
or just plain "resolvers" - that routinely cache the
information they receive from queries to the root servers.
These resolvers are located strategically with Internet Service Providers
(ISPs) or institutional networks. They are used to respond to a user's
request to resolve a domain name – that is, to find the corresponding
IP address.
So what happens to a user's
request to reach our familiar friend at icann.org? The request is forwarded
to a local resolver. The resolver splits the request into its component
parts. It knows where to find the .org registry – remember, it
had copied that information from a root server beforehand – so
it forwards the request over to the .org registry to find the IP address
of icann.org. This answer is forwarded back to the user's computer.
And we're done. It's that simple! The domain name icann.org has been
"resolved"!
Why do we need the resolvers?
Why not use the root servers directly? After all, they contain essentially
the same information. The answer is for reasons of performance. The
root servers could not handle hundreds of billions of requests a day!
It would slow users down.
If you are still with the
story, you are already wondering about more complicated names with more
parts such as www.icann.org. Well, the DNS is a hierarchical system.
First, the resolver finds the IP address for the .org registry, queries
that registry to find the IP address for icann.org, then queries a local
computer at that address to find the final IP address for www.icann.org.
Just what you would expect.
It is important to remember
the central and critical role played by the root servers that store
information about the unique, authoritative root. Confusion would result
if there were two TLDs with the same name: which one did the user intend?
The beauty of the Internet architecture is that it ensures there is
a unique, authoritative root, so that there is no chance of ambiguity.
What about "alternate
roots?" How do they fit into this picture?
Anyone can create a root
system similar to the unique authoritative root managed by ICANN. Many
people and entities have. Some of these are purely private (inside a
single corporation, for example) and are insulated from having any effect
on the DNS. Some, however, overlap the authoritative global DNS root
by incorporating the unique, authoritative root information, and then
adding new pseudo-TLDs that have not resulted from the consensus-driven
process by which official new TLDs are created through ICANN. The alternate
root operators persuade some users to have their resolvers "point"
to their alternate root instead of the authoritative root. Others (New.net
is a recent example) also create browser plug-ins and other software
workarounds to accomplish similar effects. The one uniform fact about
all these efforts is that these pseudo-TLDs are not included in the
authoritative root managed by ICANN and, thus, are not resolvable by
the vast majority of Internet users.
Why do alternate roots
create a problem?
There are many potential
problems caused by these unofficial, alternate root efforts to exploit
the stability and reach of the authoritative root. These efforts are
often promoted by those unwilling to abide by the consensus policies
established by the Internet community, policies designed to ensure the
continued stability and utility of the DNS.
For example:

First, the names of some
of these pseudo-TLDs could overlap TLD names in the authoritative
root or those that appear in other alternate roots. Our familiar friend
icann.org could appear in two different roots. Your e-mail to Aunt
Sally could end up with my Uncle Juan.

Second, the unknowing
users might not be linked to one of these alternate roots and not
be able to reach these pseudo-TLD addresses at all. Your e-mail to
Aunt Sally could end up as a dead-letter.

Third, those purchasing
domain names in these pseudo-TLDs may not be aware of these and other
consequences of the lack of universal resolvability. Or they may be
under the impression that they are experiencing universal resolvability
when in fact they are not. They may be very upset to learn that the
names they registered are also being used by others, or that a new
TLD in the authoritative root will not include those names.

These problems are not significant
so long as these alternate roots remain very small, that is, house few
domain names with little potential for conflict. But if they should
ever attract many users, the problems would become much more serious,
and could affect the stability and reliability of the DNS itself. Users
would lose confidence in the utility of the Internet.
What is ICANN's role?
ICANN's mission is to protect
and preserve the stability, integrity and utility – on behalf of
the global Internet community – of the DNS and the authoritative
root ICANN was established to manage. ICANN has no role to play with
alternate roots so long as these and other analogous efforts do not
create instabilities in the DNS or otherwise impair the stability of
the authoritative root. But ICANN does have a role to play in educating
and informing about threats to the Internet's reliability and stability.

ICANN is a consensus development
body for the global Internet community, and its focus is the development
of consensus policies relating to the single authoritative root and
the DNS. These policies include those that allow the orderly introduction
of new TLDs.
There are those–including
operators of commercialized alternate roots–who pursue unilateral
actions outside the ICANN consensus-development process. Many hope to
circumvent these processes by claiming to establish some prior right
to a top-level domain name. ICANN, however, recognizes no such prior
claim. ICANN will continue to reflect the public policy consensus of
the global Internet community over the private claims of the few who
try to bypass this consensus.
In Short . . . . . .
Just as there is a single
root for telephone numbers internationally, there must be a single authoritative
root for the Internet, administered in the public interest.

[IMG: smalbar2.gif (850 bytes)]

This
page last updated
02-Sep-2016