Critical (“top level”) zones and restrictions
The second-level domains uw.edu and washington.edu are controlled by UW-IT on behalf of the University of Washington, and all resource records at this level must be carefully governed. Resource records at this level are reserved for purposes that serve the entire UW enterprise. Requests by individual departments to add records at the uw.edu or washington.edu level for department-specific purposes will be denied, with a specific limited scope for exceptions described below.
Examples
The use of DNS TXT or CNAME records to verify control of a name is common among software as a service vendors. The intent is to prove that a customer controls a domain before the vendor allows the customer to use the domain in some way within the vendor’s software. This claim often becomes an exclusive claim: so long as one customer has claimed and verified the domain, other customers may not do so. Configuring a domain control TXT record at this level on behalf of one department could thus cause problems for other UW customers of the same vendor. Domain claims are not standardized, and will have different implications in different vendor systems. Investigating and understanding the impacts of creating a domain claim record takes time, and the network, software, and system engineers supporting UW DNS cannot investigate these implications for each request.
A CAA record instructs TLS clients to only trust security certificates signed by a particular Certificate Authority (CA) for a given domain. Unless overridden, a CAA record at the uw.edu level would be implicitly inherited by all subdomains of uw.edu, and many clients would only trust the CA listed in that record for any UW subdomain. Configuring a CAA record at this level could cause a large number of UW services and web sites to become inaccessible.
A SRV record is used by some Internet services to automatically discover a service provider for that service at a given domain. For example, a record named _autodiscover._tcp.uw.edu would be used by some email programs to automatically configure account information when a user tried to use their uw.edu email address. While SRV records look like subdomains, the first two parts of the name, with underscores, identify the service being described, and the uw.edu part means that the service is being defined at the top level. SRV records are not heavily used, but a misconfiguration at the top level could still cause protocols like Kerberos to contact a departmental service instead of a UW enterprise service.
Workarounds and exceptions
Requests for third level domains under washington.edu and uw.edu are usually approved and configuration of domain names is delegated to customers. Departments should always be able to use a lower-level domain delegated to them for domain validation. When customers must prove control of email addresses specifically, the Virtual Email Domain service, or a third party email forwarding service, can be used to provide department-specific email addresses without running an entire separate email system. This is the best and best-supported workaround for vendors which tie activation of single sign on flows to particular email domains; the user experience cost is that end users will have to use a departmental email as their account name on the vendor product. Units are encouraged to request more flexible options from their vendor. Tying SSO to an email domain is a poor choice in UW’s federated enterprise with dozens of independent IT groups, but a single primary email service.
Occasionally, using a TXT record for domain control verification in a vendor system is non-exclusive and temporary. To count as non-exclusive, claiming the domain in the vendor system for a given account must not prevent other accounts from claiming the same domain. To count as temporary, it must be possible to remove the TXT record from DNS after the vendor’s verification step is complete. UW-IT will create TXT records for domain verification purposes on behalf of specific departments when both of these criteria are met, given clear vendor documentation and a technical justification for the verification, subject to approval of the Service Owner.
UW-IT will work with outside departments procuring a vendor service for the entire UW enterprise to create domain control records as necessary.
UW Subdomains and non UW domains
Historically, campus subdomains were created primarily by department groups for departmental email, creation of a specific windows domain, and departmental host organization. Recently, subdomains have shifted to be created primarily for use as websites, and are often grant, project or event based.
UW-IT initially allowed a large number of two and three letter department names. For example, ‘ee’ for electrical engineering, ‘cs’ for computer science and ‘ess’ for earth & space sciences. There are two problems with this practice: acronyms used as subdomains are not descriptive and do not give users any indication what the domain is used for, and domain names that are not fully qualified can conflict with country codes and three letter domain extensions With the growing number of websites, we have adopted a best practice of using descriptive subdomain names, even if they require more typing. Abbreviations that make sense (e.g. phys for physics) are still allowed.
The UW Groups service enables departments to create self-service Organizational Home Groups subdomains under the “uw_” stem, since these are required in the washington.edu or uw.edu namespace.
Current process:
UW-IT tries very hard to not allow offensive or controversial names. At times, we are unaware or do not catch these (e.g. bad names translated from other languages). UW-IT retains the right to remove or change subdomain names when necessary.
Certain words and wordmarks will require additional approval from University Marketing and Communications. These words include specific branding messages similar to the following examples and others from existing UW advertisements and promotional materials:
- boundless, together, w day, for washington, undaunted, campaign, brand, gala, advancement, marketing, possible, foundation, population health
Campus subdomains require an accompanying Contact Group, whether existing or new. Subdomains and some functions involving them can be accessed from the Networks Portal by Administrator level contacts.
Unlike top level or critical zones which can impact all of the University, authorized contacts may create whatever records within their individual subdomains.
In all cases, UW-IT reserves the right to make changes to or remove any DNS records to protect the DNS system and the University.