|
UCB DNS Policy
IST Communication and Network Services
DOMAIN NAME SYSTEM (DNS) SERVICE POLICY
I. Introduction
The Informaton 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:
CNS will strive to provide a level of service that will
encourage departments to rely on CNS for this critical service. (See
Appendix B.)
For those domains which are not already delegated, CNS will
not delegate subdomains.
CNS intends to retrieve existing delegations wherever
possible.
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.
Rescinding delegations:
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.
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 IST-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 E-Berkeley Policy section on the
e-Berkeley Community and Registration in Berkeley.EDU.
3. Requirements
Eligible entities may request registration of hostnames of
their choice, providing that the names:
comply with all University and
Campus regulations such as, for example, the "Policy on the
Use of the University's Name, Seals, and Trademarks";
refer to their own department or
organization or to a project managed by the department or
organization;
do not imply affiliation with a
campus unit or department with which the site is not affiliated;
and
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.
Except for aliases and other non-address records, each
hostname must point to a valid Berkeley IP address.
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:
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).
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
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).
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.
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 IST Policy Office,
policy@uclink.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:
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.
CNS will provide name service on
its existing DNS servers.
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.
Return to top.
APPENDIX B - CNS SERVICE PROFILE FOR DNS MANAGEMENT
Level of service provided:
a. Hostmaster services:
The hostmaster@nic.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 hostmaster 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, hostmaster
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 hostmasters 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 hostmaster 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 hostmasters 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.
Return to
top.
APPENDIX C - DELEGATED SUBDOMAIN REQUIREMENTS
For those zones that are already delegated, the designated
nameservers must be run in compliance with the following principles:
No Illegal records: e.g., NS
records pointing to CNAMEs.
Email to contact listed in SOA
record is monitored at least once per day.
Requests for record
add/change/deletes from hostmaster@nic.berkeley.edu, are responded
to within 2-3 days.
Format errors or other operational
problems in the nameserver are corrected quickly.
Hostmaster is versed in DNS record
formats, BIND syntax, recommended operational standards for
nameservers.
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.)
Return to
top.
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".)
|
Return to
top.
Rev: July 20, 2004
Data Services Internal |
CNS Internal
Last revised:
March 31, 2006
Technical inquiries:
nsweb@berkeley.edu
|