Book Image

Managing Mission - Critical Domains and DNS

By : Mark E.Jeftovic
Book Image

Managing Mission - Critical Domains and DNS

By: Mark E.Jeftovic

Overview of this book

Managing your organization's naming architecture and mitigating risks within complex naming environments is very important. This book will go beyond looking at “how to run a name server” or “how to DNSSEC sign a domain”, Managing Mission Critical Domains & DNS looks across the entire spectrum of naming; from external factors that exert influence on your domains to all the internal factors to consider when operating your DNS. The readers are taken on a comprehensive guided tour through the world of naming: from understanding the role of registrars and how they interact with registries, to what exactly is it that ICANN does anyway? Once the prerequisite knowledge of the domain name ecosystem is acquired, the readers are taken through all aspects of DNS operations. Whether your organization operates its own nameservers or utilizes an outsourced vendor, or both, we examine the complex web of interlocking factors that must be taken into account but are too frequently overlooked. By the end of this book, our readers will have an end to end to understanding of all the aspects covered in DNS name servers.
Table of Contents (17 chapters)
7
Types and Uses of Common Resource Records

Domain names 101

You probably already know that a domain name is simply an alphanumeric string that is mapped—via the Domain Name System (DNS) to other data—like an Internet Protocol (IP) address.

So, asking, What is a domain? may seem self-explanatory. example.com is a domain.

However, when you get into the specifics of the DNS protocol and the documents that describe it, we start to run into some odd nuances in terms of what the formal specification of a domain is, versus what you can actually register online at some domain registrar as "your domain name."

For example, underscores are permitted in domain names. This is why certain types of records and practices use them. Later in this book, when we're examining SRV records, we'll see underscores. Take a look at this:

_xmpp-client._tcp.example.com.

However, you cannot go to a registrar website and successfully register something like example_domain.com. The underscore would not be allowed. A hyphen would be permitted, as long as the domain does not begin or end with one.

Now, how about a "hostname"? Those are easy too, right? www.example.com is a hostname. But, now, you can't use an underscore in your hostname, ever. But you can still use hyphens, just as long as they're not at the beginning or the end of a label.

(The labels are the alphanumeric strings between each dot. www, example, and com are the labels that comprise the hostname www.example.com.)

What we are seeing here is an example of the difference between what I call "the domain name ecosystem," which entails the world of registrars, registries, and oversight bodies, and "the DNS," which is what happens on your domains' nameservers or on the operations side of your organization. Take a look at this diagram:

Figure 1: The two logical realms of a domain name

As another example, we will very shortly look at the Anatomy of a domain name, where we will look at the various data components that go into a domain name registration. One of those components is called "the registrant," which is effectively the domain owner. It is the entity that owns the domain name. This is pretty straightforward, but it is not to be confused with the owner name as part of a DNS resource record (RR), which is all the individual records that your nameservers hold and serve up to make your domain—or, more specifically, your zone—visible across the internet.

In Figure 1, those myriad resource records are on the right side of our diagram, under the ops realm, collectively forming a zone, and each record in there will have an owner name, which carries a completely different meaning than the owner of the domain name, shown on the left side, under the domain ecosystem realm

The various components of "the ecosystem realm" are best depicted by the registration details that must be provided at the time a domain is registered, which are held in a database called "WHOIS."

The reason we've gone to such lengths to define these two, seemingly disparate, realms of factors that go into a domain name is this: In my 20+ years of experience in this field, as a sysop, as a CTO, and then CEO of a managed DNS provider, and as a former director for a registry operator, I have observed that a significant portion of domain-related outages occur because of a disconnect between these two realms. Organizations operate with an artificial divide between the overall domain name ecosystem and the nuts-and-bolts operations of their domains, and that can cause problems.

Anatomy of a domain name

In this section, we'll break out the functional components of a "domain name" from the perspective of the overall ecosystem on the left side of the diagram in Figure 1.1.

The "domain name" in this context is a naming entity such as example.com or any other domain we register via a domain registrar.

Registration details for domain names are kept in publicly accessible databases called WHOIS servers. The record for a given domain name is typically called a WHOIS record.

We'll look at a WHOIS record for a domain name and break out the logical components of the registration details. Each section has a distinct meaning and function within the overall ecosystem.

If you run the following example whois command on your own system, you may see a different output depending on what kind of WHOIS client you are using. For our examples, we are just using a command line whois command, which you typically find on most Linux or Unix systems.

A note on examples and example.com.

example.com is an example of a domain name. It (and several others) are specifically reserved by IANA to serve the purpose of providing examples without requiring prior permission from anybody. RFC 2606 describes "Reserved Top-Level DNS Names" and their functions. Throughout the book, I use example.com wherever possible. In cases where I need to show some specific element not present within example.com , I'll use different domain names as required. I sometimes employ the nonexistent top-level domain (TLD) .dom in examples (even though the reserved TLD .example exists and has been reserved for this purpose, it is, like so many of these "new TLDs," long and cumbersome).

WHOIS output for https://www.packtpub.com/the publisher of this book is shows as follows:

$ whois packtpub.com
Domain Name: PACKTPUB.COM
Domain ID: 97706392_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.easydns.com
Registrar URL: http://www.easydns.com
Updated Date: 2015-09-15T21:46:16Z
Creation Date: 2003-05-09T14:34:02Z
Registrar Registration Expiration Date: 2024-05-09T14:34:02Z
Registrar: easyDNS Technologies, Inc.
Registrar IANA ID: 469
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
Registry Registrant ID:
Registrant Name: Domain Manager
Registrant Organization: Packt Publishing
Registrant Street: 2nd Floor Livery Place, 35 Livery Street
Registrant City: Birmingham
Registrant State/Province: West Midlands
Registrant Postal Code: B3 2PB
Registrant Country: GB
Registrant Phone: +44.1212656484
Registrant Phone Ext:
Registrant Fax:
Registrant Email: [email protected]
Registry Admin ID:
Admin Name: Domain Manager
Admin Organization: Packt Publishing
Admin Street: 2nd Floor Livery Place, 35 Livery Street
Admin City: Birmingham
Admin State/Province: West Midlands
Admin Postal Code: B3 2PB
Admin Country: GB
Admin Phone: +44.1212656484
Admin Phone Ext:
Admin Fax:
Admin Fax Ext:
Admin Email: [email protected]
Registry Tech ID:
Tech Name: Domain Manager
Tech Organization: Packt Publishing
Tech Street: 2nd Floor Livery Place, 35 Livery Street
Tech City: Birmingham
Tech State/Province: West Midlands
Tech Postal Code: B3 2PB
Tech Country: GB
Tech Phone: +44.1212656484
Tech Fax:
Tech Fax Ext:
Tech Email: [email protected]
Name Server: DNS3.EASYDNS.ORG
Name Server: DNS1.EASYDNS.COM
Name Server: DNS2.EASYDNS.NET
Name Server: DNS4.EASYDNS.INFO
DNSSEC: unsigned
Registrar Abuse Contact Email: [email protected]
Registrar Abuse Contact Phone: +1.4165358672

WHOIS record formats differ between TLDs—and we'll discuss some of the key differences in these when we take a closer look at WHOIS—but they all share similar characteristics that can help us dissect the various "moving parts" of a domain; they are the following:

  • Registry details
  • Domain registrant
  • Administrative contact
  • Technical contact
  • Domain status
  • DNS details

Registry details

This tells us who the registrar is and key dates such as these:

  • When the domain was registered
  • When the associated record was last modified
  • The registrar's name, URL, and abuse contact

The registry details also contain the following elements that require a more in-depth explanation.

Registrar WHOIS server

This is a server that can be queried directly for a specific WHOIS record for a domain using the -h switch from the command line:

whois -h whois.easydns.com packtpub.com

There are a few reasons you may need to do this. Some WHOIS clients do a reasonably good job of figuring out which WHOIS server to query. Sometimes, for factors outside of their control, such as a change in WHOIS output format, this doesn't happen.

Furthermore, with the flood of new top-level domains ("new TLDs") now coming out, there are sometimes cases where a new TLD's WHOIS server has not yet been added to various WHOIS lookup tools. Each new TLD must operate a WHOIS server accessible on port 43, using the hostname whois.nic.<tld>.

From a command line WHOIS lookup, you would then use the -h switch. For example, if the hot new TLD everybody wants a piece of is .blargh, you would use this:

$ whois -h whois.nic.blargh example.blargh

Expiry date

At first glance, the field that contains a domain's expiry date may seem pretty self-explanatory. It's the date after which the domain expires at the registry, right? Mostly. Sort of.

The reality is that when a domain expires at the registry, it goes into a cycle called "the expiry cycle", which takes several weeks, or even months, to play out, and it is absolutely critical that you are familiar with this cycle and what is permitted and not permitted at each stage within it. For this reason, the next section steps through the entire expiry cycle.

The other thing to know about the listed expiry date in the WHOIS record is that the date shown might not actually be the expiry date. It may show the expiry as roughly one year from now, but the domain is actually already past expiry. WHOIS snippet of an expired domain displaying expiry date next year is shown as follows:

Domain Name: EXAMPLE.NET
Registry Domain ID: 1853290837_DOMAIN_NET-VRSN
Registrar WHOIS Server: whois.easydns.com
Registrar URL: http://www.easydns.com
Updated Date: 2018-04-04T07:47:36Z
Creation Date: 2014-04-03T21:32:39Z
Registry Expiry Date: 2019-04-03T21:32:39Z
Registrar: easyDNS Technologies, Inc.
Registrar IANA ID: 469

The reason for this is most registries use a mechanism called "auto-renew" at the registrar level: When the domain expires, the registry will automatically charge the registrar for another year renewal on the domain, which causes the expiry date in the WHOIS output to display an additional year.

However, if the registrar's customer hasn't renewed the domain, then the nameservers for the domain will be removed from the TLDs zone, causing the domain and anything that depends on it to stop working.

If you are looking at a domain that expires on or just before the current day, and the expiry date is one year in the future, but the domain does not resolve across the internet, then this is a likely cause. We cover what happens next in more detail in the next section.

The registrant contact set

It cannot be overemphasized how important it is that your organization gets this part right, especially given how many times over the years I've seen companies get this part wrong, sometimes with catastrophic results. Any other mistake we can make when it comes to the administration of the registration details of our domain portfolio is fixable. Sometimes this one isn't. When that happens, it can result in a permanent "lock out" condition.

The listed registrant for a domain must be the legal name of your business, organization, or the ultimate user of the domain.

Too often, it is one of the following:

  • An employee of the organization (using the employee's own name)
  • An outside consultant
  • "Fake" data of a nonexistent entity (in an effort to avoid spam or shield underlying data)
  • The party who facilitated the domain registration (such as a web host or ISP) – "free domain included" offers are notorious for this
  • The entity the domain was purchased from on the aftermarket whose contact details were never modified after control was transferred, which happens frequently

It's not completely clear whether domain names themselves are actual "property" or whether they simply convey rights. There have been arguments and legal decisions going both ways in differing jurisdictions. Suffice it to say for our purposes, the owner or rightsholder, whomever or whatever is listed as a domain's "registrant," is the ultimate authority over what happens to that domain.

This means that if you find yourself in a domain "lock-out" situation, the only entity that will be able to regain access and control over the domain is the one listed as the domain's registrant. If that is somebody else other than you, your company, or your organization, then you are at their mercy. If that somebody else doesn't exist, then you are probably screwed.

The administrative contact set

This contact set looks a lot like the registrant contact set, and in many cases they are the same or contain the same data. In the early days (when Network Solutions had the monopoly on .com/.net/.org domain registrations), there were only two contact sets: administrative ("admin") and technical.

Historically, it's the admin contact that exerts control over the domain name; even today now that the registrant contact set exists, if you have to do a password reset, or your registrar sends out some kind of notice, it'll often go to the admin contact email.

For this reason, it's very important that this email address be chosen with some care; I always recommend the following best practices.

Use a domain you control

Make sure your email address is under a domain name you directly control, not some third party.

Use a different domain than the name in the record

Don't use [email protected] in example.com, use [email protected] instead. Even if all your other domains use @example.com addresses, it is then especially important that you never lose control over the admin access to example.com. It is worth provisioning a separate domain just for this purpose.

Use an exploder

Have that email address explode out to multiple personnel within the organization, ideally also feeding into some process-tracking system, such as a ticketing queue.

Use a unique address

Specify a role account address that is specific to your domain names, such as hostmaster@—it gives you the option to filter on it.

Alternatively, use canaries

If your organization has a large portfolio of domains to manage directly, you could register a domain specifically for use as your point-of-contact info and then use email canaries for each domain or department or team: [email protected], [email protected]you can then filter and track each domain individually.

The tech contact set

This contact set typically exerts no operational or administrative control over the domain. It is primarily a point of contact that network operators can use to establish communications in order to work through various network issues that may arise.

This usually included net abuse issues until the advent of the abuse contact set.

The billing contact set

Historically, this set was created to provide a separate point of contact for billing issues related to a domain name, and was a boon for domain slammers (see Chapter 2, Registries, Registrars, and Whois). Again, this contact provides no operational control over the domain and is frequently the admin contact set duplicated.

DNS details

Here, finally, we get to the actual "guts" of what makes a domain name actually "light up" on the internet: the DNS details, such as the nameserver delegation and its DNSSEC status.

The nameserver delegation is the set of authoritative nameservers for the domain. The nameservers listed here are the ones that will receive and respond to all DNS queries for the subject domain name. Most of this book is concerned with operating these types of nameservers while minimizing mental anguish; that is, sysadmin angst or "blood in the streets"-style DNS outages.

Status

While many country ccTLDs use the same or similar status codes to the generic TLDs (gTLDs) we are about to describe, some do not. The following codes are the ones used under gTLDs.

One or more status fields will be present to indicate what operations can be carried out on the domain name and what state it is in. These statuses are set by either the registry of the parent TLD, or by the registrar of the domain name.

Status flags set by the registry

The status flags set by the registry are as follows:

Ok

No prohibitions or restrictions are in place against this domain. It is somewhat counter-intuitive to see this because it means there are no transfer locks enabled, making the domain susceptible to unauthorized hijackings or domain slamming. (In other words, when I see a domain with this status, it's something of a "red flag": something that needs to be rectified.)

inactive

The domain has no nameserver delegation associated with it and thus does not resolve across the internet.

autoRenewPeriod

The domain has expired and is in a grace period. The domain does not resolve across the internet—or it may be delegated to interim nameservers set by your registrar that intercepts your DNS and outputs a landing page ("The domain you are trying to reach has expired"). In most cases, the domain may still be renewed in the normal fashion and doing so will restore normal operations and DNS resolution almost immediately. (Also, see the Understanding the domain name expiry cycle section.)

pendingTransfer

The domain is currently being transferred from the current registrar (aka the "losing registrar") to a new one (the "gaining registrar").

redemptionPeriod

The domain has expired, the expiry grace period has also ended, and the domain's registrar has gone ahead and issued the "delete" command to the registry. redemptionPeriod is a 30-day grace period, during which it can still be renewed ("redeemed") by your registrar. (See the Understanding the domain name expiry cycle section.)

pendingDelete

The redemptionPeriod has ended and the domain will be completely deleted from the registry within a few days (usually five). Once that happens, the domain comes available for reregistration by interested parties. (If the domain has any marginal value, it will be reregistered within milliseconds.)

Status Flags set by the Registrar

clientHold

The domain has had its nameserver delegation revoked, and it will not resolve across the internet. This can be the result of an unfulfilled WHOIS Accuracy Program verification or some other legal or billing dispute against the domain.

clientDeleteProhibited

Automatically reject any requests to delete this domain while this flag is present.

clientTransferProhibited

Automatically reject any transfer requests while this flag is present. This is usually desirable and protects your domain from unauthorized hijackings and will help thwart inadvertent slamming attempts.

clientUpdateProhibited

Automatically reject any modifications or updates to the domain. Again, it is prudent to have this flag set. Many registrars set this and clientTransferProhibited as the normal state for domains. When you need to make changes to your domains, the systems temporarily clear these locks, make the updates, and re-instate them, provided the request is coming from an authorized party.

clientRenewProhibited

The domain cannot be renewed in its current state. Contact your registrar to find out why.

Understanding the domain name expiry cycle

Registration terms typically run in one-year cycles. If you register a domain today for one year, it will expire one year from today. The expiration date will be listed in the domain's WHOIS record. (See the previous section, Anatomy of a domain name, and recall that the expiry date listed in the WHOIS record may not be the actual, for-real, expiry date.)

On that day, if you have not renewed your domain via your registrar, the registrar will remove your nameserver delegation out of the TLD and your domain stops resolving.

This is the point at which many people erroneously assume that somebody else can now come in and reregister this expired domain. But this is not the case. Let's plod through this cycle.

The expiry cycle varies between TLDs. Not all TLDs allow or facilitate "parking" as we shortly describe it; some have different "drop" procedures in place. This cycle describes it as it functions for the largest TLDs (.com/.net/.org , for instance) and most of the new gTLDs.

Domain expires (day 0)

Domain expires. The registrant's rights have lapsed. The domain stops working. (The expiry date in the WHOIS record may display next year's date if the registry uses "auto-renew with registrar.")

Domain gets parked (days 3 to 5-ish)

Somewhere after a few days, many registrars will "park" the domain by inserting new "domain parking" nameservers into the TLD zone for your domain.

You may recognize this when you see it; you may arrive at a web landing page that says something to the effect of, "This domain has expired." It may be peppered with pay-per-click ads, or there may be an offer to backorder the domain.

You may also notice when you look at the WHOIS record that the nameservers are no longer the "usual" nameservers for the domain, but have other names such as ns1.expireddomain.dom or ns2.expireddomain.dom.

Doing this ostensibly serves to alert end users and, hopefully, word will get back to somebody who is in a position to do something about it to renew the domain.

What is also happening is that the registrar is doing one or more of the following:

  • Monetizing clicks
  • Measuring traffic
  • Running free ads for their own stuff
  • Soliciting interest ahead of an auction of the domain

This is a critical window in the domain life cycle because it is at this point where the registrant's (yours) and the registrar's interests may have diverged. This is because if your domain is a good one (defined as being one or more of the following: old, generic, dictionary, popular, high-traffic, or heavily backlinked), then it may be worth more to your registrar if you neglect to renew this domain rather than if you renew it.

If you renew your domain, it's worth a few bucks to your registrar. If you forget to renew it and they can auction it for $10,000 or $100,000, well then, that's another matter entirely....

RGP – Registrant Grace Period (up to 45 days)

For the next 35 or 40 days, or maybe 45 (yes, it's that inexact, the registrar can do this next step at any time), the domain is in a state called the registrant grace period (RGP).

During this period the domain can be renewed "normally." For example, if this is a non-production domain, nobody had noticed it had expired, then after a couple weeks you find your renewal notice and renew the domain, then the domain gets renewed like any other renewal. It just starts working again and everything reverts back to normal.

But at any time during the RGP, the registrar may also "direct transfer" your domain to another party. They can do this because your rights terminated back on "day 0," the day the domain expired. This is a grace period, and toward the end of the grace period, the registrar will reserve the right to move this domain off to auction, or to sell it directly to another end user.

Domains in this state can still be transferred by the registrant to another registrar (thus triggering a renewal in the process)—however, not all registrars allow it.

Redemption period (day 45-ish)

We have previously talked about the expiry date and how many registries operate under something called "auto-renewal" (this is a different context from end-user auto-renewal; we'll cover that shortly).

It means when the domain hits the expiry date, the registry automatically renews it and bills the registrar. The registrar has paid for, and is out-of-pocket on this domain name until they issue a "delete" command to the registry.

If the domain is nearing the end of the registrant grace period (up to 45 days), and if the domain looks of marginal value, meaning that nobody has expressed an interest in buying or bidding on it, and the domain isn't earning enough in pay-per-click to cover its renewal fees, then the registrar will issue that "delete" via an Extended Provisioning Process (EPP) call to the registry, and then they get their money back from the earlier auto-renewal.

The domain then enters the next phase of the expiry cycle: the redemption period. This lasts for an additional 45 days.

During this period, the domain can still be "redeemed," but only by the original registrant from before the domain expired. The registrar must not direct transfer it to another party, and they must not change the owner or registrant details aside from those which were in place before expiry. The ship has sailed on the registrar's ability to "direct transfer" it to another party.

The registry charges the registrar a "redemption fee" typically much larger than the normal renewal cost. If a domain has a wholesale cost for renewal by the registrar of $9, a redemption can cost the registrar $80 or over $100. Of course, that elevated cost will be passed back to the registrant and then some.

You can recognize the redemption period on a domain from the DomainStatus field of the WHOIS record. Take a look at this code:

Domain Name: EXAMPLEEXPIRY.COM Registrar: EASYDNS TECHNOLOGIES INC.
Sponsoring Registrar IANA ID: 469 Whois Server: whois.easydns.com Referral URL: http://www.easydns.com Name Server: DNS1.EASYDNS.COM
Name Server: DNS2.EASYDNS.NET
Name Server: DNS3.EASYDNS.CA
Status: redemptionPeriod https://icann.org/epp#redemptionPeriod Updated Date: 25-apr-2017
Creation Date: 15-mar-2011 Expiration Date: 15-mar-2017

This period is the "last-ditch" chance to renew a lapsed domain. It would be extraordinary for a busy production domain to get to this stage. Too much infrastructure and too many dependencies would be broken for too long (we're up at about 90 days of total nonfunctional DNS by this point). I have seen it happen, but more typically this affects domains that people have but aren't actively using. That doesn't prevent some pretty monster names from going the way of the expiry cycle, however.

PendingDelete – day 90 (5 days)

Finally, after 45 days in the redemption period, the registry sends the domain into its final state before it's eventual deletion: PendingDelete. As usual, this status will be visible in the DomainStatus field of WHOIS. Take a look at this:

Domain Name: EXAMPLEEXPIRY.COM
Registrar: EASYDNS TECHNOLOGIES INC.
Sponsoring Registrar IANA ID: 469 Whois Server: whois.easydns.com Referral URL: http://www.easydns.com Name Server: DNS1.EASYDNS.COM
Name Server: DNS2.EASYDNS.NET
Name Server: DNS3.EASYDNS.CA
Status: pendingDelete https://icann.org/epp#pendingDelete Updated Date: 25-apr-2017
Creation Date: 15-mar-2011 Expiration Date: 15-mar-2017

A domain in PendingDelete status cannot be renewed or redeemed; it's too late for any of that.

After five days in PendingDelete, the domain will finally be deleted and available for reregistration by anybody. If the domain has any marginal value (but somehow got through the registrar's expiry-stream mining), then the "drop-catchers" will now converge and the domain will be reregistered within a few milliseconds.

Never do this

It's important to understand that you should never intentionally allow a domain name you care about to expire with the plan of reregistering it elsewhere after. If the domain has any marginal value whatsoever, in terms of backlinks, percieved "type-in" value, and so on, it most likely will be backordered and scooped by a name sniper.

What to do if you lose a key domain

Sometimes it happens: that key domain or one belonging to your downstream customer or user slips through the cracks and before anybody notices it, it's in PendingDelete status, and you have no way to retrieve it.

You still have one avenue left to try to obtain it before it becomes reregistered to another party: you can utilize the services of a "drop-catcher." These are companies who have developed systems specifically optimized to grab expiring domain names within seconds of them being finally dropped at the registry.

Some drop-catchers include the following:

If we're dealing with a .CA domain:

And there are specialized services appearing such as these:

  • http://park.io, which specializes in .me, .to, .io, and .ly drop catching