This page contains information about implementation details related to the campus domain registration policy.

Introduction

This document describes the standard as set forth by Technology Services pertaining to the governance and rules of the Domain Name System (DNS) Service at the University of Illinois, Urbana-Champaign campus.

EDUCAUSE and the American Registry for Internet Numbers (ARIN) have delegated second level domains and IP address blocks (respectively) to Technology Services, acting on the authority of the University of Illinois at Urbana-Champaign, with the agreement that DNS service will be properly maintained and configured.

Technology Services provides DNS service to the Urbana-Champaign campus and controls allocation, management and delegation of these zones.

Terminology

American Registry for Internet Numbers (ARIN): An organization that allocates IP address space to the University of Illinois at Urbana-Champaign.
Delegation: handing over authority for a portion of the DNS namespace (thereby establishing a new zone)
Domain: a logical subtree of the hierarchical DNS namespace, headed by a domain name such as illinois.edu or example.com
Domain Name: a string of labels separated by dots which identifies an entity on the Internet. Examples: illinois.edu, example.com, www.techservices.illinois.edu.
Domain Name System (DNS): A method of translating a readable name to an Internet Protocol (IP) address.
EDUCAUSE: Grants .edu domains and offers resources for the advancement of higher education to the education community.
FQDN (Fully Qualified Domain Name): The full entry in DNS for a machine, e.g. host.unit.illinois.edu.
Hostmgr (pronounced “host manager”): role within Technology Services who handles campus DNS change requests
Hostname: A domain name given to a network-attached device.
IP Address: A number to identify a device on a network.
IP Address space/block: A group of IP Addresses.
Subdomain: a logical subset (subtree) of another domain, named by prepending one or more additional labels. Examples: unit.illinois.edu and foo.unit.illinois.edu are both subdomains of illinois.edu.  Note that a subdomain does not necessarily require a separate zone.
Subnet: A subset of an IP address space.
Time to live (TTL): The amount of time the authoritative nameserver caches a record when queried by a caching server.
Third-level name: a domain name consisting of three labels.  Example: unit.illinois.edu.
Zone: a portion of DNS namespace delegated to and configured in a particular set of authoritative name servers.  All subdomains of the apex name are part of the zone unless delegated again to form a new zone.

Roles, obligations, and resources

Units DNS requests and maintenance are processed via the unit’s IT professional for network support (aka network admin).
The IT professional for network support is designated by the unit head in agreement with Technology Services.

To identify your network admin, please contact the Technology Services Help Desk.

The primary contact for DNS for Technology Services is hostmgr at illinois.edu.

Unit costs for DNS registrations

Each campus unit is eligible for one subdomain free of charge. Additional subdomains cost $10 per year. Approved vanity domains cost $10 per year plus registration, renewal, and/or transfer fees equal to the amount that Technology Services pays the registrar.

During the illinois.edu migration, campus units will only be billed once per domain, even if the same domain exists in both illinois.edu and uiuc.edu. Each unique domain will be billed separately.

For example:

• sample1.uiuc.edu and sample1.illinois.edu are the same domain, so only one domain fee is charged.
• sample1.uiuc.edu, sample1.illinois.edu, and sample2.illinois.edu include two different domains, so two domain fees are charged.
• sample1.uiuc.edu, sample2.illinois.edu, and sample3.illinois.edu are three different domains, so three domain fees are charged.

General usage of DNS

The use of any domain name or IP address space that is managed by or associated with the University of Illinois at Urbana-Champaign must conform to the policy on Appropriate Use of Computers and Network Systems, which includes a prohibition on use of network resources for commercial or profit-making purposes or other purposes that interfere with the mission of the University.

Inter-unit DNS entries

Units wishing to create pointers from a domain they control to another unit (for example, cs.illinois.edu hostnames pointing into Beckman Institute subnets) should do so in cooperation with Technology Services. Technology Services will set up a discussion so that both groups are aware of the request and can coordinate the use of the new DNS entries.

External domain entries

Units should create and maintain their entries in cooperation with hostmanager, either via delegation or using the self-service management interface. Please see the section on non-.edu domains.

Reverse DNS (in-addr.arpa)

All hosts must have PTR records. This rule is enforced to help the campus be in compliance with industry best practice. As numerous services use PTR records, it can cause considerable problems to users if an IP does not have a matching PTR record.

Time-To-Live (TTL) recommendations

The Time-To-Live (TTL) DNS parameter is used to control how long DNS resolvers cache a DNS record. Setting a TTL value too low reduces the efficiency of caching and increases DNS server traffic/load. Setting a TTL too high means that DNS changes may not be recognized in a timely manner.

The campus standard for TTL records is 1 hour (3600 seconds). Contact hostmgr for changes to a domain’s TTL. TTL changes to individual records can be done by IT Professionals with appropriate access to the record in the IPAM appliance web interface.

Assignment of domains and subdomains

Acceptable Name Guidelines

Units requesting a new third-level name (e.g. xyz.illinois.edu) must meet the following guidelines from the Office of Public Affairs for acceptable domain names. (Pre-existing domains are ‘grandfathered’ under prior guidelines.)

• The domain name can only contain the characters (a-z), -, and (0-9), which complies with the preferred name syntax guidelines in RFC 1035 (Section 2.3.1)
• Marketability – the domain name should be succinct and descriptive of its purpose. For example, publicaffairs.illinois.edu not opa.illinois.edu
• Intuitiveness – the domain name should be easily understood and not confused with another unit. For example, studentaffairs.illinois.edu not vcsa.illinois.edu
• In general, avoid acronyms and initialisms unless they are universally recognized. For example, creativeservices.illinois.edu not cs.illinois.edu (which could be confused with Computer Science.)
• Supportive of brand – the domain name should not be contrary to the Illinois brand. The UIUC initialism should not be used in newly created domain names.
• Appropriateness – Language which could be considered derogatory, offensive, or misleading should be avoided.
• Respectful of scope and role – Third-level campus domain names (or single hostnames) should reflect high-level organizations in the university (colleges, departments, inter-departmental organizations,) or campus-wide services (www, campusrec, careercenter). Since third-level names apply at the campus level, the requesting unit must have the authority to represent the organization or service indicated or implied by the name. For example, research.illinois.edu could only be requested by a unit on campus that speaks for all research at the campus level.

Name requests which violate these guidelines must be justified and go through an approval process.

Non-.edu (vanity) domains (.org, .net)

Domains outside the .edu namespace (vanity domains) both incur cost and require the approval of Public Affairs. The following requirements apply in addition to the normal considerations for domain creations:

• Must be registered through Technology Services.
• Hostmanager works with Public Affairs to obtain approval for non .edu requests.
• Technology Services will submit requests for Vanity Domains for a department/unit.
• Requirements defined for Third Level Domains must be met.
• Department/Unit pays registration, renewal, and/or transfer fees equal to the amount that Technology Services pays the registrar, plus $10 per year to Technology Services.
• Changes to the domain must be kept to a minimum. There may be an additional fee for excessive changes to the domain. Typical traffic would be an initial set up and a few changes per year.

Approval / escalation process

The following table represents the new request approval order, and the next escalation step should a request be denied:

Step	Approval	Process
0	Unit Network Admin	for host or subdomain assignments under an assigned domain, ie: hostname.unit.illinois.edu
1	Technology Services Hostmanager	screens based on existing registrations, and acceptable use & guidelines
2	within Technology Services	technical and security concerns
3	Technology Services Executive Director, with CIO’s Office	surveys for campus conflicts
4	Office of Public Affairs	final ruling

Third-level subdomains of illinois.edu

Every third-level subdomain of illinois.edu MUST have a corresponding Domain model in Contacts Database, which must be kept up to date by the responsible department/unit.

Third-level subdomains can be implemented in one of two ways.

Separate zone

By default, each third-level subdomain will be created as a separate DNS zone, which will be made available for self-service management via the IPAM web interface.

This option has one significant drawback (resulting from an inherent technical limitation of DNS): if mysubdomain.illinois.edu is a separate DNS zone, then there cannot be a CNAME record at mysubdomain.illinois.edu.

Records in the illinois.edu zone

Alternatively, a third-level subdomain of illinois.edu may be registered as a CNAME record in the second-level illinois.edu zone, along with a small number of fourth-level subdomains (each of which may be either an additional CNAME record or a separate zone).  For example:

• mysubdomain.illinois.edu  (CNAME record in the illinois.edu zone)
• www.mysubdomain.illinois.edu  (CNAME record in the illinois.edu zone)
• etc.mysubdomain.illinois.edu  (separate zone with self-service management)
• name3.mysubdomain.illinois.edu  (either CNAME record or separate zone)
• name4.mysubdomain.illinois.edu  (either CNAME record or separate zone)

Records in the illinois.edu zone cannot be made available for self-service management via the IPAM web interface. Changes to these records must be made by request to Hostmgr.

Consider placing records that don’t have specific name requirements (including e.g. dev/test records) underneath a single fourth-level zone.

Requirements for Third Level Domain Requests

The domain name must follow the Acceptable Name Guidelines and all policies outlined in this standard. The person or group making the request must have a university affiliation (registered organization, staff, faculty, student) and the request should be routed through the unit’s Network Admin.

Requested third-level domains must not already exist and must not be reserved for future use (e.g. illinois.edu transition.) Contact Hostmanager to check domain availability.

There is no setup fee for third-level illinois.edu domains, but units will be billed according to the unit costs for DNS registrations (currently $10/year/domain)

The domain request must include:

• the desired domain name
• a description of the name and purpose
• contact information (considerations for hosted vs. delegated)
• organization codes and account numbers

See Requesting DNS Domains to start the domain registration request.

After approval, Technology Services will process the request and setup access to the domain through the IPAM web interface, or delegate it to the unit’s servers if requested (see below.) Domain requests will be acknowledged within one business day and processed within 5 business days.

Hosts and domains beyond the third level

Domain names beyond the third level are administered by the unit responsible for the third-level subdomain, subject to the following criteria:

• The names follow the acceptable name guidelines
• The length of any fully qualified domain name does not exceed 255 characters.

There is no additional cost for beyond-third-level subdomains (i.e. only the third-level domain is billed).

Note that separate DNS zones beyond the third level are usually not necessary unless the third level is registered as a CNAME or the fourth level requires delegation.  For example, you can use IPAM to create records named foo.bar.mysubdomain.illinois.edu inside a third-level zone mysubdomain.illinois.edu even though there is no fourth-level zone bar.mysubdomain.illinois.edu.  From the perspective of a DNS client, the end result is the same; the only practical difference is how things look when you log in to manage them in IPAM (i.e. whether you navigate into a separate Zone to look at all the “bar” records, or whether they are displayed in the third-level zone alongside everything else).

Implementation of changes / requests

• Changes submitted via the IPAM appliance web interface will take effect immediately. 

• Requests emailed directly to Hostmanager will be hand processed as time allows. Upon completion, Hostmanager will send a completion email to the requestor. We ask that you give your request a full 24 hours for processing and activation.

• Requests that have a sensitive time-line, either during regular business hours or outside of them, should be emailed to host manager and clearly communicated in the body of the email the desired time of activation. We ask that you coordinate all time sensitive requests a full 24 hours in advance.

• Requests to modify TTLs
  The campus standard TTL is set at the domain level and inherited by all records of that domain. The campus standard is 1 hour. This duration can be lowered to help propagate changes to high profile machines (i.e Mail servers, Web servers, etc..) to external nameservers. TTL changes to individual records can be done by IT Professionals with appropriate access to the record in the IPAM appliance web interface; if a TTL change is needed for a record you do not have access to, please contact hostmgr.

Delegation of domains to unit-managed DNS servers

Units may request Technology Services to delegate management of the domain to unit-managed DNS servers. Delegated domains must follow other standards and practices in this document, but are served from unit-managed servers.

Definition of delegation

“Administrative responsibility over any zone may be divided, thereby creating additional zones. Authority is said to be delegated for a portion of the old space, usually in form of sub-domains, to another nameserver and administrative entity.” — Wikipedia entry for DNS

Delegation is appropriate when the unit:

• wishes to use its own tools and servers for managing its DNS records,
• has business requirements that are not met by Technology Services DNS tools,
• has technical integration requirements (such as Active Directory dynamic DNS)

What can be delegated?

• unit third-level domains (e.g. unit.illinois.edu)
• non-university domains (e.g. .org domains registered to the unit)
• reverse IP lookup zones (PTR zones, e.g. 100.168.192.IN-ADDR.ARPA).
  • The DNS architecture requires having 256 address blocks for reverse lookup delegation. Units with less than a 256 address subnet cannot have reverse DNS delegated.

Delegation considerations

In a delegated DNS environment, the unit’s DNS servers are the primary responders to queries to delegated domains.

Because your DNS servers are the authoritative “holders” of your domain information, they should be well-managed and highly available.

Technology Services must have contact information on file for the DNS server administrators.

DNS outages often appear as full network outages, which harm the functionality and image of the university and your unit. The Internet takes DNS seriously and so do we.

DNS servers need to be in the Fully Open firewall group to provide DNS responses to off-campus requests.

Technology Services needs to know if you are using a Windows Active Directory domain controller as the DNS server.

Recommended values for DNS delegations

Technology Services recommends that nameservers for delegated zones be configured with the following values. Note that Technology Services does not prohibit DNS administrators from making other choices, so long as the configuration still complies with the official requirements of delegation (as set forth in the delegation agreement).

Recommended values

SOA values

• Refresh: 1 hour. Exception: If departmental name servers cannot send NOTIFYs to Technology Services name servers, please contact hostmgr to determine an appropriate value.
• Retry: 15 mins
• Expiry: 2 to 4 weeks
• Minimum: 15 mins

TIP: Don’t forget that when modifying a high-profile record (e.g. for a public-facing webserver) it is a good idea to reduce the individual record TTL in advance of making the change (e.g. to a value of 1-5 minutes), and to restore it afterward to the default setting.

Firewall groups for true Delegations

Departmental name servers for true delegations MUST be placed in the Fully Open firewall group to allow udp/53 and tcp/53 from any host (including off campus).

Firewall groups for primary/secondary pseudo-delegations

Any departmental name servers which advertise themselves in an NS RRset SHOULD allow udp/53 and tcp/53 from any host (including off campus).

“Hidden primary” departmental name servers which only participate in primary/secondary pseudo-delegations and are not listed in any NS records MAY allow udp/53 and tcp/53 traffic from off campus but are not required to do so.

Recursion

All departmental name servers must either disable recursion and use the campus resolver (IPv4:130.126.2.131) or restrict recursion to only known hosts.

Delegation request process

Send an email to hostmgr with the required information.

• domains and zones to be delegated
• DNS server names and IP addresses
• Contact information for the zones
• Reason for delegation

Delegation lifecycle

Technology Services will conduct a yearly audit of delegations, which will include an interview and a verification letter. The purpose of the interview is to define what needs and requirements are not being met with the Technology Services DNS service offering. Regular feedback equips Technology Services with the necessary information to keep services relevant to campus.

Domain lifecycle

Changes to domains

• Domain removal
  If you no longer are in need of a domain associated to you, email Hostmanager. Once the requested date of removal is met, the domain will no longer resolve and billing will cease at that point.

• Transfers within the University
  If you no longer are in need of a domain and another department or unit would like to be associated with that domain, please contact Hostmanager. Hostmanager will coordinate between both departments to reach an agreement.

DNS technical considerations

Campus resolver IP address

The DNS resolver address for campus is 130.126.2.131.