Domain Name System (DNS) and IP Address Management


Administration & Finance


Information Technology Services

Contact Information: 

Nish Malik / Associate Vice President and Chief Information Officer, Information Technology Services / (415) 405-4105 /

Effective Date: 

Monday, December 10, 2012


CSU Information Security Policy and Standards


This Policy provides guidance to various departments within Information Technology that for responsible for allocating, registering, arbitrating, and maintaining the domain names associated with SF State.


Purpose & Scope

The Domain Name System (DNS) is a hierarchical distributed naming system for computers, services, or any resource connected to the internet. The DNS translates meaningful domain names to the numerical (binary) identifiers associated with networking equipment for the purpose of locating and addressing these devices world-wide.

SF State has implemented this Policy because:

  • Individual departments and units within SF State are experiencing a need to offer and communicate about new or different services to a wider and more diverse audience.
  • There have been an increasing number of requests for domain names that do not meet current DNS and IP Address Management practices.
  • There are domain names at SF State that are inconsistent with current practice.

The various departments within Information Technology are responsible for allocating, registering, arbitrating, and maintaining the domain names associated with the university. These services are provided under the terms and conditions specified in this Policy.  

SF State has implemented this Policy to:

  • Maintain consistency in the practice of selecting and naming the domains of services and organizations at SF State.
  • Safeguard the reputation of the university and avoid improper or illegal use by commercial entities.
  • Provide clarity for users of the system.
  • Protect the privacy and security of confidential information.
  • Define the SF State domain names conventions and standards.
  • Define the criteria for Static IP assignment.
  • Allow for tracking of IP address space and allow for efficient IP Address Management.  

Policy and Appropriate Use

All services that are provided by members of the SF State community as part of their official functions and as part of the mission of the institution will be registered within the domain name.

Since colleges, departments, and student organizations are a subset of SF State; domain and host names are expected to reflect a college, departmental and service association. Thus the following naming conventions are to be followed:

  1. The naming reflects on the university and the campus. Selected names must be specific enough to accurately characterize the entity or service being represented without confusion with other services, and must be professional and non-controversial.
  2. Host names reflect the use or purpose of a system. Departments responsible for DNS servers have the right to refuse a name request if it may cause confusion about the true nature of purpose of a system.
  3. By default, SF State network resources should utilize the domain of All IP resources normally associated with the university utilize this domain or its subdomains.
  4. Subdomains are a logical representation of a top-level domain subset, usually taking the form of a college, organizational unit and/or organization officially recognized by SF State. Information Technology Services (ITS) reserves the right to refuse a request for subdomain name based on operational needs.
  5. All DNS subdomains maintained by individual units should have DNS zone and reverse DNS zone delegation setup in the zone on the campus DNS servers.
  6. Every used or reserved static IP address in the campus range should be registered in the central/hierarchical DNS to avoid duplications.
  7. All designated DHCP ranges have to be defined in the DNS with generic names.
  8. Every DNS resource address (A) record must have a corresponding reverse (PTR) record.
  9. Existing hosts or subdomains registered under that do not conform to this Policy will be reviewed to bring them into conformity with this Policy, or be granted “grandfathered” status, if that is deemed appropriate.
  10. All campus delegated DNS servers should point to central DNS services for DNS forwarding. Direct outbound DNS resolution for non-SFSU domain names, that bypasses the central DNS servers, is restricted by the border firewall.
  11. The campus DNS servers are setup with various security protection measures including throttling of excessive concurrent DNS connections.
  12. Campus DNS servers should not allow open recursive queries from outside SF State’s network.
  13. Various departments within Information Technology must adhere to SF State Domain Names Convention and Standards.
  14. Requests for central DNS services should be e-mailed to

Domain Names System (DNS) Conventions & Standards

Naming convention for generic network devices under the top level domain domain (required for centrally maintained “”(forward) and “” (reverse) DNS zones, and recommended for delegated sub-domains)

  • The generic naming convention for the primary Domain Name System (DNS) names used for the A and PTR records (if a special campus wide name is required, will be normally aliased to the primary name) is:

    • "function"-"building"-"room"-"last_octet_of_the_IP" For example:, where "function" could be:

      • "svr" is servers including virtualized.
      • "wks" is desktops, laptops.
      • "mfc" is multifunction printers, copiers, fax, and machines.
      • "prn" is other printers, copiers, fax machines.
      • "dev" is devices such as cameras, card readers, DVRs, UPS, power meter.
      • "building" is the 3-letters building abbreviation
      • "room" is the room name/number (letters/numbers only).
      • "last_octet_of_the_IP" is used to make it unique as it is currently set for the DHCP ranges.
  • Dynamic Host Configuration Protocol (DHCP) has the following naming standard and is subject to change: dhcp-"building" "last_octet_of_the_IP"

As an exception, Departments that provide a unified DHCP service across multiple buildings will have the following naming standard: dhcp-"common administrative grouping" "last_octet_of_the_IP"

Eligibility for static IP’s (required for centrally maintained DNS/IP ranges and recommended for units with DNS delegation)

  • There is no DNS related eligibility requirements for DHCP. DHCP should be default for the client devices.            
  • Business cases for static IP eligibility:

    • Service devices (server/printer/etc.) that by purpose intended to be accessed remotely.
    • Servers.
    • Network devices such as routers, switches, firewalls, VPN and other shared network resources.
    • In some cases computer labs providing remote access (ssh/rdp) that is required for lab purposes.
    • As an exemption, client devices might need a static IP. For example, for security reasons a static IP is needed to access certain remote service/server.
  • Not eligible for static IP:
    • Any mobile client, end user workstations that do not offer any shared services and others not listed in the list of eligible equipment.
    • For Windows systems administration purposes (i.e. to connect to a system based on the NetBIOS name) to use with DHCP clients. This can be accomplished with Dynamic DNS registration of the A record in the appropriate DNS subdomain (all AD domains require and so already have dedicated subdomains). For central AD clients use a dedicated "dynamic client" subdomain which along with its own naming convention and in the future Secure Dynamic updates will scale well.

Please Note: *DNS name registrations are not the same as host or NetBIOS names.

*Centralized AD NetBIOS (Windows short hostnames) names will be under a different naming convention.          

Eligibility for the second-level domain

  • Campus/college core services.
  • Local scope systems (internal unit/department only) should be in the respective subdomains.
  • Special situations/requests to be decided on case by case scenario.

Eligibility and types of records for domain

  • High visibility systems can get dedicated A (address) and PTR (reverse) records.
  • If a descriptive name is needed this would normally be aliased (CNAME’d) to the generic DNS name or the subdomain provided registration.
  • Special situations and requests to be decided on case by case scenario.


Responsibility for implementing this Policy will rest with various departments within Information Technology that are responsible for allocating, registering, arbitrating, and maintaining the domain names associated with the university.


Noncompliance with applicable policies and/or practices may result in removal of domain. In addition, disciplinary action may be applicable under other University policies, guidelines, implementing procedures, or collective bargaining agreements.