Domain Name System (DNS) Terminology
Domain Name System (DNS) is an Internet service that translates domain names into Internet Protocol (IP) addresses.
- Domain Name
It is the address where Internet users can access a website. A domain name points to an IP address, the address where Internet users can access a website
A hostname can be an “A record” or a “CNAME.”
- Top-level domain
The top-level domain is the right-most label of a domain name.
Examples of top level domains are .edu, .com, .org, .net, and .gov. There are many more, e.g. .info, .club, etc. Each country has a two letter domain e.g. .us, .uk, .ca, etc.
- Second-level domain
A second-level domain label is located to the left of the top-level domain and generally indicates the organization that registered the DNS.
- Third-level subdomain
A third-level subdomain is an extension of a domain.
These must be the names of schools, colleges, institutes, or units that are officially recognized by the U-M Regents as detailed in U-M’s SPG.
- A Record
An “A” record links/maps domains directly to their corresponding IP addresses. It can be thought of as an official, legal name; when it’s used, it directly addresses the IP address.
- Canonical Name (CNAME) record
A CNAME record points one domain name (the Alias) to the official or canonical domain name (the CNAME).
A subzone is very similar to a subdomain. The difference is that whereas subdomains provide a logical structure to the DNS, zones provide an administrative structure. For example, "athletics.umich.edu" is a subdomain or hostname in the "umich.edu" zone, managed by ITS and used by Athletics, but "ath.umich.edu" is a subzone, managed by the Athletics dept
- SPG 601.15-1
U-M’s Standard Practice Guide (SPG) that details standards for creating domain names.
- U-M Hostmaster
The U-M Hostmaster refers to the ITS Networking team members who process DNS requests.
- U-M Hostmaster DNS Review Team
The U-M Hostmaster DNS Review Team is a group—consisting of representatives from the Office of the VP for IT and CIO, Office of the VP for Communications, ITS Networking team, ITS Communications team, and Michigan Creative—that collaborates to make decisions about domain name proposals that have technical, institutional, branding and/or other conflicts or concerns.
Parts of a URL
This is the protocol, which is often assumed and not shown.
Domain name of the web server. This is the only required part of the URL, all others are optional. This part is sent to DNS to be translated into an IP address, so the URL can be sent to the server.
The port on the server where the URL request will be sent.
The web server uses this to decide which process to run or which page to display.
These are variables (like username or user ID) to send to the process on the web server.
How DNS Affects a Web URL
When a user clicks on a URL or types it in, several things happen:
- The "Domain name" portion of the URL is sent to DNS to look up the IP address for that Domain name.
- The URL is sent to that IP address and port number.
- The web server listening on the port decides what to do with the URL. Typically the domain name is mapped to a base path, and then the "path" in the URL is appended to that.
- The page at that path is returned, or the program at that path is run, with the variables being passed to that program.
DNS can decide that the URL "example.com" is sent to the server at 10.1.2.3. However, DNS cannot send the URL "chem.example.com" to "example.com/chem". The reason is that DNS has no control over the URL, it only controls what IP address the domain name part of the URL maps to.
Changing a URL can only be done by a web server, using a "web redirect." This can be done by the same server as the final website, or a separate server. ITS runs a web redirect service that can be used.