A long time ago, on my first day of college at the Music Industry Arts school at Fanshawe College in London, Ontario, our recording engineering teacher-to-be told us:

As it turned out, there was a trick to rolling microphone cables that I did not know, which was why until then all my cables always gnarled into twisted, random barbs of spaghetti in my gig bag. But after I learned "the trick," all my cables henceforth fell into ordered, neat, clean loops, and remained that way, even after transport. It was worth the price of admission to college.

This chapter is the "learning to unplug and then roll a microphone cable" of naming. We're going to get an overview of important aspects of naming beyond your own network and outside your own domain's nameservers. We're going to do this because it is necessary to have this knowledge in hand and have processes within your own organization to manage these functions of the names you are responsible for. If you don't, then you can do everything else in this book, from setting up your nameservers, to cluefully selecting an outsourced vendor, to defending against denial-of-service (DoS) attacks absolutely correctly, and with flawless execution, yet still find yourself experiencing a catastrophic outage because of something from outside your operations that affected a key domain name.

We'll start by taking a high-level overview of a domain name itself and breaking it into logical components that have different meanings and, with that, different implications.

By the end of this chapter, you should have a greater understanding of the overall workings and life cycles of your domain names, from inception (registration), through resolution (nameservers), to death (expiry), than many IT professionals have

In this chapter, we will cover the following topics:

• Why domains are important
• Domain names 101
• Anatomy of a domain name
• Understanding the domain name expiry cycle

Without the DNS or "hostnames" or domain names, we would be left having to reference all endpoints of our internet connections by their raw IP addresses.

While some people (mostly cranks) occasionally argue that this wouldn't be a bad thing, the fact remains that this name-to-number (and vice versa) translation is necessary because it adds a level of abstraction that allows seamless changes in our internet endpoints and destinations. Take a look at this:

Without hostname and domain name labels, and a universal mechanism to map between the two, all applications would have to somehow acquire end-to-end knowledge of all their peers, servers, or clients.

There is also another aspect of the DNS, which has emerged relatively recently, that takes it beyond a protocol simply for mapping names to IP addresses and back. The DNS is now, and will increasingly be, used to publish metadata.

Because of its ubiquity and relatively light footprint, especially combined with DNSSEC to authenticate responses, the DNS lends itself well for publishing other data that applications and clients will be searching for. I am speaking specifically now of authentication, reputation, and encryption processes such as X.509 certificates, PGP/GPG keys, DNS-based Real-Time Blackhole Lists (RBLs), and response policy zones (RPZs). The relatively widespread adaptation of SPF and DKIM signal the early beginnings of these types of DNS applications.

In the future, I see more activity occurring in these fields. As organizations and individuals come to grips with "surveillance-as-a-fact-of-life" and other shenanigans (such as third-party Certificate Authority (CA) debacles), an inexorable move toward taking control over your own data integrity and privacy is taking place. Thus, we see DANE as a response to having to rely on (possibly compromised, or corrupt) third-party CAs. We see increasing adaption of encryption and privacy enhancement, utilizing more uptake of DNSSEC and more authentication credentials being deployed over the DNS.

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:

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.

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: packtsupport@packtpub.com
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: packtsupport@packtpub.com
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: packtsupport@packtpub.com
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: abuse@easydns.com
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

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.

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

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.

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.

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.

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

Don't use hostmaster@example.com in example.com, use hostmaster@example.net 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.

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.

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

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: example.net@packtpub-hostmaster.com, example.com@packtpub-hostmaster.com—you can then filter and track each domain individually.

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.

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.

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.

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.

The status flags set by the registry are as follows:

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.)

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

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.)

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

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.)

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.)

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.

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

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.

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.

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

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. 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.")

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....

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.

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.

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.

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.

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:

• http://www.namejet.com
• http://www.snapnames.com
• http://www.pool.com

If we're dealing with a .CA domain:

• https://www.egatedomains.ca/content/tbr.php
• https://www.sibername.com/tbr/

And there are specialized services appearing such as these:

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

While the simplest explanation for a domain name may be "a unique name that identifies an internet resource such as a website," to convey the full spectrum of interlocking issues that govern and maintain them, it is useful to examine the data entities, DNS hierarchy, and objects that comprise the typical WHOIS records that describe them.

The basic, prerequisite knowledge of the overall domain name ecosystem includes individual domains and the data elements that describe them, their corresponding registries, which manage each domain's parent TLD, and the registrars, which provide the interface between our names and their registries.

The following points give further insight into the topics we have covered in this chapter, including internet addresses where you can find out more about domain names and related topics:

1. One example that springs to mind was a Canadian bitcoin exchange where the CEO used a purely fictitious name in the WHOIS record because both the exchange and himself personally were constantly under various forms of attack. The problem manifested through a unique combination of unfortunate events (don't they always?). The company lost access to their registrar account at roughly the same time that a hostile third party was attempting to hijack the same account, causing the then-registrar to put the account into "lockdown." The exchange had no means to prove its legitimate claim to a domain name that was, at the time, handling millions of dollars in bitcoin exchange volumes and was registered to a nonexistent person. They operated for over a year in a state of limbo, having no access to the account controlling their prime domain name and in constant dread that some third party would successfully hijack it at any moment.
2. ICANN maintains a complete list of EPP status codes and meanings at https://www.icann.org/epp.
3. Some sections of this book were hard to write because I feared veering off into "infomercial" territory. There is a service that exists solely to monitor various aspects of your domain names, including expiry dates and those windows when your registrar's interests are opposed to yours. It's called https://domainsure.com. But here's the thing - we created it. Sorry if that's self-promotion, but it's the only service of its kind that exists at the time of writing.
4. This applies mainly to gTLD and new TLD domains. Many ccTLD registries tightly control the expiry process and this is not possible. For example, CIRA runs the "To Be Released" (TBR) process and .CA registrars cannot "direct transfer" .CA domains or otherwise auction expiring names.
5. Even my company operates web.to as a pseudo-TLD for "Toronto," but it's really the ccTLD for the Kingdom of Tonga.
6. .aero, .biz, .coop, .info, .museum, .name, and .pro in 2000 and then .asia, .cat, .jobs, .mobi, .post, .tel, and .xxx in 2004.
7. See Victor Mayer's Danger + Opportunity != Crisis (http://pinyin.info/chinese/crisis.html).

8. I added this section after a high-school friend from my hometown contacted me asking for advice on getting his business's domain name back up and running. It turned out he had paid for his domain renewal to his Canada-based reseller, who had gone bankrupt years earlier. The defunct reseller still had a server online somewhere which was on autopilot, sending out renewal invoices which would never be actioned when somebody actually paid them. The registrar was in India and took 24 hours or more to respond to email support requests, to which they initially replied, "Please speak to your reseller." They never did rectify the situation and we ended up transferring his domain over to our system, which took another seven days under that TLD. All told, his business website was down for over two weeks.
9. NameCheap was sued by a Dutch company for alleged "cybersquatting" because their offending domains were using their WhoisGuard service - see http://www.domainnamenews.com/featured/namecheap-sued-domain-whois-privacy-service/5198.
10. For a long period of time easyDNS refused to offer WHOIS privacy for these reasons, but people really seemed to want it, so we did an "official flip-flop" and started offering it.
11. We submitted public comments recommending against changing the current policy until WHOIS could be redesigned from the ground up.
12. Via Wikipedia (http://en.wikipedia.org/wiki/Domain_name).