Comodo Secure DNS
Enjoy a safer, smarter and faster Internet
Enjoy a safer, smarter and faster Internet
In the early days of the Internet, computers located and reached the few interconnected computers by referencing their unique numeric Internet Protocol (IP) addresses (e.g., 192.168.0.1). As the number of interconnected computers grew, the impracticality of memorizing all these numbers became obvious, and a rudimentary naming scheme was developed. A central repository of easy-to-remember names and their associated IP addresses was created and maintained in the form of a plain list in a text file named HOSTS.TXT. Periodically, administrators would connect to the central repository where the authoritative HOSTS.TXT file was located, and would download the current list of computer names. As the number of computers (hosts) on the Internet increased, this file began to grow exponentially, and keeping the hosts file up-to-date became a much more daunting task.
Realizing that this system would prove to be difficult to scale, designers put the host-naming process "under the knife" in order to develop a more scalable system with distributed management - and the Domain Name System (DNS) was born. The designers proceeded to inscribe every detail of their creation and created the DNS Internet standards as defined by RFC 1034 and RFC 1035.
DNS fulfilled its goal of becoming an efficient, distributed and scalable system for resolving human-readable hostnames to network-usable IP addresses.
The DNS hierarchy is a naming format in which the computer would be known by its name, followed by a hierarchical list of domains that were simply logical zones into which the computer fell for management purposes. These names are separated by dots and written in reverse order (broadest domain last). For example, a typical name looks like this:
Since the domain name trees read from right to left, we can interpret that the broadest domain in this example is ".COM". This portion of the name is known as the top-level domain, or TLD. These TLDs are authorized for use by the Internet Corporation for Assigned Names and Numbers (ICANN) and are managed by individual entities called "Registries." "COMODO" in WWW.COMODO.COM represents the second-level domain name, and is registered for use through an entity called a "Registrar." The combination of the second-level and top-level domain is what is commonly referred to as the "domain name."
This leaves "WWW", which is the hostname or the actual computer name as assigned by a local administrator and is now commonly used to refer to websites. Most administrators configure their DNS such that the domain without "WWW." will resolve to the same place as with the "WWW".
While selecting a second-level domain name that directly represents your firm's name is a convention, there is generally no rule requiring this for many TLDs. For most top-level domains, anyone can register any name they choose, providing that the standard naming rules are adhered to and the name is available. Exceptions to this include sponsored top-level domains like .museum and .aero, which limit domains to members of a specific industry or location.
Resolution is the process of translating a domain name into an address that computers can use. The easiest way to understand this process is with an example.
Let's imagine that an Internet user wants to visit a specific website named "WWW.EXAMPLE.COM." Typing the URL into the Web browser initiates the Web request. Before the browser connects to the server hosting the website, however, the user's computer must find the server's IP address. The Web browser first turns this hostname over to the resolver. A resolver's sole purpose is to translate domain names to IP addresses; it is a silent computer program or process that runs on any computer connected to the Internet. The resolver starts by checking its own internal tables to see if it has any information stored or cached containing the IP address for the requested hostname. If not, the resolver checks its configuration for the IP address of a name server to which it can pass the query.
The server to which the resolver connects is known as the "recursive DNS server," and is usually maintained by your ISP or connectivity provider (corporate entities may maintain their own recursive DNS servers). The location of the server is not important, so long as the resolver can connect to it reliably and quickly.
Every domain name registered is required to select two (2) or more name servers that will pass on "official" or "authoritative" data for that domain name to the rest of the Internet when asked. The party who registered the domain designates the name server they wish to have answer authoritatively on their behalf, and they must either maintain these name servers themselves or coordinate with the administrators of an existing server to provide DNS services.
The recursive server, upon receiving a query from the resolver, checks to see if it already has the information being requested. If the recursive server can't resolve the query on its own, it will need to find an answer -- but what servers can it ask, and how does it know about them?
All name servers that respond to queries have a file containing a listing of the names and addresses of Internet root servers. The sole purpose is to get a user started in the Authoritative Chain of DNS servers that will get the right answer.
In our example, the root servers do not know the IP Address for "WWW.EXAMPLE.COM," but will recognize the ".COM" and point the recursive server to the next set of Authoritative servers that it should ask. Now, the query has made it from the client resolver to the recursive server to the root server, and the root server has found the server that should have the necessary information to respond to the query. The root server now passes this address back to the recursive server.
The recursive server contacts each authoritative server in the chain and issues the original query until it finds the answer. It will then return the result to the recursive server. The recursive server delivers the result to the client and usually caches the query result in the event someone asks for it again soon. If a server is supposed to be authoritative for a domain but does not have any information for the domain or is not configured to handle it (a situation known as a "lame delegation"), different things can occur. Some authoritative servers are set up to give a default answer if they do not have an exact match ("wildcarding"), while other servers respond with an error.
The client resolver hands off the IP address in question to the actual network protocols to locate the IP address and establish a connection, and the resolution process is complete.
Although this process seems lengthy on paper, it typically happens in milliseconds!
Resource records are the foundation of DNS. Every piece of information that DNS can provide about a host or domain is stored as a resource record (RR), and dozens of different resource record types exist to help define the types of DNS information available. We'll take a look at a few common types.
Address A
Address A records are the "core" of DNS. The A record stores the IP address associated with a given hostname. Most DNS operations are queries for A records.
Canonical Name (CNAME)
Canonical Names (CNAMEs) are the DNS equivalent of aliases or symbolic links. This record's function is to point a hostname to another hostname. For this to be useful, the "destination" hostname must have an A record that points to an IP address.
A few things to note about CNAMEs:
CNAMEs can point to any hostname on any domain anywhere in the world, regardless of who owns the domain or where it is located.
CNAMEs require that both the destination host and the destination host's A record (IP address) be returned in order to properly resolve. As such, CNAMEs are generally slower than A records and should be used sparingly.
Pointer (PTR)
Pointers are essentially the opposite of A records in that they resolve IP addresses back to hostnames. Although it is not a required function of DNS, some applications like to use an inverse query to authenticate or provide more information about a connected or connecting host.
A few things to note about PTRs:
Just like a domain name, a nameserver must be configured to be authoritative for the block of IP addresses, and the root servers must be aware of this delegation.
The smallest standard block that can be authoritatively delegated is currently 256 IP addresses (otherwise known as a "/24" or somewhat incorrectly as a "Class C"). There are proposed mechanisms to allow sub-delegation of PTR responsibility to even smaller blocks.
You do not have to set up PTRs for your hostnames and your domains to resolve correctly. Some applications may call for it, but it is not required by any Internet standard.
The SOA record defines the given name server's authority for the domain. In addition to authority, the SOA record contains several configuration parameters for the domain as follows:
Person In Charge - Email address of the person responsible for the domain's administration.
Serial Number - This number must be incremented each time a change is made to the records for a domain/zone. If a zone is changed but the serial number is not updated, the secondary server will not acquire the new data when it refreshes its zone information.
Refresh - How often, in seconds, a secondary name server is to check with the primary name server to see if an update is required.
Retry - If a secondary server tries to poll the primary server and fails, the secondary should wait this number of seconds before trying again.
Expire - If the secondary server is not able to update its data by contacting the primary server for this number of seconds, it will stop using the data it has for queries, in case the data is outdated or inaccurate.
Minimum TTL - TTL time is a per-record specification that tells any querying name server how long it should keep that particular record in its cache. The Minimum TTL field is a zone-wide default that is used when a record does not explicitly specify its own TTL time.
Name Server (NS)
NS records supply the hostname of the authoritative name server(s) for the domain. Every domain must have an NS record, and current RFC guidelines specify no fewer than two. Domains can also be divided into sub-domains as specified by local administrators, and each sub-domain can have its own NS records.
MX records specify the hostname of the server that will handle mail for the domain. When you send mail to postmaster@example.COM, your local mail server has to contact the server that handles mail for "example.COM" and pass the email on to it.
The server that handles mail for a domain could feasibly be any server on the Internet, so the host attempting to deliver mail needs a way to find out the address of the server to contact. This is the role of the MX record.
The MX record has three parts: a domain name, a hostname and a preference value. The domain name for the above example would be "example.COM". The hostname is the name of the server to which mail for this domain will be delivered. Incidentally, this server must also be configured to accept and handle mail for the given domain.
The preference value is a number (usually between 0 and 100) to indicate which MX record will be tried first (if more than one exists). A lower number will always be used before a higher number. This allows for some redundancy if the preferred mail-handling host loses connectivity or the ability to accept mail for delivery.
A few caveats about MX records:
MX records are not equivalent to email addresses. They cannot contain a user name, only a hostname. The mail server for your domain handles everything before the "@" on its own.
MX records should never point to a CNAME record, only a host that has a valid A record.
MX records cannot point to an IP address.
The server to which you are pointing will not begin handling mail for you until you let the server's administrator know and that administrator configures the server to accept email for your domain.
The character used as a wildcard in most DNS implementations is the asterisk (*). You may use this character in certain RRTypes to match any hostname beneath your domain.
If you set up an A record for "*.example.COM" to point to "127.0.0.1", every possible hostname will resolve to that IP address. So, with this entry in place, "www.example.COM" would resolve to "127.0.0.1", "mail.example.COM" will resolve to "127.0.0.1" and even "we.love.example.COM" will resolve to "127.0.0.1," all because of a single wildcard record that matches everything. You can configure an A record for "*." to point to "127.0.0.1" by itself, so regardless of the query, it will always respond with 127.0.0.1.
You can also do this for MX records. If mail is sent to "somebody@example.COM", the MX record lookup for "example.COM" would be performed and that mail would be delivered to the host returned in the MX query. What would happen if mail was sent to "somebody@mail.example.COM", or "somebody@anything.example.COM"? The answer is that the mail will not be delivered, since an MX record for these hostnames does not exist. Rather than adding every possible hostname as an MX record, DNS allows you to specify "*.example.COM" as an MX record label, to catch all possible hosts.