|
Domain and Sub Domain Naming
The domain name system (DNS) is a collection of protocols, software that implements those protocols, and computers that translate host names like www.psu.edu into numeric IP (Internet Protocol) addresses like 128.118.25.3 which computers on the Internet use to communicate with each other. Without DNS, we'd all be memorizing 32-bit integer IP addresses, instead of intuitive and easy to remember host names, URLs or e-mail addresses.
The DNS is a distributed database (which means no single organization is responsible for updating it) used by TCP/IP applications to "map" between hostnames and IP addresses. Each site (University, department, or campus) may maintain its own database of information and run a server that other systems across the Internet can query. This distributed database allows local control of the segments of the overall database, yet data in each segment are available across the entire network through a client/server scheme. No single server stores all of the information.
The Domain Name Space:
Every domain has a unique name called a "domain name." A domain name identifies a domains position in the DNS database. It is essentially just a path represented in a large inverted tree, called the domain name space (see figure 1). In DNS, each domain can be administered by different organizations. Each organization can then separate its domain into a number of subdomains and dole out responsibility for those subdomains to other organizations. For example, different Penn State colleges, departments and organizations within the ".PSU.EDU" domain have chosen to establish separate subdomains.
Each node on the "tree" represents a domain. Everything below a node falls into its domain. One domain can be part of another domain. For example, the domain "tns" is part of the ".psu" domain which is part of the ".edu" domain. Each domain can be further divided in to additional "branches" or partitions, called subdomains.
On the Internet, the domain is the DNS name (that has been converted from a specific numeric address) that gets you there, and consists of a hierarchical sequence of names (labels) separated by periods (dots). The "PSU.EDU" extension on a Penn State hostname is called the Penn State Domain.
DNS software is generally made up of two elements: a DNS "name server" and a "resolver." The name server constitutes the server half of the DNS's client-server mechanism and responds to requests by "mapping" name-to-address conversions. For instance, when a user types in a hostname or an e-mail address, DNS invokes an application program and supplies the name of a machine with which the application must communicate. The application must find the machine's IP address. It passes the domain name to a resolver and requests an IP address. The resolver will attempt to "resolve" the request by querying name servers further up the "tree." If that doesn't work, the second name server will ask yet another - until it finds one that "maps" the IP address to the request.
Note: This policy does not address the configuration of the resolver portion of the DNS. Most Operating Systems come with their own resolver configuration. IB Contacts should configure their systems to use the DNS servers listed in local authoritative DNS Servers for PSU.EDU.
Purpose
Telecommunications and Networking Services (TNS) administers and operates the authoritative Domain Name System (DNS) server for The Pennsylvania State University Internet domain, "PSU.EDU". The following policy is primarily intended for Penn State Integrated Backbone (IB) Contacts and pertains to the administration and operation of DNS servers at Penn State. This policy also outlines the responsibilities of the IB Contacts in regards to the PSU.EDU Domain Name System. This policy does not alter the responsibilities stated in Penn State's policy, AD20 Computer and Network Security which establishes conditions for use of, and requirements for appropriate security for University Computer and Network Resources.
IB Contacts have authority over, and the responsibility for, the IP (Internet Protocol) address space assigned to them. Typically, this authority and responsibility is assigned when the IP address space is allocated for a new IB connection or when additional IP address space is allocated to an existing connection. As part of this assignment, IB Contacts also have the authority over, and responsibility for, the DNS naming associated with the IP address space assigned. The IB Contact can register and manage DNS names for IP addresses and control parameters for DNS entries. Only the IB Contacts responsible for a block of IP address space have the DNS authority for that particular block.
As noted in the previous section, IB Contacts have full responsibility for the DNS naming of the IP address space they have been assigned. Contacts must observe the following when registering DNS names:
Names in the "PSU.EDU" root space are restricted and will be limited to those representing a University-wide service. IB Contacts wishing to register in the root space must indicate that the entry is for a University-wide service.
Requests for DNS Assignments or Updates within "PSU.EDU" should be submitted by the IB Contact via the TNS web page for IB Service Requests.
IB Contacts have the authority to create subdomains within the "PSU.EDU" domain and are responsible for managing them.
IB Contacts must choose appropriate subdomain names for their assigned IP address space and must operate their subdomains properly by performing timely updates of inverse files as outlined in the next section.
DNS subdomain naming hierarchies must in part mirror Penn State administrative reporting hierarchies. DNS subdomain names, however, do not have to show full and complete organizational structure. A subdomain hierarchy may show only a part of an administrative structure and the structure shown in DNS must reflect the reporting structure. Said a bit differently, if an organization assigns a lower level entry for its assigned subdomain then the lower level subdomain must reflect administrative reporting hierarchies.
For an example of what is permitted, consider Office Z in Unit W. Then OfficeZ.PSU.EDU is permitted because it shows Z is under PSU.EDU. Remember the DNS subdomain structure does not have be full and complete, but what is shown must be accurate. OfficeZ.UnitW.PSU.EDU is also permitted because the structure the name shows is accurate and happens to be more complete.
Consider an example of what is not permitted. Suppose two departments A and B in the College of X want to identify their subdomains with the names DeptA and DeptB. Assume each department is on the same administrative level, each department reports directly to the college level. Not permitted are the fully qualified subdomain names DeptA.DeptB.ColX.PSU.EDU and DeptB.DeptA.ColX.PSU.EDU. These subdomain names do not reflect the administrative reporting structure and therefore are not permitted. And, assuming that both department A and College of Y exist but that A is not within Y, then DeptA.ColY.PSU.EDU is an example of what not permitted. The DNS name does not reflect organization reporting and would not be permitted for that reason.
Requests for new subdomains within "PSU.EDU" must be submitted by the IB Contact via the TNS web page for IB Services Requests.
IB Contacts requesting a subdomain may provide the DNS server for the subdomain or request that TNS provides the server. TNS will provide a server for subdomains below the primary "PSU.EDU". IB Contacts may also run their own DNS server for subdomains below the primary "PSU.EDU". IB Contacts may also request that a third party within Penn State run the DNS server for their subdomain. In these instances, the authority for the subdomain will only be assigned when all involved in this sort of arrangement are in agreement. The agreement should be stated, in writing, and sent to the TNS host master for filing purposes.
Subdomain names are created on a first-come-first-serve basis. TNS will not resolve disputes among IB Contacts over the ownership of subdomain names. If the parties cannot reach an agreement, the dispute will be referred to a higher authority.
If desired, IB Contacts may request and run their own DNS server for subdomains within PSU.EDU.
TNS strongly encourages all IB Contacts who decide to run their own DNS server to take an active role in the operation and responsibility of running the server.
This includes:
In some cases, partial DNS information from one IB Contact may need to be maintained on the DNS, server of another IB Contact who has chosen to run their own server. This situation may arise due to the design of the DNS and the need to completely use all allotted IP address space. IB Contacts who are running their own DNS server must provide for the timely maintenance of DNS information under the authority of their server, even in instances when that DNS information may pertain to other IB Contacts.
All DNS server operators must coordinate the operation and maintenance for the PSU.EDU domain by adhering to certain restrictions for providing DNS servers for PSU.EDU domain.
These rules are listed below.
The official basic "Requests For Comments" (RFC) pertaining to the operation of a Domain Name Server are as follows:
In addition to the official RFCs referenced above, there are unofficial guides for configuration and operation of DNS servers that have been written by experienced DNS administrators. TNS recommends the book entitled DNS and BIND(by) Paul Albitz and Cricket Liu, published by O'Reilly and Associates, Inc. ISBN 1-56592-010-4). This book is specific to the operation of the BIND name server on UNIX-type operating systems. BIND is the most commonly used DNS server environment in the Internet and is the environment used by the name servers operated by TNS.
Additional DNS configuration and operation guidelines are generally available in the system documentation for most computer operating systems which are commonly used to operate DNS servers. Beyond these general recommendations it is not the specific function of Telecommunications and Networking Services to act as a support resource for the implementation and operation of DNS servers aside from ensuring that the departmental and college servers operate in compliance with the RFC standards.
__________________________________________
What is ICANN?
The Internet Corporation for Assigned Names and Numbers (ICANN) is an internationally organized, non-profit corporation that has responsibility for Internet Protocol (IP) address space allocation, protocol identifier assignment, generic (gTLD) and country code (ccTLD) Top-Level Domain name system management, and root server system management functions. These services were originally performed under U.S. Government contract by the Internet Assigned Numbers Authority (IANA) and other entities. ICANN now performs the IANA function.
As a private-public partnership, ICANN is dedicated to preserving the operational stability of the Internet; to promoting competition; to achieving broad representation of global Internet communities; and to developing policy appropriate to its mission through bottom-up, consensus-based processes.
What is the Domain Name System?
The Domain Name System (DNS) helps users find their way around the Internet. Every computer on the Internet has a unique address called its "IP address" (Internet Protocol address). Because IP addresses (which are strings of numbers) are hard to remember, the DNS allows a familiar string of letters (the "domain name") to be used instead. So rather than typing "192.0.34.163," you can type "www.icann.org."
What is ICANN's Role?
ICANN is responsible for coordinating the management of the technical elements of the DNS to ensure universal resolvability so that all users of the Internet can find all valid addresses. It does this by overseeing the distribution of unique technical identifiers used in the Internet's operations, and delegation of Top-Level Domain names (such as .com, .info, etc.).
Other issues of concern to Internet users, such as the rules for financial transactions, Internet content control, unsolicited commercial email (spam), and data protection are outside the range of ICANN's mission of technical coordination.
Ensuring predictable results from any place on the Internet is called "universal resolvability." It is a critical design feature of the Domain Name System, 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.
How does ICANN work?
Within ICANN's structure, governments and international treaty organizations work in partnership with businesses, organizations, and skilled individuals involved in building and sustaining the global Internet. Innovation and continuing growth of the Internet bring forth new challenges for maintaining stability. Working collectively, ICANN's participants address those issues that directly concern ICANN's mission of technical coordination. Consistent with the principle of maximum self-regulation in the high-tech economy, ICANN is perhaps the foremost example of collaboration by the various constituents of the Internet community.
ICANN is governed by an internationally diverse Board of Directors overseeing the policy development process. ICANN's President directs an international staff, working from three continents, who ensure that ICANN meets its operational commitment to the Internet community.
Designed to respond to the demands of rapidly changing technologies and economies, the flexible, readily implemented policy development process originates in the three Supporting Organizations. Advisory Committees from individual user organizations, and technical communities work with the Supporting Organizations to create appropriate and effective policies. Over eighty governments closely advise the Board of Directors via the Governmental Advisory Committee.
ICANN's Board has included citizens of Australia, Brazil, Bulgaria, Canada, China, France, Germany, Ghana, Japan, Kenya, Korea, Mexico, the Netherlands, Portugal, Senegal, Spain, the United Kingdom, and the United States.
ICANN's Accomplishments
Among ICANN's recent accomplishments:
ICANN established market competition for generic domain name (gTLD) registrations resulting in a lowering of domain name costs by 80% and saving consumers and businesses over US$1 billion annually in domain registration fees.
ICANN implemented a Uniform Domain Name Dispute Resolution Policy (UDRP), which has been used to resolve more than 5000 disputes over the rights to domain names. The UDRP is designed to be efficient and cost effective.
Working in coordination with the appropriate technical communities and stakeholders, ICANN adopted guidelines for the deployment of Internationalized Domain Names (IDN), opening the way for registration of domains in hundreds of the world's languages.
ICANN's Ongoing Work
In 2000, ICANN introduced seven new gTLDs: .aero, .biz, .coop, .info, .museum, .name, and .pro. The ICANN community is currently exploring possibilities to add additional gTLDs.
In response to community concerns over privacy and accessibility, ICANN is hosting several workshops regarding Whois, the public database of domain name registrations.
With the deployment of IPv6, the new IP address numbering protocol, global network interoperability continues to be a primary mission for ICANN.
ICANN Welcomes Participation
Participation in ICANN is open to all who have an interest in global Internet policy as it relates to ICANN's mission of technical coordination. ICANN provides many online forums which are accessible through ICANN's website, and the Supporting Organizations and Advisory Committees have active mailing lists for participants. Additionally, ICANN holds public meetings throughout the year. Recent meetings have been held in Bucharest, Montreal, Shanghai, Rio de Janeiro, and Accra.
For more information on the Supporting Organizations and Advisory Committees, please refer to their websites:
Address Supporting Organization (ASO) - <www.aso.icann.org>
Country Code Domain Name Supporting Organization (CCNSO) - <www.ccnso.icann.org>
Generic Names Supporting Organization (GNSO) - <www.gnso.icann.org>
At-Large Advisory Committee - <www.alac.icann.org>
Governmental Advisory Committee - <www.gac.icann.org>
More information on ICANN can be found on ICANN's website: <http://www.icann.org>