Domain Name System (DNS) Service Policy

PLEASE NOTE:
This is an archived version of the DNS Policy. An updated version was issued on 2/1/2024.

New Link: Domain Name System (DNS) Service Policy and Resources


I. Introduction

The Information Systems and Technology - Communication and Network Services (CNS) department is the steward of the Berkeley Campus network. In fulfilling that role, CNS serves as the central point of contact for the outside world and has responsibility to ensure that management of this University resource complies with applicable laws and regulations.

CNS provides Domain Name System (DNS) Information Management and Host Name or Domain Name Registration Service for selected organizations affiliated with the University of California, Berkeley. These services are provided under the terms and conditions specified in this Policy.

Selected terms in this Policy are defined in Appendix A - Definitions.

II. Purpose

This Policy is promulgated to conserve limited campus resources (such as IP address space, staff time, and computer processing and memory resources) and to ensure compliance with applicable laws and University and Campus regulations.

III. Policy

A. Use of Berkeley Campus IP addresses

Those who operate sites located at Berkeley Campus IP addresses may use only IP addresses that have been registered and specifically assigned to them, either by CNS or, for those departments who have delegated DNS, by their departmental DNS administrator (see section B.2, below.)

Users whose unauthorized use of a campus IP address leads to an IP address conflict that must be investigated by CNS may be responsible for the time and material costs incurred by CNS staff.

B. DNS Information Management

1. General

CNS maintains DNS information for all connections within the berkeley.edu domain, with certain exceptions. For specific information regarding the level of service provided see Appendix B - CNS Service Profile for DNS Management.

2. Delegations to other departments on campus

It is the intent of CNS to reduce or abolish existing subdomain name service delegations. Due to former administrative practices, some campus departments operate a "delegated" subdomain in which the management of the name service is provided by a departmental administrator, rather than by CNS. This requires that both sets of servers agree on who is responsible for which subdomains, and requires extremely careful coordination between campus and departmental system administrators. To date, subdomain name service delegations have resulted in an unacceptable level of problems.(1) Therefore:

  1. CNS will strive to provide a level of service that will encourage departments to rely on CNS for this critical service. (See Appendix B.)

  2. For those domains which are not already delegated, CNS will not delegate subdomains.

  3. CNS intends to retrieve existing delegations wherever possible.

  4. For those zones that are currently delegated, the designated nameservers must be run in compliance with the principles specified in Appendix C - Delegated Subdomain Requirements.

  5. Rescinding delegations:

    1. CNS may temporarily rescind a DNS delegation if the malfunction of a delegated nameserver is causing operational problems for all or part of the campus network and the responsible administrators cannot be immediately notified. In this event, CNS will make every effort to notify the departmental administrators, using available contact information, of the change in delegation.

    2. CNS may permanently rescind a delegation if there are repeated or consistent operational problems with delegated nameservers, or if the requirements in Appendix C are repeatedly not met by a department operating a delegated nameserver. In this case, departmental administrators will be given notice by the Director of CNS, providing the reason(s) for the revocation.

C. Hostname or Domainname Registration Service

1. General

The term "domainname" may be substituted for "hostname" within this section (C).

Hostnames are assigned by Berkeley IT-CNS only for "berkeley.edu" domain locations. Hostnames are generally registered on a first-come, first-served, basis. Requests will be granted within two (2) business days.

2. Eligibility

See the Campus Online Activities Policy section on The Berkeley Community: CalNet ID and name registration in Berkeley.EDU domain.

3. Requirements

  1. Eligible entities may request registration of hostnames of their choice, providing that the names:

    1. comply with all University and Campus regulations such as, for example, the "Policy on the Use of the University's Name, Seals, and Trademarks";

    2. refer to their own department or organization or to a project managed by the department or organization;

    3. do not imply affiliation with a campus unit or department with which the site is not affiliated; and

    4. are not currently in use.

    Hostnames are normally registered for immediate use. However, hostnames that meet the requirements of this section (C.3) may also be registered in order to "reserve" them, either for future use or to prevent their use by others.

  2. Except for aliases and other non-address records, each hostname must point to a valid Berkeley IP address.

  3. Each IP address referenced by a DNS address record must be uniquely associated with a connection cable ID, located on the wall jack or cable itself.

    Exceptions to this requirement are the following:

    1. The IP address is used for a PPP or dial-up server. In this case the number of IP addresses assigned for this purpose will be no greater than the number of actual dial-in connections (i.e. phone lines).

    2. The IP address is used for connections to an external hub or switch only when approved by CNS for use on an all-switched network. See CNS User-installed Network Equipment Policy. As with dial-up lines, the number of IP addresses will not exceed the number of ports on the user-installed device. CNS may be unable to make IP address assignments if the subnet on which the device is attached is at or nearing capacity with respect to address space.

4. Subdomain Name Registration

  1. Standard subdomain name registration: Procedures for requesting that a subdomain name be registered under the domain ".berkeley.edu" are specified in Subdomain and Web Server Names (http://www.net.berkeley.edu/DNS/subd-www.shtml).

  2. Web server subdomain name registration:

    The hostname "www." may only be used within a registered subdomain. See the Subdomain and Web Server Names policy, (http://www.net.berkeley.edu/DNS/subd-www.shtml), for details.

  3. Official subdomain names: An official subdomain implies an organizational level within the campus. Therefore, unofficial subdomains such as michael.berkeley.edu will not normally be registered as subdomains, although they may be registered as hosts.(2)

5. Hostname alias registration for web servers

Entities wishing to acquire a hostname alias must contact the administrator for their web server. Hostname aliases for web servers will be assigned by CNS only upon CNS' approval of a request from the web server administrator.

Web server naming policies are described in Subdomain and Web Server Names. In addition to the guidelines outlined there, web server administrators are strongly encouraged to follow the trend away from the unnecessary prefixing of "www" on every host that operates as a web server.

D. Other DNS services and policies

CNS will not register a name "defensively" outside of berkeley.edu;, e.g., to reserve a name in the .com domain solely for the purpose of preventing someone else from registering it. Inside berkeley.edu, CNS may make defensive registrations for departments under the conditions listed in Section III.C.(3)

1. Non-berkeley.edu hostnames for campus sites

Some sites that are physically part of the berkeley.edu network (see Appendix D) may wish to register non-berkeley.edu host name addresses. Departments may conduct such reservations without CNS intervention, as long as:

  • the registration is performed by a campus-affiliated entity;

  • the site complies with University and Campus regulations;

  • UC Berkeley is not listed in Internet registration information; and

  • a UC Berkeley email address is not given in Internet registration information.

2. Registration address for non-berkeley.edu sites

Hostnames in berkeley.edu may resolve to IP addresses not listed in Appendix D only under exceptional circumstances. To request an exception, contact the Berkeley IT Policy Office via email at: itpolicy@berkeley.edu

3. DNS service for non-berkeley.edu names

CNS may provide name service for campus-affiliated entities who wish to register non-berkeley addresses. The following provisions apply:

  1. CNS will not allow or approve the use of any campus hosts, including the CNS department's DNS servers, to provide authoritative domain name service for commercial (.com) entities.

  2. CNS will provide name service on its existing DNS servers.

  3. CNS and the requesting entity will discuss and review how the domain will be managed and what resources will be necessary. If management of the domain requires a significant amount of ongoing maintenance or imposes a significant resource burden on CNS staff or equipment, a cost-recovery mechanism or alternate arrangement may be necessary. Such arrangements will be made on a case-by-case basis.

Exceptions to these provisions may be made where historical or resource-sharing agreements have been made with other organizations to "trade" name services, especially where such trades provide increased redundancy for the campus network. (An example is CNS providing remote backup DNS services for other campuses in exchange for the reciprocal provision of remote berkeley.edu DNS service.)Footnotes:

(1) In situations where DNS management has been delegated, adequate coordination between CNS and the departments has not been possible, despite the good-faith efforts of both parties. Subdomain delegation has led to unacceptable incidents, including interference with CNS management of the connection information database and even, occasionally, interference with general operation of the campus network itself.

(2) For example, in the case of the host michael.berkeley.edu, where michael.berkeley.edu is not a registered subdomain, CNS would permit an alias of mail-michael.berkeley.edu. However, mail.michael.berkeley.edu would not be permitted, since the dot between "mail" and "michael" requires that michael.berkeley.edu be a registered subdomain, which it is not. Of course, the preferred option would be to simply use the hostname michael.berkeley.edu.

(3) A number of domain registration services allow an entity to reserve a domain name without specifying name servers. The only requirement is that the proper fee be paid. Because such reservation is available through those entities, CNS will not support or provide registration service for units wishing to reserve .com addresses.



APPENDIX A - DEFINITIONS

delegated subdomain
- a domain name which belongs under the authority of one set of name servers, which is actually served by another set of servers.
domain name
- a way to identify and locate computers connected to the Internet. No two organizations can have the same domain name. A domain name always contains two or more components separated by periods, called "dots"". For example, the Berkeley Campus domain name is "berkeley.edu".
Domain Name System (DNS)
- the way that Internet domain names are located and translated into IP addresses.
DNS server, nameserver
- a server which provides IP address/hostname mapping for computers on a network.
Internet Protocol (IP) address
- the location of a particular connection to the Internet, expressed as four series of digits separated by dots. A computer connection registered with the DNS has a domain name associated with its IP address.
primary nameserver
- a nameserver which is authoritative for a domain and contains host information for that domain locally. Changes to the domain are made manually, or through dynamic updating, first to the primary nameserver.
hostname
- a name registered to a particular host. For example: uclink.berkeley.edu or cory.eecs.berkeley.edu. The hostname is mapped to a unique IP address in the DNS.
secondary nameserver
- a nameserver which is authoritative for a domain and transfers all of the host information from the primary nameserver.
subdomain
- once a domain name has been established, subdomains can be created within it.


APPENDIX B - CNS SERVICE PROFILE FOR DNS MANAGEMENT

Level of service provided:

a. DNS Administrator services:

  • The dns@berkeley.edu mailbox is read by a team composed of CNS staff. It will be continually monitored throughout the weekday hours of 8am to 5pm, and occasionally outside of those hours.

  • CNS will make every attempt to respond to DNS Administrator requests on the same day that they are received. All requests will receive a response within two (2) business days. Responses may confirm that the requested changes have been made to the DNS database, or they may indicate that the request cannot be accommodated (providing a reason). The response may also indicate that the request will take longer than two business days to complete; in such a case the reason for the delay will be included, as well as an estimate as to when the request will be completed.

  • As part of the network connection request process, the DNS Administrator will make every attempt to complete IP address assignments by the due date, or within three business days of receiving the service point information from the Operations, Installation and Repair (OIR) engineer, whichever is later. Note that the DNS Administrator cannot be held responsible for connection installation delays that occur during other phases of the network process; nevertheless, they will make a good-faith effort to speed up the IP assignment process when the overall installation process has been delayed during other phases.

  • Once a DNS Administrator request is completed and added to the DNS database, changes will take place during the regular reload time of 3:00 AM every morning. In cases where a department or user needs changes to take effect earlier, the changes can be put into effect at 5:30 PM. In cases where there are DNS problems that are causing operational issues in the campus network (see also section B., Operational Issues), the nameservers can be reloaded immediately. This is not provided as a normal practice due to the volume of changes that the DNS Administrator's make each day, and to the potential disruption that repeated reloads of the nameservers might cause during the course of the business day.

b. Nameserver operations:

  • The campus nameservers (ns1.berkeley.edu and ns2.berkeley.edu) consist of a virtual cluster of hosts that are deployed throughout campus. Each request is routed to the server that is nearest to the given host and, if a server goes down, requests will automatically be re-routed to another server. This helps to provide redundancy against server failures and mechanical failures (such as power outages) that affect only limited areas of campus.

  • The nameservers are maintained on a 24x7 basis. Members of the Network Services group are always on call in case a problem occurs.


APPENDIX C - DELEGATED SUBDOMAIN REQUIREMENTS

For those zones that are already delegated, the designated nameservers must be run in compliance with the following principles:

  1. No Illegal records: e.g., NS records pointing to CNAMEs.

  2. Email to contact listed in SOA record is monitored at least once per day.

  3. Requests for record add/change/deletes from dns@berkeley.edu, are responded to within 2-3 days.

  4. Format errors or other operational problems in the nameserver are corrected quickly.

  5. The DNS Administrator is versed in DNS record formats, BIND syntax, recommended operational standards for nameservers.

  6. Nameservers a running current, patched version of BIND, and on hosts that are a running current, patched OS and are secure.

See the DNS Resources Directory (http://www.dns.net/dnsrd/) and the Internet Software Consortium (http://www.isc.org/) for more information on DNS and BIND.

CNS encourages administrators of currently-delegated DNS servers to develop procedures for maintaining reliable operation of their name services similar to those in Appendix B - CNS Service Profile for DNS Management. (See above.)


APPENDIX D - CAMPUS RESOURCES

This Policy considers the following to constitute campus resources and subject to University and Campus regulations pertaining to resources and facilities:

a.

Physical network connections: includes any of the following - physical wiring in campus buildings and hubs, switches, and/or routers that serve campus buildings or spaces leased by campus for departmental use.

b.

IP address space: The following address blocks have been assigned to the University and are maintained by the American Registry of Internet Numbers (ARIN):

128.32.0.0 - 128.32.255.255
136.152.0.0 - 136.152.255.255
169.229.0.0 - 169.229.255.255
192.12.234.0 - 192.12.234.255
192.31.95.0 - 192.31.95.255
192.31.105.0 - 192.31.105.255
192.31.161.0 - 192.31.161.255
192.35.209.0 - 192.35.209.255
192.58.221.0 - 192.58.221.255
192.101.42.0 - 192.101.42.255
192.107.102.0 - 192.107.102.255
192.154.4.0 - 192.154.6.255
192.195.74.0 - 192.195.74.255
198.49.166.0 - 198.49.166.255

These address blocks constitute a University resource. NOTE: Reverse DNS for any IP address in the above blocks, if it exists, MUST resolve to a berkeley.edu hostname.

c.

Network servers, including the Domain Name System (DNS) servers (also referred to as "nameservers".)