Understanding the Internet, Part 2: Domain names

[Understanding the Internet, Part 1: IP addressing and ports.]

I may have remarked before that IP addresses are not particularly intuitive or easy to remember. Fortunately, to remedy this problem, we have the Domain Name System (DNS). DNS, one of the cornerstones of the Internet, is what makes it possible to reach the millions of sites in existence without knowing their IP addresses. If we continue with the analogy of the postal service, DNS is like the Yellow Pages of the Internet, allowing you to find a company address by name. If you do a search using google.ca, DNS is what is actually searching the IP address for you. In most cases, web browsers do this transparently so that you never have to do it yourself.

To obtain a domain name on the Internet, you must go through a registrar. A registrar is like a notary or a solicitor, legalizing your possession of a desired domain name and, generally speaking, allowing you to record the IP addresses linked to your domain name. A domain name can be anything you want it to be, as long as it is appended by a recognized Top Level Domain (TLD). Among the most well-known TLDs are:

• com
• gov
• biz
• net
• …

Not to mention the country-specific TLDs, which are managed by government agencies (ca, fr, us, etc.), and new TLDs that have just recently been coined, such as:

• ninja
• museum
• food
• …

To know more about existing TLDs, check out this exhaustive list on Wikipedia, at this address.

If your preferred domain name is valid and available at the registrar of your choice, simply purchase it and start using it. For websites, once you have programmed the static IP address of a hosting service into your DNS service, within a few minutes, you can visit your website from anywhere on the planet simply by typing your domain name into a web browser.

Suppose you need to host several pages, or separate documents, within your domain name. You can do this by using Fully Qualified Domain Names (FQDN) or by placing them under one or more separate Uniform Resource Locators (URLs).

When you request a page on a web browser, the DNS service used by your browser will search for the IP address to go to. When the DNS service finds the IP address for the domain name you have entered, your browser sends an information request (HTTP protocol) to this address via a specific entry point (the port). Your browser will then request the first document available for this domain name, or a document specified in the URL. For the average user, the HTTP protocol basically seeks to retrieve specific files via a URL so that they can be interpreted by a web browser and displayed in a readable format.

For the Love of Potatoes

Here is a concrete example to illustrate this. You like potatoes so much that you decide to buy the domain name potatoes.com. Once your domain name is purchased, you configure it with a web host and you record DNS information that points potatoes.com to the IP address 1.2.3.4 (hypothetical). You then decide to code your first page. You call it fries.html and drop it at the root of your web server.

Note: names such as potatoes.com may or may not be available for purchase. Most of the time, general terms such as potato, pizza, steak, car, etc. are very desirable and have already been bought by someone else. Either they are actually used for a website, or they are put up for sale for a huge amount of money. Sometimes, a subtle variation in the spelling of the name will be used for piracy purposes (we will come back to this later). The names used in the following examples do not necessarily point to real sites; if they do, it is just a coincidence.

In general, an FQDN refers to a domain name with a prefix, often indicating what type of resources are available at that address. It can be anything, but the best known prefix is “www”, which, by convention, has long been used for websites. Transposed into the bricks-and-mortar world, this is what it would look like:

• The domain name would be a company name.
  • potatoes.com
• The FQDN would be the name of a department within said company.
  • www.potatoes.com
• And the URL would refer to a specific resource that you want to reach within the company.
  • www.potatoes.com/fries.html

Let’s see an example of a URL to a specific resource:

http://www.potatoes.com:80/fries.html

• http is the protocol.
• www.potatoes.com is the FQDN and potatoes.com is the domain name.
• 80 is the port to use on this server.
  • Important note:
    • Port 80 is the port conventionally used for the HTTP protocol. ;
    • If no port is specified, port 80 is assumed by default, so there is no need to enter it in most cases. Its inclusion in the example is simply for educational purposes.
• fries.html is the name of the file to be retrieved from the server.

If this example were actually configured, here is the general sequence of events that would occur after entering the URL in a browser:

1. Searching the IP address of potatoes.com on the DNS.
   • Address 1.2.3.4 is returned to the browser.
2. The browser then sends a request to address 1.2.3.4 on port 80 specifying the following:
   • 1. Declaration of use of the HTTP protocol;
   • 2. Request the file fries.html. If no file name is specified, what the server returns depends on its configuration:
     • A list of documents for the domain potatoes.com;
     • The first document available;
     • A document specified by the web server administrator.
3. The server sends the file fries.html to the browser.
4. Finally, the browser displays the contents of the file fries.html for the user.
   • a. An HTML file usually contains text as well as codes that define the formatting of the text and that call external resources such as images.
   • b. HTML standards are well defined and generally uniform so most browsers interpret these codes in the same way, although there may be some variances between browsers (but this warrants a whole other article).
   • c. Display problems caused by these exceptional variances are generally identified by quality assurance teams before production goes live, but software updates and changes in standards can wreck certain features or formatting overnight.

In such a case, you may decide to create a secondary site dedicated to french fries, with a modified FQDN. For example:

http://frites.potatoes.com/index.html

As long as the address 1.2.3.4 is entered at the DNS level, the FQDN will know to point the information for fries.potatoes.com to this “new” site. This site can contain information related specifically to french fries, while the site potatoes.com can contain all other information about potatoes in general.

If you had control of the fictitious address 1.2.3.4, you could point as many FQDNs and domain names to it as the server capacity allowed.

Now, let’s say that your growing love of french fries leads you to buy the domain name french-fries.com. Again, as long as the web server is configured correctly, IP address 1.2.3.4 can be used for both the french-fries.com and potatoes.com web pages. In the physical world, it would be like having two companies co-located in the same physical office.

If you subsequently won fans with whom you wanted to correspond, you would have to set up a mail server. To do this, you must configure 3 other DNS records:

• A DNS record type A for the FQDN mail.potatoes.com.
  • This DNS record is required to indicate that address 1.2.3.4 matches the FQDN mail.potatoes.com.
  • If an email service is installed on the same server as our web server, this record could point to the same IP address.
• A DNS record type MX.
  • An MX record is a standard format of DNS addressing that indicates the location of an email server linked to a domain name.
  • In this case, we would indicate that the FQDN mail.potatoes.com is the address of an email server.
  • In practice, these records often point to robust email servers such as Gmail or Outlook.
• A DNS record type TXT for the SPF.
  • An SPF (Sender Policy Framework) entry is a special DNS record that is used as a reference for all email servers around the world to verify the origin of an email and avoid spoofing.
  • In our case, we will specify that only the address 1.2.3.4 and the name mail.potatoes.com are allowed to send email for the domain potatoes.com.

With these records, not only would your fans be able to send you email to share their unconditional love of the famous tuber, but also, if an evil broccoli lover ever tried to send email allegedly coming from the address broccoli@potatoes.com, email servers around the world would immediately be able to see that the originating IP address did not match the SPF instructions of the mail server associated with potatoes.com. Such email would be considered as spam and trashed accordingly (best place for broccoli, in my humble opinion).

This may all seem a little twisted and convoluted, but believe it or not, it is just the tip of the iceberg. If you’re wondering why you need to understand all these concepts, the answer will come in my third and final article, in which I will share some practical tips to help you better manage your digital life. In the meantime, trust me: you’ll soon see why understanding FQDNs, domain names, IP addresses and SPF records will make sense once I give you useful examples and tools to know what is happening.