Search ITS   | User Guides |   | Services |   | Policies |   | Forms |   | Help |   | Home |  

TNS Policies

The Domain Name System

DNS Organization

How DNS Works

DNS Policy for PSU.EDU

Policy for the Administration and Operation of the Domain Name System Servers for the PSU.EDU Domain

DNS:The Domain Name System (Overview)

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.

DNS Organization:

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.

How DNS Works:

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.

DNS Policy for PSU.EDU Domain:

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.

DNS Authority For Assigned IP Space

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.

DNS Names

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:

• A Penn State IP address cannot have a non-Penn State DNS name. A Penn State address must be named within a subdomain of "PSU.EDU" or within the "root" domain, "PSU.EDU".
• A Penn State DNS name cannot identify a non-Penn State IP address. A Penn State DNS name must resolve to an address assigned to Penn State.

Individual DNS Entries in the PSU.EDU Root

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 Domain Name System (DNS) Service.

DNS Subdomains within PSU.EDU

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 Subdomain Management Request Form . Sudomains may be updated and deleted from this web page as well. Searches of the existing subdomains may be done using the TNS Subdomain Search Form.

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.

Running DNS Servers for Subdomains within PSU.EDU

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:

• Keeping abreast of DNS security issues and applying security updates as necessary.
• Becoming familiar with DNS structure and operation by referencing the official Internet Standards documents on DNS. Internet Standards are defined within documents entitled "Request for Comments" (RFC). Refer to the list of RFC references pertaining to the operation of DNS.
• Following requirements for PSU.EDU root domain name server. (these requirements are listed in the next section).
• Running an authoritative secondary server.
  In order to provide for adequate DNS service for Penn State, those IB Contacts who want to run their own DNS servers are required to have one backup server.
  TNS will provide this service if other arrangements for a backup server cannot be made.
• Performing timely maintenance of DNS information (Inverse File Updates).

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.

Requirements for DNS Servers for PSU.EDU

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.

TNS will:

• Maintain and distribute the root PSU.EDU data.
• Specify and use a reliable and cryptographically secure method for distributing the root data.
• Coordinate a minimum of 2, and a maximum of 5, servers authoritative for "PSU.EDU" root and for "ADDR.ARPA" domain with the goal of having all servers being generally operational at all times.
  At least 2 of the University Park on-campus servers are to be delegated to other PSU organizations.
  To encourage redundancy and fault tolerance, the University Park on-campus root servers are to be distributed as much as possible to networks in different buildings with different IB connections.
  To provide optimum redundancy in the event the campus network is isolated from the Internet, TNS will coordinate the operation of at least 1 off-site server authoritative for "PSU.EDU" root and its "ADDR.ARPA" domain at a location not owned by the University. These locations should be well connected but distant from the University's network.
• Monitor all "PSU.EDU" domain servers for adherence to the operational guidelines specified. Take corrective measures, including the reassignment of the zone server to another operator, if DNS servers fail to meet these guidelines.
• Perform routine audits to the "PSU.EDU" domain data to remove format errors and other inaccuracies in the DNS information to ensure a clean and understandable namespace.

All PSU.EDU Root Domain Name Server Operators will:

• Provide and maintain adequate hardware in order to support the DNS server
• Maintain physical security of the network and DNS server hardware.
• Maintain the highest level of security on the DNS server, including monitoring the system and applying security patches to the Operating System and server software on a timely basis as needed, unless directed otherwise by TNS.
• Maintain the DNS server in a physical space that is appropriate for computer server operations, including proper heat, ventilation and air conditioning (HVAC), backup power, and other applicable services.
• Write and maintain a disaster recovery plan covering, at least, the following items:
  Availability of replacement hardware within 24 hours.
  Maintenance of a data backup schedule.
  Procedures to ensure reliability of the network infrastructure between the name server platform and the IB.
  Procedures for monitoring the functionality of the server and methods to alert appropriate personnel if the server should become unavailable.
• Monitor the security of the server, checking logs, running appropriate security tools, etc. (reference University Computer and Security Policy AD20 and University Policy AD23 on the Use of Institutional Data).
• Limit non-emergency outages to the TNS "maintenance window".
• Provide, at least 1 business day advance warning to other operations personnel when conducting routine maintenance that may impact the operation of the server by posting notice of such to the email distribution list, l-psudb@lists.psu.edu. In addition, all scheduled maintenance outages of the DNS should be coordinated to minimize the effects of those outages on regular Penn State DNS operations.

References

The official basic "Requests For Comments" (RFC) pertaining to the operation of a Domain Name Server are as follows:

• RFC 974, "Mail routing and the domain system"
• RFC 1034, "Domain names - concepts and facilities"
• RFC 1035, "Domain names - implementation and specification"
• RFC 1101, "DNS encoding of network names and other types"
• RFC 1183, "New DNS RR Definitions"
  Some additional RFCs which may be helpful are:
  
• RFC 1713, "Tools for DNS debugging"
• RFC 1912, "Common DNS Operational and Configuration Errors"

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.

The Pennsylvania State University © 2004. All rights reserved. Alternative Media Statement and Nondiscrimination Policy
This site maintained by Telecommunications and Network Services, a unit of Information Technology Services.
Provide site feedback to TNSWebmaster@mail.tns.its.psu.edu. 07/27/07