E-Book
35,99 €

Managing Mission - Critical Domains and DNS E-Book

Mark E. Jeftovic

0,0

35,99 €

Sammeln Sie Punkte in unserem Gutscheinprogramm und kaufen Sie E-Books und Hörbücher mit bis zu 100% Rabatt.

Mehr erfahren.

Herausgeber: Packt Publishing
Kategorie: Wissenschaft und neue Technologien
Sprache: Englisch

Beschreibung

This book will give you an all encompassing view of the domain name ecosystem combined with a comprehensive set of operations strategies.

Key FeaturesManage infrastructure, risk, and management of DNS name servers. Get hands-on with factors like types of name servers, DNS queries and and so on. Practical guide for system administrators to manage mission-critical serversBased on real-world experience - Written by an industry veteran who has made every possible mistake within this field.Book Description

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.

What you will learnAnatomy of a domain - how a domain is the sum of both its DNS zone and its registration data, and why that matters.The domain name ecosystem - the role of registries, registrars and oversight bodies and their effect on your names.How DNS queries work - queries and responses are examined including debugging techniques to zero in on problems.Nameserver considerations - alternative nameserver daemons, numbering considerations, and deployment architectures.DNS use cases - the right way for basic operations such as domain transfers, large scale migrations, GeoDNS, Anycast DNS.Securing your domains - All aspects of security from registrar vendor selection, to DNSSEC and DDOS mitigation strategies.Who this book is for

Ideal for sysadmins, webmasters, IT consultants, and developers-anyone responsible for maintaining your organization's core DNS

Mark E. Jeftovic is the cofounder and CEO of easyDNS Technologies Inc, the managed DNS provider and domain name registrar. He was formerly a director to the Canadian Internet Registration Authority (CIRA) and is currently a director to the Internet Society Canada Chapter. Mark entered the internet space in the early '90s as a computer programmer and Unix sysadmin, working for the early dial-up ISPs in Toronto before cofounding a web development firm in 1995 that later morphed into easyDNS. A lifelong guitarist and avid bookworm, Mark lives in Toronto with wife Angela and daughter Emily.

Details

Sie lesen das E-Book in den Legimi-Apps auf:

Android

iOS

von Legimi
zertifizierten E-Readern

Seitenzahl: 429

Veröffentlichungsjahr: 2018

Bewertungen

0,0

Rezensionen(0 Rezensionen)

Leseprobe

Managing Mission-Critical Domains and DNS

Demystifying nameservers, DNS, and domain names

Mark E. Jeftovic

BIRMINGHAM - MUMBAI

Managing Mission-Critical Domains and DNS

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author(s), nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Commissioning Editor: Gebin GeorgeAcquisition Editor:Noyonika DasContent Development Editor:Mohammed Yusuf ImaratwaleTechnical Editor: Shweta JadhavCopy Editor:Safis EditingProject Coordinator:Hardik BhindeProofreader: Safis EditingIndexer:Mariammal ChettiyarGraphics:Jason MonteiroProduction Coordinator:Shantanu Zagade

First published: June 2018

Production reference: 1300618

Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK.

ISBN 978-1-78913-507-7

www.packtpub.com

To my wife Angela, whose resiliency and focus is an inspiration. To my daughter Emily, who never ceases to amaze.

– Mark

mapt.io

Mapt is an online digital library that gives you full access to over 5,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.

Why subscribe?

Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals

Improve your learning with Skill Plans built especially for you

Get a free eBook or video every month

Mapt is fully searchable

Copy and paste, print, and bookmark content

PacktPub.com

Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.

At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.

Contributors

About the author

Mark entered the internet space in the early '90s as a computer programmer and Unix sysadmin, working for the early dial-up ISPs in Toronto before cofounding a web development firm in 1995 that later morphed into easyDNS.

A lifelong guitarist and avid bookworm, Mark lives in Toronto with wife Angela and daughter Emily.

This book would not have been possible without the generous help from the following people: Tamas Acs, Ranko Rodic, Peter Van Dijk, Matt Pounsett, Patrik Lundin, Cricket Liu, John Demco, George Kirikos, Russ Nelson, Jan-Piet Mens, Jaques Latour, Joe Abley, Bert Hubert, Paul Vixie, Steve Job, Jim Carroll, Rick Broadhead, Richard Lau, Jothan Frakes, Dan Blais, Douglas Patterson, Noyonika Das, Mohammed Imaratwale, and Sandro Pasquale.

Packt is searching for authors like you

If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.

Title Page

Managing Mission-Critical Domains and DNS

Dedication

Packt Upsell

Why subscribe?

PacktPub.com

Contributors

About the author

Packt is searching for authors like you

Preface

Who this book is for

What this book covers

To get the most out of this book

Download the color images

Conventions used

Get in touch

Reviews

The Domain Name Ecosystem

Why domains are important

Domain names 101

Anatomy of a domain name

Registry details

Registrar WHOIS server

Expiry date

The registrant contact set

The administrative contact set

Use a domain you control

Use a different domain than the name in the record

Use an exploder

Use a unique address

Alternatively, use canaries

The tech contact set

The billing contact set

DNS details

Status

Status flags set by the registry

inactive

autoRenewPeriod

pendingTransfer

redemptionPeriod

pendingDelete

Status Flags set by the Registrar

clientHold

clientDeleteProhibited

clientTransferProhibited

clientUpdateProhibited

clientRenewProhibited

Understanding the domain name expiry cycle

Domain expires (day 0)

Domain gets parked (days 3 to 5-ish)

RGP – Registrant Grace Period (up to 45 days)

Redemption period (day 45-ish)

PendingDelete – day 90 (5 days)

Never do this

What to do if you lose a key domain

Summary

References

Registries, Registrars, and Whois

Registries and Registrars

Generic TLDs

Country Code TLDs (ccTLDs)

New Top-Level Domains

IDN TLDs

Online tools for converting punycode

Infrastructure TLDs

Registrars and Resellers

An effective Registrar should...

What is Whois?

Thin versus thick Whois

Whois privacy

RegisterFly – The Lehman Brothers' moment of the domain industry

How to tell whether Whois privacy is enabled

Why you should always use Whois privacy

Why you should never use Whois privacy

Where is Whois going?

Europe's GDPR and its effect on Whois

Registration Data Access Protocol (RDAP)

Preface

Domain names and DNS can be thought of as the basic foundation of the internet. If you want to explain how important DNS is to somebody, you might find the following useful; this has been my "30-second elevator pitch" about DNS for close to 20 years now:

"Everytime you send an email; visit a web page; type or receive an instant message, text or SMS; place a VoIP call (or a Skype call), or do anything else involving the internet, it cannot happen until a bunch of computers around the internet have a conversation about it:

Where does this email need to be delivered?What server is holding the file that this web browser is asking for?Where is the VoIP gateway that needs to route this call?These conversations happen very quickly, typically in under 100 milliseconds (less than a quarter of the time it takes you to blink), and typically involve, at a minimum, 3 or 4 disparate servers around the globe. None of those servers have anything to do with the actual email, web page, or application being routed.These special computers are called nameservers, and without them, absolutely nothing would happen on the internet.

What is interesting about DNS, given its importance, is how overlooked it is in the overall scheme of IT. Similarly, domain names (the logical naming entities that anchor DNS lookups) are often the most profoundly misunderstood facets of IT as well, even by otherwise advanced technical personnel.

For some reason, DNS and domain names seem to be a blind spot in many organizations' infrastructure. As we have fondly quipped since our early days as a managed DNS provider, "DNS is something nobody cares about …until it stops working".

It never fails to amaze me that a company can spend thousands, hundreds of thousands, even millions of dollars on redundancy, high availability, firewalls, disaster recovery plans, and even cyberthreat insurance, and yet the entire technical infrastructure of the organization is held up by a couple of unpatched, forgotten nameservers gathering mold in a closet somewhere. Often, this can be the case without a given company being aware of it, because they simply allow their (pick one) web host, registrar, ISP, data center, or some other vendor to handle the DNS for them, perhaps as part of a bundled offering, and they have absolutely no knowledge of the state of the DNS infrastructure deployed by that vendor.

Following on from that theme, perhaps the DNS infrastructure may be beyond solid: anycast deployments, DDoS mitigation, hot spares, uptime monitoring, and 24x7 NOC support; but the portfolio of domain registrations are managed haphazardly or on an ad hoc basis. The smooth running underpinning of the organization is ripe for disruption by an unintentional domain expiry or a domain registration getting "slammed".

Truth be told, I am not a DNS expert per se, unless you use Neils Bohr's definition of an expert as "somebody who has made all possible mistakes within a very narrow field".

What I am is somebody who came up the DevOps side and then wound up running a business in the DNS and domain space for nearly 20 years. In that time, I've been dealing with all manner of use cases and customer profiles, and I've seen almost every DNS and domain-related failure condition imaginable.

Who this book is for

Your time will be well spent in reading this book if the following is true:

You are responsible for at least one mission-critical domain that must be online 24x7x365, or you are part of a team that manages large groups of domains, in the hundreds, thousands, or above, on behalf of your company or on behalf of your downstream users.

Your responsibilities include maintaining your organization's core DNS or DNS for its downstream users or clients, even if you accomplish these tasks by outsourcing DNS management to external providers. (This can include sysadmins, webmasters, IT consultants, and developers.)

You work for a technology company, or you are in tech, your core competency is something other than domains and DNS, but you or your company relies on functioning domains to carry on your business (which is almost everybody these days).

Here's a basic acid test: If your company's or perhaps one of your client's key domain names went offline for any reason, would you be one of the people who will be paged after hours, woken up in the middle of the night, grilled, yelled at, or possibly fired afterward? If the answer is "yes" or "maybe", this book is for you.

What this book covers

Chapter 1, The Domain Name Ecosystem, describes what parts of the naming system affect specific functions of your domains.

Chapter 2, Registries, Registrars and Whois, outlines the relationship between registrants and registries, and the database that houses your registrant data.

Chapter 3, Intellectual Property Issues, examines issues like which domains your organization should register and how IP-based domain disputes work.

Chapter 4, Communication Breakdowns, lists the various ways in which a key domain can go offline because of procedural and organizational mishaps, and also details common scams to be aware of.

Chapter 5, A Tale of Two Nameservers, looks at the difference between resolvers and authoritative nameservers and how they work together to answer DNS queries.

Chapter 6, DNS Queries in Action, looks at the anatomy of a DNS query and how queries actually get from a resolver to an authoritative nameserver and back to the client.

Chapter 7, Types and Uses of Common Resource Records, takes you through each DNS Resource Record (RR) type on an individual basis.

Chapter 8, Quasi-Record Types, goes through record types that don't actually exist within the DNS protocol but are frequently managed from within the DNS infrastructure.

Chapter 9, Common Nameserver Software, looks past the near ubiquitous BIND server and examines alternatives, such as PowerDNS, NSD, tinydns, and Knot DNS, with an eye toward nameserver diversity.

Chapter 10, Debugging Without Tears – DNS Diagnostic Tools, digs into debugging tools for DNS, both command-line and web-based.

Chapter 11, DNS Operations and Use Cases, delves into DNS use cases; we will cover all the things people often want their nameservers to do (even if it breaks protocol.)

Chapter 12, Nameserver Considerations, explains that as your portfolio of names under management grows, it becomes more difficult to change some of the deployment decisions made early on. With this in mind, we want to try to create a sensible approach from the outset.

Chapter 13, Securing Your Domains and DNS, covers securing your naming infrastructure, including DNSSEC.

Chapter 14, DNS and DDoS Attacks, looks at DDoS mitigation considerations.

Chapter 15, IPv6 Considerations, is a short but sweet chapter where we look at IPv6 considerations and how they relate to DNS.

To get the most out of this book

This book is not about how to learn the basics of operating nameservers. It is assumed that the reader already has working knowledge of at least one nameserver daemon or knows how to use an external vendor or system to manage zone data.

The book sets out to build on previous works in the field and is meant to fill what I perceived to be a vacuum that starts somewhere after "everything you need to know about running a nameserver" and runs up to "the byzantine and arcane labyrinths of domain policy".

In the former case, when in the case of BIND servers, there are standard must-reads, such as Paul Albitz and Cricket Liu's DNS and Bind (O'Reilly Media) and Ron Aitchison's Pro DNS & Bind 10 (Apress), or the exhaustive look at bind alternatives found in Jan-Piet Mens Alternative DNS Servers (UIT Cambridge).

On the domain policy side, there hasn't really been anything since Rony and Rony's The Domain Name Handbook (2000, Publishers Group West), exhaustive in its day but never updated, and nothing has really appeared to build on it. Milton Mueller's Ruling the Root (MIT Press) should be mentioned as it also endeavors to bridge a gap, in that case between an understanding of the technology and the economic and political drivers that shape the landscape within which the DNS is deployed.

It is also assumed that you are familiar with at least the technical basics of the DNS naming system. Worth mentioning here is that the Wikipedia pages about DNS are typically up to date, accurate, and accessible to the non-specialist.

Download the color images

We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: http://www.packtpub.com/sites/default/files/downloads/ManagingMissionCriticalDomainsandDNS_ColorImages.pdf.

Conventions used

There are a number of text conventions used throughout this book.

CodeInText: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "Mount the downloaded WebStorm-10*.dmg disk image file as another disk in your system."

A block of code is set as follows:

<OWNER-NAME> <TTL> <CLASS> <TYPE> <DATA>

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

# Example of a very simple Knot DNS configuration.

server: listen: 0.0.0.0@53 listen: ::@53 zone: - domain: example.com storage: /var/lib/knot/zones/ file: example.com.zone log: - target: syslog any: info

Any command-line input or output is written as follows:

$ dig -t mx easydns.com @dns1.easydns.com

Bold: Indicates a new term, an important word, or words that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: "Select System info from the Administration panel."

Warnings or important notes appear like this.

Tips and tricks appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: Email [email protected] and mention the book title in the subject of your message. If you have questions about any aspect of this book, please email us at [email protected].

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.

Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Reviews

Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!

For more information about Packt, please visit packtpub.com.

The Domain Name Ecosystem

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:

"Today we're going to teach you how to unplug a microphone cable and then roll it up. Yes, you are all sitting there thinking, I already know how to do that. We also used to think you arrived here already knowing that. Then, one day a few years back, I asked a first-year student to do it and he walked over to the wall over there... and proceeded to yank the guts right out of a brand new Neumann U87 microphone..."

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

Why domains are important

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.

The terms "hostname" and "subdomain" are often used interchangeably. Whether a particular label is a domain, hostname, subdomain, or superdomain depends on your reference point and its relation to a zone cut, which we'll explain later.

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

InFigure 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.comis 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 nonexistenttop-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.comDomain Name: PACKTPUB.COMDomain ID: 97706392_DOMAIN_COM-VRSNRegistrar WHOIS Server: whois.easydns.comRegistrar URL: http://www.easydns.comUpdated Date: 2015-09-15T21:46:16ZCreation Date: 2003-05-09T14:34:02ZRegistrar Registration Expiration Date: 2024-05-09T14:34:02ZRegistrar: easyDNS Technologies, Inc.Registrar IANA ID: 469Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibitedDomain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibitedRegistry Registrant ID:Registrant Name: Domain ManagerRegistrant Organization: Packt PublishingRegistrant Street: 2nd Floor Livery Place, 35 Livery StreetRegistrant City: BirminghamRegistrant State/Province: West MidlandsRegistrant Postal Code: B3 2PBRegistrant Country: GBRegistrant Phone: +44.1212656484Registrant Phone Ext:Registrant Fax:Registrant Email: [email protected] Admin ID:Admin Name: Domain ManagerAdmin Organization: Packt PublishingAdmin Street: 2nd Floor Livery Place, 35 Livery StreetAdmin City: BirminghamAdmin State/Province: West MidlandsAdmin Postal Code: B3 2PBAdmin Country: GBAdmin Phone: +44.1212656484Admin Phone Ext:Admin Fax:Admin Fax Ext:Admin Email: [email protected] Tech ID:Tech Name: Domain ManagerTech Organization: Packt PublishingTech Street: 2nd Floor Livery Place, 35 Livery StreetTech City: BirminghamTech State/Province: West MidlandsTech Postal Code: B3 2PBTech Country: GBTech Phone: +44.1212656484Tech Fax:Tech Fax Ext:Tech Email: [email protected] Server: DNS3.EASYDNS.ORGName Server: DNS1.EASYDNS.COMName Server: DNS2.EASYDNS.NETName Server: DNS4.EASYDNS.INFODNSSEC: unsignedRegistrar Abuse Contact Email: [email protected] 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.NETRegistry Domain ID: 1853290837_DOMAIN_NET-VRSNRegistrar WHOIS Server: whois.easydns.comRegistrar URL: http://www.easydns.comUpdated Date: 2018-04-04T07:47:36ZCreation Date: 2014-04-03T21:32:39ZRegistry Expiry Date: 2019-04-03T21:32:39ZRegistrar: 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 no

xistent 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 thi

The entity the domain was purchased from on the aftermarket

whos

e 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 theultimate 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]. 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

Tausende von E-Books und Hörbücher

Ihre Zahl wächst ständig und Sie haben eine Fixpreisgarantie.

Sie haben über uns geschrieben:

Managing Mission - Critical Domains and DNS E-Book

Mark E. Jeftovic

Managing Mission-Critical Domains and DNS

Why subscribe?

PacktPub.com

Contributors

About the author

Packt is searching for authors like you

Table of Contents

Preface

Who this book is for

What this book covers

To get the most out of this book

Download the color images

Conventions used

Get in touch

Reviews

The Domain Name Ecosystem

Why domains are important

Domain names 101

Anatomy of a domain name

Registry details

Registrar WHOIS server

Expiry date

The registrant contact set

The administrative contact set

Use a domain you control

Use a different domain than the name in the record

Use an exploder

Use a unique address

Alternatively, use canaries

The tech contact set

The billing contact set

DNS details

Status

Status flags set by the registry

Ok

inactive

autoRenewPeriod

pendingTransfer

redemptionPeriod

pendingDelete

Status Flags set by the Registrar

clientHold

clientDeleteProhibited

clientTransferProhibited

clientUpdateProhibited

clientRenewProhibited

Understanding the domain name expiry cycle