Managing Mission-Critical Domains and DNS

Transcription

www.it-ebooks.info
Managing Mission-Critical
Domains and DNS
Mark Jeftovic
www.it-ebooks.info
Managing Mission-Critical Domains and DNS
by Mark Jeftovic
Copyright © 2010 Mark Jeftovic. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.
O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are
also available for most titles (http://safaribooksonline.com). For more information, contact our corporate/
institutional sales department: 800-998-9938 or [email protected].
Editor: Brian Anderson
Production Editor: FIX ME!
Copyeditor: FIX! ME!
Proofreader: FIX ME!
January -4712:
Indexer: FIX! ME!
Cover Designer: Karen Montgomery
Interior Designer: David Futato
Illustrator: Rebecca Demarest
First Edition
Revision History for the First Edition:
2014-12-16:
Early release revision 1
2015-05-04:
Early release revision 2
See http://oreilly.com/catalog/errata.csp?isbn=0636920034148 for release details.
Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly
Media, Inc. !!FILL THIS IN!! and related trade dress are trademarks of O’Reilly Media, Inc.
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as
trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark
claim, the designations have been printed in caps or initial caps.
While every precaution has been taken in the preparation of this book, the publisher and authors assume
no responsibility for errors or omissions, or for damages resulting from the use of the information contained
herein.
ISBN: 063-6-920-03414-8
[?]
www.it-ebooks.info
Table of Contents
Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
1. Domain Names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Why Domains Are Important
Anatomy of a Domain Name
Registry Details
Registrar Whois Server
Expiry Date
Registrant Contact Set
The Admin Contact Set
The Tech Contact Set
Billing Contact Set
DNS Details
Status
1_01 Wrap Up
1
1
3
4
5
6
7
8
8
8
8
10
2. Registries, Registrars & TLD Providers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Understanding Registries
The Original Top Level Domains
Generic TLDs
Country Code TLDs (ccTLDs)
IDN TLDs
Chartered TLDs
New Top Level Domains
Private Namespaces
Alternative Namespaces
Registrars
The Extensible Provisioning Protocol
NetSol Monopoly
12
12
12
13
13
14
15
16
16
17
17
17
iii
www.it-ebooks.info
ICANN and Competition
TLD Providers
Why Do I Need to Know All This?
18
18
18
3. Whois. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Thin vs Thick Whois
Whois Privacy
How to Tell if Whois Privacy is Enabled
Why you should always use “Whois” privacy
Why you should never use “Whois” privacy
Where is Whois going? Registration Data Directory Service (RDDS)
21
25
27
27
28
28
4. Intellectual Property & Legal Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Which Domains Should Your Organization Register?
Asserting Your Trademarks Withing the New gTLD Landscape
Sunrise
Landrush
Premium Auction
The Trademark Clearing House
Typo domains
Dispute Mechanisms
Uniform Domain Name Dispute Resolution Policy (UDRP)
How the UDRP Works
Transfer Dispute Resolution Procedure (TDRP)
Uniform Rapid Suspension System (URS)
What if Somebody is infringing on your marks or squatting on your name?
What If Somebody Tries to Take Your Domains?
What Happens When Somebody Initiates a UDRP Against Your Domain
Domain Aftermarket
Account Push
Registrar Transfer
Domain Aftermarket and Backorder Services
Backordering and Registrar Expiry Frontrunning
Escrow Services
Other Legal Issues
Chapter Summary
29
32
32
32
33
33
35
38
38
38
39
41
42
42
42
43
43
44
44
44
45
46
49
5. Managing Your Portfolio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Multi-Domain Architectures
Organizational Best Practices
The Domain Portfolio Audit
Managing Customer Domains
iv
|
Table of Contents
www.it-ebooks.info
51
51
51
51
Authentication
Security
Scaling
Transferring Domain Names
Change of Registrant
Nameserver Redelegations
Registrar Transfer
Registrar Transfer and Nameserver Redelegation
51
51
51
51
52
52
54
54
6. Common Pitfalls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Domain Slamming
Phishing
Unintentional Expiry
The Domain Expiry Cycle
Domain Scams
The “Foreign Infringer” Scam
Aftermarket Scams
ICANN Suspensions
Whois Accuracy Program
Incorrect or Bad Whois Reports
DNS Failures
55
55
55
55
55
56
56
57
57
57
57
7. Types of Nameservers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Root Nameservers
Resolvers or Recursors
Authoritative Nameservers
Primary Nameserver
Secondary Nameservers
Other Nameserver Types
Forwarders
59
65
67
67
69
70
70
8. DNS Queries In Action. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Exceptions to UDP queries. When TCP is required.
Zone Transfers Happen Over TCP
Large Responses, EDNS and DDOS Mitigation (Oh My!)
Anatomy of a DNS Query: How Nameserver Selection Actually Works
Summing Up
72
73
73
74
75
9. Types and Uses of Common Resource Records (and some not-so-common ones…). . . 77
A / Hostnames
CNAME/ Alias
The MX Record
77
78
81
Table of Contents
www.it-ebooks.info
|
v
A couple of special case MX-isms:
SOA / Start of Authority
Originating Nameserver
Point of Contact
Serial
The Refresh interval
The Retry interval
The Expire Interval
The Minimum (a.k.a Time To Live)
NS / Nameserver
TXT / Text Records
SPF Records
SRV
NAPTR
DNAME
PTR
IPv6
AAAA
A6
KEY
CERT
DNSSEC Specific RR Types
Uncommon / Obscure RR Types
RP
AFSDB
LOC
vi
| Table of Contents
www.it-ebooks.info
82
83
83
84
84
85
85
85
86
87
87
88
88
89
91
91
93
93
93
93
93
93
93
94
94
94
Preface
This book is a work in progress – new chapters will be added as they are written. We
welcome feedback – if you spot any errors or would like to suggest improvements, please
email the author at [email protected].
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, or visit a web page, type or receive an instant message, text
or SMS, place a VOIP call (or skype), or 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 to? 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 miliseconds (less than 1/4th
the time it takes you to blink), and typically involve at a minimum 3 or 4 disparate servers
around the globe - none of which 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 Information Technology. Similarly, domain names (the logical nam‐
ing entities which anchor DNS lookups) are often the most profoundly misunderstood
facets of IT as well, even by otherwise advanced technical personel.
For some reason, DNS and domain names seem to be a “blind spot” in many organi‐
zations’ 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”.
vii
www.it-ebooks.info
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 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 times 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 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 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.
True Story
Once, several years ago I found myself meeting with the technical
director of a small Caribbean country code - ccTLD) We were meet‐
ing in the office building of the local government telecom that ran the
namespace. He asked, somewhat hesitantly, if could take a few mi‐
nutes to help them out with some DNS issues they were having with‐
in the rootzone for their ccTLD. I agreed. He stood up, said “come
with me please”, and I, expecting to be bundled off to a datacenter
somewhere, followed behind.
We went into the elevator, up a floor, exited and walked through a
small cafeteria/kitchenette. He opened what looked like an officesupply closet and gestured to what appeared to be some kind of i486
tower computer under a desk. The root prompt was present on the
monitor.
“This is ns1.” He said, as he typed a few keystrokes (“vi /etc/
named.conf ”) “Ns2 is down in the basement.” After I got over my
shock I took a look, mentally noting that “Right now I am handediting the nameserver config of a country-level root server….” made a few changes for them, dutifully saved the file…and at his
behest, restarted bind.
Who Should Read This Book
Your time would be well spent in reading this book if:
• You are responsible for at least one mission critical domain which must be online
24x7x365, or are part of a team that manages large groups of domains (in the hun‐
viii
| Preface
www.it-ebooks.info
dreds, or thousands and 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 it’s downstream users or clients, and this even if you accomplish these tasks by
outsourcing DNS management to external providers.
(This can include: sysadmins, webmasters, IT consultants, and developers.)
The basic acid test is this: if your company’s or perhaps one of your client’s key domain
names went dark, will you be one of the people who is going to, paged after hours, woken
up in the middle of the night, grilled, yelled at or possibly fired afterwards? If the answer
is “yes” or “maybe” then this book is for you.
Why I Wrote This Book
I wrote this book because (at the risk of belaboring the point) all too often I come across
organizations and businesses who understand IT, who are fully eficacious within their
own core competence but they don’t possess an understanding of the principles outlined
in this book.
Either the DNS/nameserver solution is ad-hoc or inadequate to the gravity of the task
or else the back office lacks any procedural framework for handling the administrative
overview of the organization’s key domain assets.
I see definciencies on one side or the other in many, otherwise highly savvy organiza‐
tions. In extreme cases there is lack on both sides.
The separation of DNS ops from domain portfolio administration has always been in
my mind an artificial one, but it’s a divide that occurs in many places. Even when the
DNS is operated by extremely competent DNS gurus, there can be an institutional un‐
awareness of what is happening on the domain administration side of the fence that can
lead to catastrophic disconnects.
This book aims to remove that artificial distinction and to give you a solid framework
on effectively managing your organization’s naming architecture from the administra‐
tive / policy side right through to the techncinal DNS and nameserver implementations.
A Word On The “Domain Name” and “DNS Operations”
Environments Today
On the domain name side of things, the big picture these days (late 2014 thru mid 2015
and beyond) is the advent of the new Top Level Domains (TLDs) being added to the
internet root; as well as numerous policy additions from ICANN (the body that oversees
Preface
www.it-ebooks.info
|
ix
the naming space) - some of which (as we’ll see later) have actual operational impact
on your production domains.
There are so many new TLDs coming out, I can’t even keep track of them. This changes
the way organizations need to approach their Intellectual Property (IP) requirements
with regard to domain names. In the past some entities would attempt to “defend their
marks” in all available Top Level Domains. That is effectively impossible now.
The forthcoming transition of operating the rootzone (.) from the IANA to an inter‐
national body (at the time of writing to be named later) brings to light questions of
international and cross-border governance; issues which have been coming to the fore
with increasing frequency and that necessitate a serious forum to discuss it.
Even ICANN’s new (2014) Whois Accuracy Program may sound like something only
domainer policy wonks would be interested in, but it can operationally affect your
organization because being unaware of this policy and not abiding by it can cause a fully
functional (and possibly even an extremely mission critical) domain name to simply
cease functioning and disappear from the internet.
The DNS ops environment today, once you get to know it, is actually pretty interesting.
While the bind nameserver is by far the most popular nameserver in use today, there
are some strong alternatives: powerdns, and nsd, and some emerging contenders such
as knotdns.
There is anycast DNS (think of it as a Content Delivery Network or “CDN” for your
DNS), geoDNS, load balancing and of course, the DNSSEC extensions.
While this book’s focus on the DNS side is on operating authoritative nameservers, for
completeness we’ll touch on resolvers, because there have been many developments in
the public resolver space over the last few years as well.
Navigating This Book
Over on DNS operations we look at the nuts and bolts of operating nameservers and
making sure the lights stay on for all you and your downstream users’ domains.
This book is divided roughly into two sections, domains and DNS. Think of Part I as
external forces that act on your domains: , registries, registrars, oversight bodies, poli‐
cies, etc. Part II shifts to the internal: operating your own infrastructure, running your
DNS. Even if you outsource some or all of these components to external vendors, this
section will help you design that intelligently. It will also be sprinkled with liberal doses
from the “Learn From My Mistakes” file.
Part I: Domains
This half of the book discusses the various aspects of managing domain names and
portfolios of domain names as distinct from running the actual DNS for them.
x
|
Preface
www.it-ebooks.info
• Chapter 1 breaks out the anatomy of a domain name (there’s more to it than you
might think!)
• Chapter 2 moves into oversight bodies who administer the various naming and
numbering schemas that your domain names have to operate within.
• Chapter 3 looks at Registrars and Registries and what the ramifications are of having
your domains with one or another Registrar and under specific Registries. We look
at the various Top Level Domains (from generics, to chartered, country codes and
now the new TLDs) and we even get into the dark recesses of the namescape with
darknets, alternate namespaces and the emergent attempts at decentralized P2P
DNS systems.
• Yes, Chapter 4 is an entire chapter focused on “whois”, whois servers, whois privacy
and the myriad ways domain registrants can utterly screw themselves if they get
certain aspects of this wrong.
• Chapters 5 and 6 look at Intellectual Property issues and the domain aftermarket.
Why would you care? Well even of you are a systems or engineer type, you will
probably hear about IP issues regarding domains you manage as an initial pointof-contact. And after somebody in your organization messes up and you lose one
of your domain names (or one belonging to a customer), you’ll need a working
knowledge of the domain aftermarket when it comes time to go out there and buy
it back.
• Finally we round out Part 1 with Chapters 7 and 8 where we look at overall man‐
agement of a domain portfolio, including common tasks and best practices, fol‐
lowed by a chapter on common pitfalls.
This segues nicely into Part II: Managing DNS
Managing DNS is something your organization needs to master, even if you outsource
your actual DNS. Whether you do it in-house, use a managed DNS provider, or as is
becoming more common these days, some combination of both, Part II’s goal is to equip
you with the knowledge to be able to manage your vendors and your in-house deploy‐
ments without ever experiencing DNS downtime, or if you do, knowing the diagnostics
and remedies to make any outage as brief as possible.
• In Chapters 9 & 10 we look at why DNS is important (short answer: because nothing
on the internet happens without it) and we break down the anatomy of a DNS query.
It may sound basic but it is frequently misunderstood.
• Chapter 11 looks at types and common uses of the various Resource Records (RR’s)
and that is followed by Chapter 12 which examines what I call “pseudo-record
types”. This is basically a record type that doesn’t really exist in strict DNS protocol
terms but conveys meaning to most end-users (example: “web forwarder” - tech‐
Preface
www.it-ebooks.info
|
xi
nically there is no “web forwarding” DNS record type, it’s typically an A record that
points at a URL forwarding server).
From here we go into the nameservers themselves, starting with
• Chapter 13: the three broad classifications of nameservers: root servers, authorita‐
tive nameservers and resolvers. We spend most of our time with authoritative
nameservers but you need to understand where all three fit into the DNS lookup
process and how they interact.
• Chapter 14 drills down to common nameserver software such as the near ubiqui‐
tous bind software, other popular nameservers like powerdns, nsd, tinydns and
emerging servers such as knotdns. We also take a look at resolver specific daemons
like dnscurve.
• Chapters 15 and 16 get into diagnostic tools, both command line and web based
and then DNS frameworks & Libraries that can be used in application development.
• Chapter 17 we delve into DNS use cases where cover all the things people often
want their nameservers to do (even if it breaks the protocol ;)
• Chapter 18, love it or hate it, DNSSEC, followed by Chapter 19 where we look at
IPv6 considerations as they relate to DNS.
• Finally in Chapter 19 we put it all together into creating and implementing your
DNS strategy, including my magic bullet formula to absolutely guarantee 100%
DNS availability no-matter-what.
• We end up Part II with Chapter 20 on the evolution of DNS where we look at
decentralized roots, darknets and some wild hypberbolic “what comes next?” type
speculations.
I’ve also added three appendices to the book that you can use to implement the ideas
contained herein:
• Appendix A: The Domain Portfolio Audit
• Appendix B: The Domain Registrar Checklist
• Appendix C: The DNS Provider Checklist
You’re probably not going to read this book in order, but you should probably skim
through it and be familiar with the big concepts. There is an old adage “experience is
something you don’t get until just after you need it” and this is acutely germane when
it comes to managing domains and DNS.
Ideally you can read this book and have the experience before you need it.
xii
|
Preface
www.it-ebooks.info
Other Books In the Field
This book seeks to build on previous works in the field and is meant to fill what I
perceived to be a vaccuum 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, whether it be specifically bind servers there are standard must-reads
such as Cricket Liu’s “DNS & 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).
In the latter case, 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 up‐
dated and nothing has really appeared to build on it.
(This is the bridge I hope to build in this book, to show how DNS operations intersects
with domain policy in a very real way, especially when operating at scale, managing
portfolios of thousands of domains and above.)
Online Resources
Conventions Used in This Book
The following typographical conventions are used in this book:
Italic
Indicates new terms, URLs, email addresses, filenames, and file extensions.
Constant width
Used for program listings, as well as within paragraphs to refer to program elements
such as variable or function names, databases, data types, environment variables,
statements, and keywords.
Constant width bold
Shows commands or other text that should be typed literally by the user.
Constant width italic
Shows text that should be replaced with user-supplied values or by values deter‐
mined by context.
This icon signifies a tip, suggestion, or general note.
Preface
www.it-ebooks.info
|
xiii
This icon indicates a warning or caution.
Using Code Examples
Supplemental material (code examples, exercises, etc.) is available for download at
https://github.com/oreillymedia/title_title.
This book is here to help you get your job done. In general, if example code is offered
with this book, you may use it in your programs and documentation. You do not need
to contact us for permission unless you’re reproducing a significant portion of the code.
For example, writing a program that uses several chunks of code from this book does
not require permission. Selling or distributing a CD-ROM of examples from O’Reilly
books does require permission. Answering a question by citing this book and quoting
example code does not require permission. Incorporating a significant amount of ex‐
ample code from this book into your product’s documentation does require permission.
We appreciate, but do not require, attribution. An attribution usually includes the title,
author, publisher, and ISBN. For example: “Book Title by Some Author (O’Reilly).
Copyright 2012 Some Copyright Holder, 978-0-596-xxxx-x.”
If you feel your use of code examples falls outside fair use or the permission given above,
feel free to contact us at [email protected].
Safari® Books Online
Safari Books Online is an on-demand digital library that
delivers expert content in both book and video form from
the world’s leading authors in technology and business.
Technology professionals, software developers, web designers, and business and crea‐
tive professionals use Safari Books Online as their primary resource for research, prob‐
lem solving, learning, and certification training.
Safari Books Online offers a range of product mixes and pricing programs for organi‐
zations, government agencies, and individuals. Subscribers have access to thousands of
books, training videos, and prepublication manuscripts in one fully searchable database
from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Pro‐
fessional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John
Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT
Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technol‐
xiv
| Preface
www.it-ebooks.info
ogy, and dozens more. For more information about Safari Books Online, please visit us
online.
How to Contact Us
Please address comments and questions concerning this book to the publisher:
O’Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
800-998-9938 (in the United States or Canada)
707-829-0515 (international or local)
707-829-0104 (fax)
We have a web page for this book, where we list errata, examples, and any additional
information. You can access this page at http://www.oreilly.com/catalog/<catalog page>.
To comment or ask technical questions about this book, send email to bookques
[email protected].
For more information about our books, courses, conferences, and news, see our website
at http://www.oreilly.com.
Find us on Facebook: http://facebook.com/oreilly
Follow us on Twitter: http://twitter.com/oreillymedia
Watch us on YouTube: http://www.youtube.com/oreillymedia
Acknowledgments
Preface
www.it-ebooks.info
|
xv
www.it-ebooks.info
CHAPTER 1
Domain Names
Why Domains Are Important
You probably already know that a domain name is simply an alphanumeric label that
is mapped - via the Domain Name Service (DNS) to other data - like an IP address.
Without DNS or hostnames or domain names1, we would be left having to reference all
endpoints of our interenet connections by their raw IP addresses.
While some people (mostly cranks) occasionally argue that this wouldn’t be a Bad
Thing(tm), the fact remains that this name-to-number (and vice versa) translation is
necessary because it adds a level of abstraction required to track changes in our internet
endpoints and destinations.
Without hostname and domain name labels, and a universal mechanism to map be‐
tween the two, all applications would have to somehow acquire end-to-end knowledge
of all it’s peers.
The easiest way to gain an understanding of how the logical components of “a domain
name” come together is to look at what’s called a “whois record”2 for any given domain
name.
1. The terms “hostname” and “subdomain” are often used interchangebly. Whether a particular label is a domain,
sub-domain or super-domain depends on your reference point and it’s relation to a zone cut which we’ll
explain later
2. 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. Chapter 4 examines “The Whois” in excrutiating
detail.
1
www.it-ebooks.info
a note on examples and example.com
example.com is an example of a domain name. It (and several oth‐
ers) are specifically reserved by IANA to serve the purpose of pro‐
viding 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 possi‐
ble, in cases where I need to show some specific element not present
within example.com I’ll use oreilly.com or some other relevant do‐
main.
$ whois oreilly.com
Domain Name: OREILLY.COM
Registry Domain ID: 2932677_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.godaddy.com
Registrar URL: http://www.godaddy.com
Update Date: 2014-04-28 18:07:56
Creation Date: 1997-05-26 23:00:00
Registrar Registration Expiration Date: 2015-05-25 23:00:00
Registrar: GoDaddy.com, LLC
Registrar IANA ID: 146
Registrar Abuse Contact Email: [email protected]
Registrar Abuse Contact Phone: +1.480-624-2505
Domain Status: clientTransferProhibited
Domain Status: clientUpdateProhibited
Domain Status: clientRenewProhibited
Domain Status: clientDeleteProhibited
Registry Registrant ID:
Registrant Name: O'Reilly Media, Inc.
Registrant Organization: O'Reilly Media, Inc.
Registrant Street: 1005 Gravenstein Highway North
Registrant City: Sebastopol
Registrant State/Province: California
Registrant Postal Code: 95472
Registrant Country: United States
Registrant Phone: +1.7078277000
Registrant Phone Ext:
Registrant Fax: +1.7078290104
Registrant Fax Ext:
Registrant Email: [email protected]
Registry Admin ID:
Admin Name: Admin Contact
Admin Organization: O'Reilly Media, Inc.
Admin Street: 1005 Gravenstein Highway North
Admin City: Sebastopol
Admin State/Province: California
Admin Postal Code: 95472
Admin Country: United States
Admin Phone: +1.7078277000
Admin Phone Ext:
2
|
Chapter 1: Domain Names
www.it-ebooks.info
Admin Fax: +1.7078290104
Admin Fax Ext:
Admin Email: [email protected]
Tech Name: Tech Contact
Tech Organization: O'Reilly Media, Inc.
Tech Street: 1005 Gravenstein Highway North
Tech City: Sebastopol
Tech State/Province: California
Tech Postal Code: 95472
Tech Country: United States
Tech Phone: +1.7078277000
Tech Phone Ext:
Tech Fax: +1.7078290104
Tech Fax Ext:
Tech Email: [email protected]
Name Server: NSAUTHA.OREILLY.COM
Name Server: NSAUTHB.OREILLY.COM
DNSSEC: unsigned
Whois record formats differ between Top Level Domains (TLDs) - and we’ll discuss
some of the key differences in Chapter 4, but they all share similar characteristics which
can help us dissect the various “moving parts” of a domain:
• 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:
• when the domain was registered
• when the associated record was last modified
• Registrar’s name, URL & abuse contact
The Registry details also contain the following elements which require a more in-depth
explanation:
www.it-ebooks.info
|
3
Registrar Whois Server
This is a server which can be queried directly for a given whois record for a domain
using the -h switch from the command line:
whois -h whois.godaddy.com oreilly.com
There are a few reasons you may need to do this. In the wild-west days of the internet,
a common prank (which still works) was to create “nameserver glue records”3 for pop‐
ular domains that could convey messages to those querying the popular domain, for
example:
$ whois microsoft.com
MICROSOFT.COM.ARE.GODDAMN.PIGFUCKERS.NET.NS-NOT-IN-SERVICE.COM
MICROSOFT.COM.CAN.GO.FUCK.ITSELF.AT.SECZY.COM
MICROSOFT.COM.EENGURRA.COM
MICROSOFT.COM.FILLS.ME.WITH.BELLIGERENCE.NET
MICROSOFT.COM.HAS.A.PRESENT.COMING.FROM.HUGHESMISSILES.COM
MICROSOFT.COM.IS.A.MESS.TIMPORTER.CO.UK
MICROSOFT.COM.IS.A.STEAMING.HEAP.OF.FUCKING-BULLSHIT.NET
MICROSOFT.COM.IS.HOSTED.ON.PROFITHOSTING.NET
MICROSOFT.COM.IS.IN.BED.WITH.CURTYV.COM
MICROSOFT.COM.IS.NOT.HOSTED.BY.ACTIVEDOMAINDNS.NET
MICROSOFT.COM.IS.NOT.YEPPA.ORG
MICROSOFT.COM.LIVES.AT.SHAUNEWING.COM
MICROSOFT.COM.LOVES.ME.KOSMAL.NET
MICROSOFT.COM.MAKES.RICKARD.DRINK.SAMBUCA.0800CARRENTAL.COM
MICROSOFT.COM.MATCHES.THIS.STRING.AT.KEYSIGNERS.COM
MICROSOFT.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM
MICROSOFT.COM.RAWKZ.MUH.WERLD.MENTALFLOSS.CA
MICROSOFT.COM.SHOULD.GIVE.UP.BECAUSE.LINUXISGOD.COM
MICROSOFT.COM.SOFTWARE.IS.NOT.USED.AT.REG.RU
MICROSOFT.COM.WAREZ.AT.TOPLIST.GULLI.COM
MICROSOFT.COM.WILL.BE.BEATEN.WITH.MY.SPANNER.NET
MICROSOFT.COM.WILL.BE.SLAPPED.IN.THE.FACE.BY.MY.BLUE.VEINED.SPANNER.NET
MICROSOFT.COM.ZZZ.IS.0WNED.AND.HAX0RED.BY.SUB7.NET
MICROSOFT.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM
MICROSOFT.COM.ZZZZZZ.MORE.DETAILS.AT.WWW.BEYONDWHOIS.COM
MICROSOFT.COM.ZZZZZZZZZZZZZZZZZZ.IM.ELITE.WANNABE.TOO.WWW.PLUS613.NET
MICROSOFT.COM.ZZZZZZZZZZZZZZZZZZZ.GET.ONE.MILLION.DOLLARS.AT.WWW.UNIMUNDI.COM
MICROSOFT.COM.ZZZZZZZZZZZZZZZZZZZZZZ.IS.A.GREAT.COMPANY.ITREBAL.COM
MICROSOFT.COM
You can break through this layer of noise and extract the actual whois record by using
the -h switch. You can find out which registrar you require by prefixing your query with
an =; so
3. see Chapter 2-02 for more on nameserver glue recs
4
|
www.it-ebooks.info
$ whois =microsoft.com
[snip]
Domain Name: MICROSOFT.COM
Registrar: MARKMONITOR INC.
Whois Server: whois.markmonitor.com
Referral URL: http://www.markmonitor.com
Name Server: NS1.MSFT.NET
Status: clientDeleteProhibited
Status: clientTransferProhibited
Status: clientUpdateProhibited
Status: serverDeleteProhibited
Status: serverTransferProhibited
Status: serverUpdateProhibited
Updated Date: 09-aug-2011
Creation Date: 02-may-1991
Expiration Date: 03-may-2021
$ whois -h whois.markmonitor.com microsoft.com
Further, with the flood of New Top Level Domains (“new TLD’s”) now coming out, there
are sometimes cases where a new TLD’s whois server has not yet been added to *whoisservers.net*4 yet, which means you will need the -h switch to be able to pull a whois
record.
For example, the hot new TLD everybody wants a piece of is .BLARGH, but there is no
record for blargh.whois-servers.net, you would then try:
$ whois -h whois.nic.blargh example.blargh
Expiry Date
At first glance the field that contains a domain’s expiry date may seem pretty selfexplanatory. It’s the date after which the domain expires at the Registry, right? Mostly.
Sort of.
There are a couple of things to know about this date.
The first thing to know is that when a domain expires on a certain date, that does not
mean that the domain will become immediately available to re-register the following
day (or following minute). In most TLDs, if a Registrant neglects to renew a domain
name and it expires, it enters into a process often referred to as The Expiry Cycle. For
4. whois-servers.net is a zone operated by Centergate Research which endeavors to map Top Level Domains to
their corresponding whois servers.
www.it-ebooks.info
|
5
a detailed examination of the domain expiry cycle, see “The Expiry Cycle” section later
in Part I.
The second thing to know about this field is that the listed Expiry Date may not actually
be the date in which the domain, absent the Registrant explicitly renewing, will expire.
The reason for this is because of a mechanism many Registries employ called “autorenewal”. It means what you think it would: when the domain hits its expiry date, the
Registry automatically renews the domain on behalf of the Registrar, bills the Registrar
their wholesale cost of renewal, and that sets the Expiry Date ahead one year.
If the Registrant then does not renew the domain with the Registrar, then the Registrar
will often “suspend” the domain by taking it’s nameserver delegation out of the TLD
rootservers, and commence an expiry grace period; after which it will issue a “delete
domain” command to the Registry. If that happens the Registry then refunds the Reg‐
istrar the renewal fee it charged when it executed the auto-renew, and resets the expiry
date back to the original one before the auto-renew happened. This occurance coincides
with the domain transitioning into a “RedemptionPeriod” state (again, we delve way
too far into this in the Domain Expiry Cycle section because if you find yourself man‐
aging a lot of domain names, you need to understand this cycle. At some point in time,
somebody is going to let some domain slip through that they are going to want to
somehow claw back).
Registrant Contact Set
It cannot be over-emphasized 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 (often with catastrophic results). Any other mistake one may make when it comes
to administration of the registration details of one’s domain portfolio is fixable. Some‐
times this one isn’t.
The listed Registrant for a domain MUST be the legal name of your business, organi‐
zation or the ultimate user of the domain. Too often it is one of the following:
• An employee of the organization (in his own name)
• An outside consultant
• “Fake” data of a non-existant 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 - this happens fre‐
quently.
6
|
www.it-ebooks.info
It’s not completely clear whether domain names themselves are actual “property” or
simply convey rights. There have been arguments and legal decisions going both ways
and in differing jurisdictions. Suffice it to say for our purposes, owner or rightsholder,
whomever or whatever is listed as a domain’s “Registrant” is The Ultimate Authority
over what happens to that domain.
It means 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 screwed.
The Admin 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 registration), there were only two contact sets:
Administrative 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 an exploder
Have that email address explode out to multiple personal 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 host‐
master@ - 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: [email protected],
[email protected] - you can then filter and track each domain
individually.
www.it-ebooks.info
|
7
The Tech Contact Set
This contact set typically exerts no operational or administrative control over the do‐
main, 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.
Billing Contact Set
Historically this set was created to provide a separate point-of-contact for billing issues
related to a domain name, and a boon for domain slammers (see 1_07). Again, this
contact provides no operational control over the domain and is customarily 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 it’s DNSSEC
status.
The nameserver delegation are the authoritative nameservers for the domain. We out‐
line the types of nameservers in 2_02 (“Types of Nameservers”), but suffice it to say that
these nameservers are the ones that will receive and respond to all DNS queries for the
subject domain name. Most of Part II of this book is concerned with operating these
types of nameservers, doing so at significant scale (100’s of thousands of domains, mil‐
lions or billions of queries), achieving uninterupted uptime, all the while mimimizing
mental anguish, sysadmin angst or “blood in the streets” style DNS outages.
Status
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.5
Status Flags set by the Registry
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 more susceptable to unauthorized hijackings or domain slam‐
ming. (In other words, when I see a domain with this status it’s somewhat of a “red
flag”: something that needs to be rectified.)
5. ICANN maintains a complete list of EPP status codes and meanings at https://www.icann.org/epp
8
|
www.it-ebooks.info
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 which intercept your DNS and output 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 Domain Expiry Cycle”).
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. Re‐
demptionPeriod is a 30-day grace period during which it can still be renewed (“re‐
deemed”) by your Registrar.
pendingDelete
The redemptionPeriod has ended and the domain will be completely deleted from
the Registry within a few days (usually 5). Once that happens, the domain comes
available for re-registration by interested parties. (If the domain has any marginal
value it will be re-registered within milliseconds. See “Dropcatching Services”).
Status Flags set by the Registrar
clientHold
The domain has had it’s nameserver delegation revoked and it will not resolve across
the internet. This can be the result of an unfulfilled Whois Accuracy Program ver‐
ification 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
thrwart inadvertant slamming attempts.
clientUpdateProhibited
Automatically reject any modifications or updates to the domain. Again, it is pru‐
dent 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 reinstate them,
provided the request is coming from an authorized party.
www.it-ebooks.info
|
9
clientRenewProhibited
The domain cannot be renewed in its current state. Contact your Registrar to find
out why.
1_01 Wrap Up
While the simplest explanation of a domain name may be " a unique name that identifies
an internet resource such as a website.6, in order to convey the full spectrum of inter‐
locking issues that govern and maintain them you need to examine the myriad data
entities, DNS hierachry and objects that comprise a typical “Whois Record” that de‐
scribe them.
Once you understand that there are multiple vectors that can impact the operation (or
failure) of a single domain name: registry, registrar, administrative, policy, technical and
nameservers, and that these forces can combine in different ways between multiple
domain names, one begins to appreciate the geometrical increase in complexity that
arises when domains aggregate into working groups, portfolios or user bases.
6. via Wikipedia http://en.wikipedia.org/wiki/Domain_name
10
|
www.it-ebooks.info
CHAPTER 2
Registries, Registrars & TLD Providers
Your domain names are subject to and impacted by, external and internal factors. In‐
ternal factors are the operation of the DNS and the management principles you apply
to your portfolio. External factors come from Registries under which your domains are
registered and the Oversight bodies that administer them. Those factors usually man‐
ifest on your portfolio via the the conduit of the Registrars for the given domains.
In order to effectively manage your portfolio, one must both be cognizant of, and un‐
derstand the influence of these external forces. In laying out the big picture of these
inescapable externalities, I couldn’t help but interject a certain amount of historical “how
this came to be” context.
A domain registry operates a “top level domain (TLD)” a.k.a “root” for a given name‐
space. .COM is a Top Level Domain. Your country has it’s own TLD (called a ccTLD),
mine is .CA for Canada.
Different TLDs have different Registry operators. Some Registry operators run more
than one TLD.
A Registry can operate under a “thick” model, in which the Registry operator provides
most or even all of the functionality at both the registry level and end-user registrant
level. In other words, a Registry may operate as its own Registrar, those who would like
to register domains in it would deal directly with the Registry itself.
These are most often country code TLDs. History shows that usually the progression
is from a thick registry model where the operator does everything to a “thin” model,
where the Registry accredits “Registrars” who then facilitate domain name registration
services to the end-users (The Registrants).
The “big three” generic TLDs: .COM/.NET & .ORG and ccTLD’s like .US and .CA began
as thick registries that have since transitioned to thin ones. This process is usually play‐
ing out somewhere in the world and if you manage a lot of different ccTLD domains,
11
www.it-ebooks.info
it’s good to be aware if it’s happening in any of them. For example, Switzerland (.CH) is
completing this transition in 2015. Some ccTLDs are hybrid models, operating a directto-registrant model from the registry while also allowing third-party Registrars to pro‐
vide registration services (.TO and .IO come to mind).
The Original Top Level Domains
Near the beginning, before “internet time” began (1992-ish) there were 7 main
TLDs .COM, .EDU, .INT, .GOV, .MIL, .NET, .ORG, and the special case .ARPA
In those days, each TLD had a purpose or charter, and some of them still do today. For
example, .INT is still for international bodies such as the Red Cross and WIPO; .MIL
is still for the US military and .GOV is still for the US Government.
Generic TLDs
While .COM, .NET and .ORG originally had charters (.COM was for commecial enti‐
ties, .NET for network infrastructure and .ORG for non-profit entities), those distinc‐
tions are largely blurred today and certainly not enforced in any meaningful way.
Today these three are the big, incumbant “generic TLDs” (gTLDs) because domains
under these namespaces are unrestricted and can be registered by any entity for any
reason.
There have been other TLDs over the years attempt to position as gTLDs, prior to the
advent of the New TLDs (see below) these have been Country Code TLDs (ccTLDs)
attempting to position themselves as gTLDs.
For example, .CO markets itself as “.CO = Company”, but the reality is .CO TLD exists
as the Country Code Top Level Domain for Columbia. .TV isn’t really a TLD about
television. It’s the country code for Tuvalu. WS touts itself as “.WS = Website”, but it’s
actually the ccTLD of Western Samoa. The list goes on1
1. Even my company operates web.to as a pseudo-TLD for “Toronto”, but it’s really the ccTLD for the Kingdom
of Tonga
12
|
Chapter 2: Registries, Registrars & TLD Providers
www.it-ebooks.info
Country Code TLDs (ccTLDs)
Every country or territory in the world that has it’s own ISO31662 designation has the
2-character version of that designation assigned as it’s country-code Top Level Domain
(ccTLD).
The ccTLDs have their delegations assigned via ICANN (see “Oversight Bodies” side‐
bar) but each one sets it’s own policies governing the registration of domains within
their respective ccTLDs.
Some, such as .CA, .CN and .US have local presence requirements: which means that
only citizens and entities native to Canada, China and the United States resepectively
are permitted to register domains within the TLD.
Others, as we’ve seen above, are wide open and may actively position their ccTLD as
something other than their geographical context.
IDN TLDs
Iternationalized Domain Names are domains that contain characters that are outside
the usual alpha-numeric character set. In other words, they contain characters with
accents or non-english entities.
Because labels within the DNS are encoded in ASCII, these types of entities must be
converted to an ASCII representation before they can be used within the DNS system.
This is facilitated by converting them to punycode.
Punycode uses a function called toASCII to strip out the characters that need encoding
and appends them to the remaining string separated by a hyphen. (The entire encoding
process is described in RFC 3492)
In other words: Motörhead would become motrhead-p4a, then we also need a mecha‐
nism to signal that this label or domain was not orginally an ASCII label to begin with,
so the prefix xn-- was selected.
Thus Motörhead.com becomes xn—motrhead-p4a.com (alas, that domain is already
taken)
In another example, 危危 (the famed yet flawed meme that in Chinese the word for
opportunity is arrived at by superimposing the symbols of “crisis” and “opportunity”3
becomes xn—xlr637b
2. International Standards Organization’s “Codes for the representation of names of countries and their subdi‐
visions.” - http://en.wikipedia.org/wiki/ISO_3166
3. See Victor Mayer’s “Danger + Opportunity != Crisis http://pinyin.info/chinese/crisis.html)
www.it-ebooks.info
|
13
Online Tools for Converting Punycode
Verisign’s IDN Conversion Tool: http://mct.verisign-grs.com/convert
Servlet?input=Mot%C3%B6rhead
All About Charsets: http://www.charset.org/punycode.php
Prior to the 2014 expansion of the Top Level Domain space, IDN’s existing within many
of the legacy TLDs. In other words, the label to the left of the dot could support IDN
strings while the domain suffix, the TLDs themselves were all ASCII.
With the advent of the new TLDs, IDNs are now supported to the right of the dot. xn
—j6w193g Such as Hong Kong’s *.危危 * Again, at the level of DNS lookups, you can’t
simply dig this suffix’s internationalized label:
Marks-MacBook-Pro:~ markjeftovic1$ host -t ns .
host: '.' is not a legal name (empty label)
Rather, the label is converted to punycode:
Marks-MacBook-Pro:~ markjeftovic1$ host -t ns xn--j6w193g
xn--j6w193g name server C.HKIRC.NET.HK.
xn--j6w193g name server Y.HKIRC.NET.HK.
xn--j6w193g name server V.HKIRC.NET.HK.
xn--j6w193g name server U.HKIRC.NET.HK.
xn--j6w193g name server B.HKIRC.NET.HK.
xn--j6w193g name server W.HKIRC.NET.HK.
xn--j6w193g name server Z.HKIRC.NET.HK.
xn--j6w193g name server D.HKIRC.NET.HK.
xn--j6w193g name server X.HKIRC.NET.HK.
Chartered TLDs
There exist “special purpose” or “sponsored” TLDs which are not available for general
widespread use but are instended for use within narrowly defined use cases. They are
sponsored by a specific community served by namespace. The .MIL and .INT zones
where early examples of these which have maintained their meaning and their charter
to the present day, (unlike say, .ORG ,although .ORG was never sponsored by a specific
agency even in it’s original incarnation)
In earlier rounds of post-ICANN TLD expansion several chartered TLDs were added
such as .MUSEUM, .AERO and .COOP and now that New Top Level Domain expansion
(see below) has commenced in earnest, there are now many more. Again, Wikipedia
stays pretty current with a list that specifcally breaks out the chartered TLDs http://
en.wikipedia.org/wiki/Sponsored_top-level_domain
Don’t confuse a “chartered” or “sponsored” TLD with a generic vertical TLD For ex‐
ample, .JOBS is a chartered TLD as it is sponsored by the Society for Human Resource
14
|
www.it-ebooks.info
Management. Contrast with .PRO, which is a generic TLD, however one that gears itself
toward “professionals”.
This book is not the place to debate the efficacy of attempting the divide internet users
into prefined naming categories. I’ve made my opinions clear on this in the past. The
purpose of this book is to guide us in dealing with exigencies of running these domains
for our customers, our employers and other stakeholders. In other words, we just work
here and our job is to keep the lights on for all these domains.
New Top Level Domains
As of 2013, things officially “got real” as the ICANN new TLD process kicked into
motion and released the wave of the new top level domain landscape. While “New
GTLDs” are defined as any TLDs entered into the Root after January 1st 2013, the TLD
expansion began in ernest during 2014.
The 2013 expansion is distinct from earlier new TLD expansions in that for the first
time it became possible for practically any entity to apply for a new Top Level Domain.
The previous two rounds of expansion (2000 and 2004 respectively) were much more
limited in scope and produced only 7 and 8 new TLDs respectively4 the 2014 round
opened the floodgates and so far over 400 new TLDs have been delegated in the roots.
This means that the number of generic TLDs has expanded over 20-fold in one year
and shows no signs of abating.
How Can I Get My Own TLD?
For obvious reasons, applying for a Top Level Domain was non-trivial. The application
process on the current expansion round closed back in 2012 and the new TLDs from
that round are still being delegated in a rolling basis.
Over the next few years up to 1300 more TLDs may go live..
It cost over $100,000 USD in non-refundable application fees to apply for a new Top
Level Domain, and in cases where there were more than one applicant for a given string,
a subsequent auction process ensued. For example, in November 2014 auctions were
held on various TLDs with multiple contenders, some of the results were as follows:
November 2014 new TLD auction results
TLD
# bidders
winning bid
winner
.BUY
16
$4,588,888
Amazon EU S.à r.l.
4. .aero, .biz, .coop, .info, .museum, .name and .pro in 2000 and then .asia, .cat, .jobs, .mobi, .post, .tel and .xxx
in 2004
www.it-ebooks.info
|
15
TLD
# bidders
winning bid
winner
.DOT
52
$700,000
Dish DBS Corporation
.REALTY
112
$5,588,888
Fegistry, LLC
.TECH
20
$6,760,000
Dot Tech LLC
.VIP
41
$3,000,888
Top Level Domain Holdings Ltd.
Source: https://gtldresult.icann.org/application-result/applicationstatus/auctionresults
At this point there is no word on when the next round of applications will be accepted.
But don’t despair: there will probably be a vigorous aftermarket for TLDs at some point
in the near future.
If you are serious about operating a TLD or someday owning one, you can familiarize
yourself with the ICANN New TLD Applicant Guidebook which will be a good basis
for understanding the next application round, when and if one is announced.
Private Namespaces
Alternative Namespaces
At the end of the day, the traditional internet namespaces that you and I and all of our
users experience every day is the result of consensus and inertia. There have been at‐
tempts from time to time to extend the legacy IANA-derived namespace into alternate
namespaces, and for the most part they have been unsuccessful.
There are exceptions emerging today, where an alternative namespace may obtain a
degree of traction apart from the legacy roots owing to its very nature of being outside
the legacy tree, decentralized and thus resistant to top-down control or censorship.
Examples of such namespaces are .ONION and .BIT
.ONION
The .ONION namespace (named after the routing protocol that provides anonymity)
is part of “The DarkNet” and accessed via the peer-to-peer TOR network and is not
normally visible to typical internet users without active modifications to their local
applications (such as browser plug-ins).
By using .onion addresses, users and applications can interact and communicate with
one another privately and anonymously. The infamous Silk Road marketplace ran on
the Onion network using the address http://silkroad6ownowfk.onion
There also exists as a compliment to .ONION addresses which specify TOR exit nodes,
ending in .EXIT
16
|
www.it-ebooks.info
.BIT
The .BIT namespace is an alternative DNS namespace that derives it’s rootzone from a
blockchain ledger model (similar to that employed by crypto-currencies such as bitcoin)
instead of an inverted-tree DNS hierarchy.
By using a decentralized blockchain, a true “P2P DNS” model has been achieved (some‐
thing I personally declared as being impossible more than once before it happened).
The .BIT namespace is attractive to privacy advocates because domain names under .BIT
cannot be seized, censored or otherwise squelched unless the private key governing a
specific domain is known.
While .ONION exists almost as a deliberate antithesis to the legacy rootzone, .BIT seeks
to one day be included in it and thus be visible and usable to all internet users. Another
contrast between .ONION and .BIT is that addresses under the former are not actually
resolved via the DNS protocol but by the end-client, typically a web browser. While the
latter is a real DNS-based namespace and resolved over the DNS.
Registrars
Registrars are organizations that facilitate the registration of domain names in specific
TLDs. They may specialize in this or do so in conjunction with some other service they
provide (such as web hosting providers or managed DNS). Most Registrars provide
registration services to multiple TLDs.
The basic responsibilities of Registrars include providing the ability to:
• Register and renew domain names
• Modify / update contact data associated with domain names (“Whois” records)
• Control security parameters of a domain (lock states)
• Update and maintain the nameserver delegations of domain names
• Enter DS keys into parent rootzone for DNSSEC enabled domains (where available)
The Extensible Provisioning Protocol
The de facto standard for Registrar/Registry communications is the Extensible Provi‐
sioning Protocol (EPP) which is defined in RFC 4930, although not all Registries who
implement it stick to it vigourously.
NetSol Monopoly
In the olden days, if you wanted to register a .COM/.NET or .ORG domain you had one
option, Network Solutions (a.k.a “NetSol”) - who operated both the registry and end-
Registrars
www.it-ebooks.info
|
17
user registration functions, making it “thick” registry with themselves acting as the
registrar.
Up until 1995 it was operated by the National Science Foundation and later spun out as
“The Internic”. Domains were registered for free, but they were strictly limited to onedomain per organization (and they enforced it).
In 1995 NetSol was purchased by SAIC and fees were introduced to register new do‐
mains and then to renew existing ones.
ICANN and Competition
In 1998 the oversight of the internet root transitioned from IANA to ICANN (see sidebar
“Oversight Bodies”)
Part of ICANN’s mandate was to open the domain registration business to competition,
commencing with the accreditation of five Registrars in the new Shared Registry System
in 1999. The first 5 Registrars in addition to NetSol were: BulkRegister (later acquired
by eNom), Register.com (now owned by web.com along with NetSol), Melbourne IT,
Tucows/OpenSRS and A Technology Company (which never launched).
In 2000, near the top of the .COM bubble, Versign acquired Network Solutions for a
reported 20 Billion dollars (that’s with a “B”). IN 2003 Verisign exited the Regsistrar
business by selling off Network Solutions and kept running the .COM and .NET Reg‐
istries, while the .ORG Registry was taken over by Public Interest Registry.
And thus, the era of competition (for the most part) began. While it can be argued that
Verisign enjoys a near pseudo-monopoly in the operation of .COM in that it is hard to
imagine that contract being awarded to any other entity in the future, we all know that
internet-time is the great equalizer and the future is anything but certain.
TLD Providers
Which brings us to Top Level Domain providers, the latest emergent market segment
in the field of DNS and naming.
Now that hundreds and thousands of New TLDs are hitting the roots, companies have
emerged that cater to new TLD operators, who can outsource the actual operations of
the either the registry itself, the new TLDs rootzone DNS or both.
In practical terms it is vital that any sysadmin or IT personel who are tasked with keeping
the lights on for a given portfolio of domain names have a visceral understanding of
both the underlying Registry from which the domains are originated and the Registrar
landscape which is their conduit into those Registries.
18
|
www.it-ebooks.info
Things change. If your company has decided to rebrand onto .CO then the ops group
needs to know that the ultimate authority over the key domain asset is the national
government of Columbia. Governments have been known to change, new governments
introduce new policies. New policies can impact the ccTLD of the country in question.
The point is that in order to effectively manage increasingly complex domain portfolios,
situational awareness of the Registries involved, their circumstances and their policies,
as well as working knowledge of the associated Registrars are a requirement.
• In 2010 CNNIC, the Chinese naming authority over .CN changed the policy for
the ccTLD and banned new domain registrations via Registrars who were not based
in China, tightened up restrictions and began enforcing local presence require‐
ments on .CN applicants.
• When the Arab Spring revolts hit Libya, the viability of the .ly ccTLD was called
into question. As the Libyan government, in an act of desparation, attempted to
shut down the internet within the country, many wondered if that would extend to
the .ly namespace - up on which many international start-ups are built. In fact, even
before the Arab Spring revolts hit Libya in 2011, the Libyan government was already
shutting down selected .ly domains in 2010 with no prior warning5
• Tuvalu may become the first country to completely disappear beneath rising sea
levels. In 2009 Godaddy questioned the future viability of the .TV namespace were
that to happen.6
• In 2013 the future of the gd, .tc and .vg ccTLDs came into question when a dispute
erupted between two entities asserting their own right to operate those namespaces.
7
With the advent of hundreds and even thousands of new TLDs, it is only a matter of
time before a few of them start failing. How that will work is a big question at this point.
Greater care must be taken when selecting top level domains to register key domains
under, especially in cases where those domains become a part of the greater internet
infrastructure.
5. As Was Predicted, Libya Is Shutting Down Some .ly Domains With No Notice https://www.techdirt.com/
articles/20101007/02303811322/as-was-predicted-libya-is-shutting-down-some-ly-domains-with-nonotice.shtml
6. GoDaddy Tells Us Not to Buy .TV Domains Because Tuvalu Is Sinking? http://gizmodo.com/5235114/
godaddy-tells-us-not-to-buy-tv-domains-because-tuvalu-is-sinking
7. Personal dispute jeopardizes all .gd, .tc and .vg domain names http://www.tld.sc/en/2013/03/personal-disputejeopardizes-all-gd-tc-and-vg-domain-names/
www.it-ebooks.info
|
19
www.it-ebooks.info
CHAPTER 3
Whois
As we outlined in the Anatomy of A Domain Name section, the domain name can be
split into logical sections like Registrant, Admin Contact, Tech Contacts, Nameservers,
etc. All of these sections are described and enumerated in records called “Whois” records
and those records are served by “Whois” servers. While in the early days Whois records
were merely informational repositories of points-of-contact for domain names, as the
internet became more integral to everyday living and business, these records became of
utmost importance by default. They have legal bearing now, they are used to decide
ownership disputes and liability issues. There exist “forensic whois record auditors”
who trace domain ownership using these records to asses whether a given domain may
be “stolen”.
The “Whois” servers are internet hosts that listen for Whois requests (typically on port
43) and they respond to queries about given domain names with the associated “Whois”
records for them. While traditionally there have been best practices for the format of
“Whois” records, there is no standard “Whois” format. That said, things are slowly
moving towards one.
Thin vs Thick Whois
Most registries today are moving towards a “thick” Whois model. That means is that
Whois servers are operated by the registries themselves and the Whois records returned
by the registry are the full and complete records:
$ whois easydns.org
Domain Name:EASYDNS.ORG
Domain ID: D19300541-LROR
Creation Date: 2000-02-07T16:36:30Z
Updated Date: 2014-02-05T19:35:20Z
Registry Expiry Date: 2015-02-07T16:36:30Z
Sponsoring Registrar:easyDNS Technologies Inc. (R1247-LROR)
Sponsoring Registrar IANA ID: 469
21
www.it-ebooks.info
WHOIS Server:
Referral URL:
Domain Status: ok
Registrant ID:tuFR6qyd4IzCW0LK
Registrant Name:Hostmaster Role Account
Registrant Organization:easyDNS Technologies
Registrant Street: 304A - 219 Dufferin St.
Registrant City:Toronto
Registrant State/Province:ON
Registrant Postal Code:M6K3J1
Registrant Country:CA
Registrant Phone:+1.6474788439
Registrant Fax Ext:
Registrant Email:[email protected]
Admin ID:tukBnUT7S6DIXC3g
Admin Name:Hostmaster Role Account
Admin Organization:easyDNS Technologies
Admin Street: 304A - 219 Dufferin St.
Admin City:Toronto
Admin State/Province:ON
Admin Postal Code:M6K3J1
Admin Country:CA
Admin Phone:+1.4165358672
Admin Phone Ext:
Admin Fax: +1.4165350237
Admin Fax Ext:
Admin Email:[email protected]
Tech ID:tu4jwsWgdFxARStq
Tech Name:Hostmaster Role Account
Tech Organization:easyDNS Technologies
Tech Street: 304A - 219 Dufferin St.
Tech City:Toronto
Tech State/Province:ON
Tech Postal Code:M6K3J1
Tech Country:CA
Tech Phone:+1.4165358672
Tech Phone Ext:
Tech Fax: +1.4165350237
Tech Fax Ext:
Tech Email:[email protected]
Name Server:DNS1.EASYDNS.COM
Name Server:DNS3.EASYDNS.ORG
Name Server:DNS2.EASYDNS.NET
Name Server:DNS4.EASYDNS.INFO
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
22
|
Chapter 3: Whois
www.it-ebooks.info
Name Server:
Name Server:
Name Server:
DNSSEC:Unsigned
Contrast with thin a Whois model which is largely the exception now and for the most
part on the way out.1
Thin whois goes back to the days when oversight of .COM, .NET and .ORG (in fact all
naming) was transitioned to ICANN. The Network Solutions monopoly was ended and
domain registrations under the existing gTLDs was opened up to competition, begin‐
ning with “The Original Five” ICANN registrars 2
Under that model, the registry operated a central whois server which handed out small
“stub records” and a reference to the whois server operated by the Registrar for each
domain. Those Registrar “Whois” servers return the full “Whois” records for the domain
names being queried.
For a thin whois lookup, we’d see the stub record:
$whois easydns.com
Domain Name: EASYDNS.COM
Registrar: EASYDNS TECHNOLOGIES, INC.
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.ORG
Name Server: DNS4.EASYDNS.INFO
Status: clientTransferProhibited
Status: clientUpdateProhibited
Updated Date: 24-oct-2014
Creation Date: 24-mar-1998
Expiration Date: 23-mar-2015
Your whois client will then follow the reference to the Registrar Whois server:
Domain Name: EASYDNS.COM
--------------------------------------------------------------------------Anycast Deployed Nameservers. 100% DNS Uptime SLA
--------------------------------------------------------------------------Registry Domain ID: 5253553_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.easydns.com
Registrar URL: http://www.easydns.com
Updated Date: 2014-10-23 20:08:47
Creation Date: 1998-03-24 05:00:00
1. The only thin whois TLDs operating at the time of writing are .COM, .NET and .JOBS
2. The original 5 competitive Registrars were: Network Solutions (now part of Web.com), Tucows/OpenSRS,
MelbourneIT, Register.com (also now part of Web.com) and BulkRegister (later acquired by eNom).
Thin vs Thick Whois
www.it-ebooks.info
|
23
Registrar: easyDNS Technologies, Inc.
Registrar Abuse Contact Phone: +1.4165358672
Registrant Name: Hostmaster Role Account
Registrant Organization: easyDNS Technologies
Registrant Street: 300A - 219 Dufferin St.
Registrant City: Toronto
Registrant State/Province: ON
Registrant Postal Code: M6K 3J1
Registrant Country: CA
Registrant Fax Ext:
Registrant Email: [email protected]
Registry Admin ID:
Admin Name: Hostmaster Role Account
Admin Organization: easyDNS Technologies
Admin Street: 300A - 219 Dufferin St.
Admin City: Toronto
Admin State/Province: ON
Admin Postal Code: M6K 3J1
Admin Country: CA
Admin Phone: +1.4165358672
Admin Phone Ext:
Admin Fax: +1.6474386227
Admin Fax Ext:
Admin Email: [email protected]
Registry Tech ID:
Tech Name: Hostmaster Role Account
Tech Organization: easyDNS Technologies
Tech Street: 300A - 219 Dufferin St.
Tech City: Toronto
Tech State/Province: ON
Tech Postal Code: M6K 3J1
Tech Country: CA
Tech Phone: +1.4165358672
Tech Phone Ext:
Tech Fax: +1.6474386227
Tech Fax Ext:
Tech Email: [email protected]
Name Server: DNS4.EASYDNS.INFO
Name Server: DNS2.EASYDNS.NET
Name Server: DNS3.EASYDNS.ORG
Name Server: DNS1.EASYDNS.COM
DNSSEC: Unsigned
24
|
Chapter 3: Whois
www.it-ebooks.info
Today, most TLDs are using a thick whois, where the entire whois record is served from
a central Whois server for that namespace, usually operated by the Registry itself.
Whois Privacy
The big problem with registering a domain name is that your contact details (or those
of your customer) are supposed to be “true and valid” contact details in order to fulfill
the requirements of your Registry Terms of Service and those details must be published
in the “Whois” database which is, as you now know, publicly accessible.
Wtf is a Whois?
My estimation is that a majority of internet users, even a majority of domain name
registrants have no idea that the Whois database even exists, let alone publishes their
contact data for all to see. Sure, you may know that (now ;) but the thing is, a lot of your
customers don’t.
The problem is that spammers, advertisers and marketers data mine the whois database
and extract data from it so before you know it you are getting various emails, marketing
pitches and junk faxes all because of the information you had to supply when you reg‐
istered the domain name.
To mitigate this Registrars invented “Whois privacy”. Whois privacy is basically masking
your “Whois” but because it is technically against the rules to supply false data in a
domain name registration what happened was that Registrars created actual corporate
entities that would act as the Registrant for your domain in your place. So when some‐
body looks up the “Whois” record for a domain name he would see the “Whois” for the
some privacy providing entity or some other suitable proxy cutout.
$ whois antiguru.com
Domain Name: ANTIGURU.COM
--------------------------------------------------------------------------Imagine a Success Coach who was actually successful!
Follow me on Twitter: http://twitter.com/antiguru
--------------------------------------------------------------------------Registry Domain ID: 1549312202_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.easydns.com
Registrar URL: http://www.easydns.com
Updated Date: 2014-03-24 10:00:05
Creation Date: 2009-03-25 19:05:18
Registrar: easyDNS Technologies, Inc.
Registrar Abuse Contact Phone: +1.4165358672
Whois Privacy
www.it-ebooks.info
|
25
*Registrant Name: Contact Privacy
Registrant Organization: MyPrivacy.net Ltd.*
Registrant Street: 300A-219 Dufferin St.
Registrant City: Toronto
Registrant State/Province: ON
Registrant Postal Code: M6K 3J1
Registrant Country: CA
Registrant Fax:
Registrant Fax Ext:
*Registrant Email: [email protected]*
Registry Admin ID:
Admin Name: Contact Privacy
Admin Organization: MyPrivacy.net Ltd.
Admin Street: 300A-219 Dufferin St.
Admin City: Toronto
Admin State/Province: ON
Admin Postal Code: M6K 3J1
Admin Country: CA
Admin Phone: +1.6474785997
This accomplishes what most set out to do and it masks your Whois data your private
contact details from marketers and spammers. But… it comes with host of associated
risks that you need to be aware of.
Most importantly when you use “Whois” privacy the actual owner or rights holder for
your domain name is the privacy entity that is listed in the Whois record for your
domain.
In practical terms there is usually a secondary agreement between you and that privacy
entity that presumably upholds your rights to the domain name. But in the event of a
dispute or lost contact details or a lockout situation, it is the privacy entity that owns or
holds all the rights to your domain names not you.
Further, Registrars are contractually obligated to escrow their whois data with an escrow
provider to safeguard against business failure on part of the Registrar. There is no ob‐
ligation that they have to escrow your shielded data. What may happen instead is that
they will only escrow your privacy-protected data.
RegisterFly - The Lehman Brothers moment of the domain industry
This became an issue back when registerFly failed as a registrar and a lot of people lost
the rights to their domain names because they were locked out. { insert story - mark }
26
|
Chapter 3: Whois
www.it-ebooks.info
How to Tell if Whois Privacy is Enabled
If you do a look on a “Whois” record a lot of times there is no set field inside the record
that says “privacy is enabled” but after you look at enough of these you start to get a feel
for it. The table below lists common Privacy providers (cutouts) and the domain reg‐
istrars they are associated with:
Table 3-1. Whois Privacy Entities
Privacy Entity
Registrar
Domains By Proxy
Godaddy
WhoisGuard
Namecheap
MyPrivacy.net Ltd.
easyDNS
Contacy Privacy Ltd.
Tucows/OpenSRS
Privacy Protection Service INC d/b/a PrivacyProtect.org Public Domain Registry
WhoisGuard Inc.
eNom
Oneandone Private Registration
1&1 Internet Inc.
Whois Privacy Services Pty Ltd
Fabulous Pty.
All these various privacy providers are entities that are usually created by the registrar
specifically or solely to facilitate “Whois” privacy. One of the key reasons here is to
compartmentalize potential liability from domain names which the Privacy Entity is
listed as the “Registrant”.3
There are a few reasons you would want to use Whois privacy:
• you don’t want your personal contact details harvested by spammers.
• you may be in “stealth mode”, registering domain names about new products and
services you may want to shield yourself from the scrutiny of your competitors
• you’re doing something controversial like whistleblowing, _
3. 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-sueddomain-whois-privacy-service/5198
www.it-ebooks.info
|
27
Why you should never use “Whois” privacy
You should never use Whois privacy if you consider the risk of not directly owning and
controlling your domain names to be an unacceptable risk.4 The other thing about
“Whois” privacy, especially for ecommerce websites and companies doing business on
the internet, is that it tends to look “scammy”. If you are taking people’s credit card data
or other Personally Identifiable Information (PII) then you should be as transparent as
possible and make it easy for users to lookup exactly who they are doing business with.
Few would disagree that in this context, anonymized whois records may be offputting
to potential customers. The problem is when the signup process for many domain reg‐
istrations is so convoluted and oversaturated with “upsells” and “addons” that in many
cases whois privacy may be enabled for your domains without the domain registrants’
actually being aware of it
Another caveat to using “Whois” privacy is that it can also be used (intentionally? who
knows) to create “lock-in” situations. For people not immersed in this industry, tran‐
ferring domains between Registrars can be a daunting task. It gets even harder when
the domains have Whois privacy enabled.
When signing up a domain with a given registrar, adding Whois privacy is trivially easy
(perhaps, as previously noted, too easy). It’s just a checkbox! For your convenience it
may have already been checked.
Come time to transfer it out and turn it off, it’s another story. Once you’re at a point
where you decide to transfer your domain to another registrar (perhaps because of the
stellar service?) you have to disable Whois Privacy before you can transfer the domain
out. Usually the Registrar creates a separate Privacy Entity, if they are nice about it, you
have the ability to disable Whois Privacy from within the same control panel you manage
everything else. If they’re “not so nice” about it, they force you to contact the Privacy
Entity separately to disable it, and that Privacy Entity may erect more hurdles, such as
providing written authorization or photo ID.5
Where is Whois going? Registration Data Directory Service
(RDDS)
{ summarise GNSO efforts and recommendations, outline roadmap and how to follow
process }
4. 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.
5. This isn’t the place to name names. You can see DomainHelp.com for a comparison of Whois Privacy Entities
28
|
Chapter 3: Whois
www.it-ebooks.info
CHAPTER 4
Intellectual Property & Legal Issues
This chapter provides an overview of intellectual property (IP) and legal issues that can
affect one or more of your portfolio domains or those of your downstream users.
Even if your function as it relates to the portfolio is primarily technical in nature, it is
important that there is some cognizance of these issues among the technology team.
When legal issues arise, the initial point of contact is is frequently the hostmaster, web‐
master, postmaster or similar technical person. The initial response needs to be con‐
sistent with documented internal company policies. Similarly, when it comes to IP is‐
sues, the technical team should be acting in accordance to known organizational pa‐
rameters.
Without this awareness the consequences can range from making the organization vul‐
nerable to legal challenges from outside entities or even downstream users; to having
discordant, often contradictory responses to a given situation.
In this section we’ll discuss the need to have coherent policies that guide everything
from which domains and TLDs an organization should register its marks in, to how to
go about recovering a domain that has inadvertantly expired, through to how to respond
to legal challenges to your domains and even how to challenge somebody else’s domain
if you feel it is infringing in your IP.
What top level domain suffixes should your organization register? In the old days (be‐
fore 2014) a lot of registrars would try to goad their customers into registering their
organization name in every top level domain that was possibly available.
“Get your name before somebody else does!” was the well-worn mantra that was con‐
stantly broadcasted at registrants every time a new generic top level domain came out
or some country code decided to be brand themselves as some sort of pseudo-TLD. In
29
www.it-ebooks.info
a lot of cases it worked because managers, IP departments or lawyers would think that
there is an obligation to defend the organization’s intellectual property in any way they
can. What that meant was a lot of organizations would make it a habit to register their
name in every TLD in which they could possibly do so.
As we’ve discussed, now that the new TLDs are here, there are hundreds and eventually
thousands of TLD’s. It is effectively impossible to defend your mark in every single one
of these. Especially if you are an organization with a large portfolio of trademarks,
products, call-to-action URLs or other meaningful names.
For example one of our clients at easyDNS is a pharmaceutical conglomerate that has
the domain name of every single product they own plus a few other “call-to-action”1
domain names in their portfolio. On its own it is about 6,000 to 10,000 names. The level
of complexity involved in taking that IP portfolio and then registering them in as many
TLDs as practical before the 2014 rollout of the new TLDs was daunting enough. Now
that the new TLDs are out of the bottle, I think it is categorically impossible.
Which brings us back to the question “what domain suffix should organizations register
in”?
There is a rule of thumb espoused by a legendry domainer by the name of Frank Schilling
who always advocated registering the .COM, .NET, .ORG of your name plus the ccTLD
of your primary country of business and any other countries you are doing business in.
So if you’re The Example Corporation you would register (if you can) example.com,
example.net, example.org, and if you’re here in Canada you would get example.ca. That’s
a pretty good rule of thumb. Your mileage may vary, sometimes you can’t get the .COM,
everybody (Conventional wisdom holds that “.COM is King” but it can be open to
debate. It certainly is the most popular top level domain in existence as per the chart
below ).
1. a “call-to-action” URL or domain is one used to bridge the gap between mediums. For example a billboard
offering services with a URL on it saying “http://calltoday.ca” - that’s a “call-to-action” URL. It may be easier
to remember than the actual product or service name and thus can increase response rates, and make it easier
to measure effectiveness
30
| Chapter 4: Intellectual Property & Legal Issues
www.it-ebooks.info
Sometimes you can’t get the .COM and make a calculated decision to launch without
it. This was already becoming more prevelant in the “Web 2.0” phase of the internet,
with companies launching on alternative TLDs like .IO, .LY, and so forth.
What this rule of thumb signifies is that you’re going to make a rational decision around
a small set of core TLDs. I would modify this rule as follows:
• Try to get the big generics .COM, .NET, .ORG
• Get the country code(s) that you’re doing business in
• Register in any of the new top level domains that make direct relevant business
sense to your organization and its products / services.
An example of this last point, we launched easyPress managed WordPress hosting in
2013, and we actually launched on .CA: easyPress.ca. We don’t have the .COM and we
never will. We decided to go ahead regardless, positioning as “the Canadian managed
wordPress hosting company”. When the new top level domains came out we decided
to secure easy.press. That is an example of a new TLD that makes direct relevant sense
to a specific use-case.
You have to choose your balance, a set of criterea that will whittle all the potential TLDs
down to a strategic group of them that you want to defend your marks in, and then you
just leave the rest behind.
www.it-ebooks.info
|
31
Asserting Your Trademarks Withing the New gTLD Landscape
As we’ve covered, there are so many new gTLDs rolling out we will be well into the
thousands within a few years. You will want to register some or all of your marks in
some (but not all) of the new gTLDs. You may also want to make use of the Trademark
Clearing House for those marks you do want to defend, but not by registering every
possible domain. We’ll cover both aspects here.
The bad news is when you add up the various fees (Trademark Clearing House, Sunrise
Applications, not to mention all the extra domains themselves) it starts to add-up. You
might be further ahead building your entire infrastructure on an easy-to-remember
IPv4 address (I am of course kidding).
Once a new gTLD delegation is added to the root, it goes through a ramp-up phase
before it is widely available on a first-come/first-served basis.
Sunrise
In the Sunrise phase Intellectual Property owners may register for domains that match
their trademarks. Usually the trademarks must be registered (in any jurisdiction) in
order to qualify, and trademarks may not “span the dot”. In other words, when .bar
enters Sunrise and your organization holds a registered trademark on “foobar[tm]” you
cannot enter a Sunrise application for foo.bar. You can only enter a claim on a matching
label for your trademark, in this example: foobar.bar.
If multiple trademark claimants enter Sunrise applications for the same label it will
usually go into an auction process.
Sunrise claims typically cost significantly more than a normal “Landrush” registration
(in the $300 to $500 USD range each), yet another barrier making it unfeasible in many
cases to defend all of one’s registered marks under all possible gTLDs.
For the “new GTLDs” which are in the process of rolling out, you have to have your
trademarks registered with the Trademark Clearing House (see below) in order to qual‐
ify for a sunrise round.
Landrush
Landrush is the “free-for-all” phase where presumeably, everything left after Sunrise
becomes available on a first-come/first-served basis. That said, the common practice
among most new gTLD operators now is to reserve a list of domains designated as
“premium”, which cannot be registered via Landrush.
Many Registrars pre-sell Landrush by building up waiting lists beforehand themselves.
Similar to the Registries “Premium lists”, they will take preorders on upcoming domains
and if they encounter contention (multiple orders for the same label), they will endeavor
32
|
Chapter 4: Intellectual Property & Legal Issues
www.it-ebooks.info
to “snag” the domain upon commencement of landrush and if successful they will then
auction it to the multiple parties.
Premium Auction
The Registry will often reserve most of the highly desireable labels under a specific new
gTLD, as well as all of the 1, 2 and perhaps some of the 3 character labels and designate
them as “premium names”. They will then either auction them off of broker them to
interested parties on a case-by-case basis, for vastly inflated fees.
The Trademark Clearing House
For the vast number of new gTLDs under which you won’t or can’t directly register your
labels, you can gain some defense of your marks by making use of the Trademark
Clearing House.
This provides a mechanism where one registers one’s marks but will allow other parties
to register labels matching those marks, provided they go through an additional step
where they are made aware of the contending marks, and affirm that their use of the
domain does not infringe on the mark.
www.it-ebooks.info
|
33
34
|
www.it-ebooks.info
The problem in my mind with the Trademark Clearing House is that you need have
your marks in it before you can apply for sunrise applications for any of the new TLDs,
but the terms only last 90 days to a year. Which means yet another service your com‐
mited to subscribing and renewing in order to “defend your marks”.
Typo domains
Another decision that you will have to incorporate into your strategy is what to do about
obvious (emphasize the “obvious” part) typos of your domains. Defensively securing
misspellings and typos of your portfolio will again, boost the complexity of the portfolio
itself an order of magnitude. (Think about trying to defend your mark in all TLDs with
all possible typo variations it becomes impractical very quickly).
Some examples of obvious typos: we’re easyDNS, so we have easydsn, it is a common
typo to make. We do this because it brings in traffic from our own userbase which may
www.it-ebooks.info
|
35
commonly make this typo from time-to-time. It makes sense because it contributes
directly to usability.
Contrast with a typo that will rarely if ever be made: easydsn.biz. Who cares. We don’t
and the reason we don’t is because it nobody has ever typed that trying to get to our
website.
There is a reason why it is safe to ignore entire swaths of typos under most TLDs. If
somebody else actually grabs a derivation of one of your marks, whether it is a typo or
a cybersquat under any other top level domain, in other words, any use which can be
deemed “confusingly similar” to yours, there are mechanisms available for you to have
those domain names shut down and seized if they are in fact trading on your intellectual
property. (We will explain them below).
36
|
www.it-ebooks.info
What is “CyberSquatting”?
There is a lot of confusion around the term “cyberquatting in which
it is frequently misconstrued as any time somebody registers a do‐
main and doesn’t actively “use it for something”. But that is not cy‐
bersquatting. A lot of people feel there should be some manner of “use
it or lose it” rules around domain names and they view those who
don’t “use” their own domains as cybersquatters.
It’s a fallacious argument, since “use” is entirely subjective. Use vs nonuse is an opinion. Even if a domain is intentionally not delegated in
the roots, it may be that way for a reason and thus constitute “use”.
More often the cybersquatting charge is leveled against “domainers”,
defined as people and companies who register large numbers of do‐
main names and then either offer them for sale in the aftermarket,
monetize them via ads or lead generation, or both.
There is a perception that doing so is not a “legitimite” use of the
domain, however that is a purely subjective opinion (not to men‐
tion a sanctimoniously Marxist one).
My stance on this has been borne out in repeated findings by UDRP
panels that “domain parking” is a legitimite use of a domain name,
and further, that asking for a “inflated sum” of money in the after‐
market is (again, subjective) not evidence of a “Bad Faith” registra‐
tion (“Bad Faith” being a key requirement in a domain dispute pro‐
ceeding).
So What is “CyberSquatting” then?
It is when some party deliberately and intentionally registers mispel‐
lings or alternate TLD versions of your domains and does the fol‐
lowing:
• Uses it in a way which is “confusingly similar” to your own
(passing off)
• Benefits from your trademarks, i.e. running ads for your prod‐
ucts or those of a competitor
• Intends to profit from the domain through these methods or
from an eventual sale of the domain to you or otherwise.
A textbook example of cybersquatting would be the registration of
yourtrademark.co (capturing typo traffic from people missing or ne‐
glecting to type the final “m” in yourtrademark.com) and then redi‐
recting that traffic to an affiliate program selling your own prod‐
ucts, or that of a competitor’s.
www.it-ebooks.info
|
37
Dispute Mechanisms
Processes exist to handle disputes between contending claims on a given domain name.
The “Terms of Service” your Registrar will have you agree to at the time you register a
domain will include the provision to abide by these processes. Disputes are not handled
or arbited by ICANN but rather by “Dispute Resolution Providers” who are sanctioned
by ICANN to render decisions according to the defined policy.
Uniform Domain Name Dispute Resolution Policy (UDRP)
The Uniform Domain Name Dispute Resolution Policy is the primary mechanism by
which Intellectual Property (IP) rights (or claims) are asserted over domain names. If
the complainant is successful in bringing a UDRP procedure against an offending do‐
main, it can be canceled or ordered transferred to the complainant. (The remedy in
successful cases is always a transfer. If the domain is simply canceled then some other
Registrant may grab it and you are back to square one).
In order to successfully bring a UDRP against a domain name, all three of the following
elements must be present:
“(i) your domain name is identical or confusingly similar to a trademark or service mark
in which the complainant has rights; and
(ii) you have no rights or legitimate interests in respect of the domain name; and
(iii) your domain name has been registered and is being used in bad faith.”
• https://www.icann.org/resources/pages/policy-2012-02-25-en
In a UDRP the party bringing the action is “the complainant” while the current domain
holder defending against the action is “the respondant”.
To bring a complaint against a domain the complainant selects an authorized Dispute
Resolution Provider, such as the National Arbitration Forum (NAF) or the World In‐
tellectual Property Rights Organization (WIPO) and files the complaint and pays the
administrative fees.2
How the UDRP Works
Here we’ll take you through the basic flow and “things to know” of the UDRP procedure.
It is highly recommended that you retain a lawyer that specializes in these matters (See
the “Domain Name Lawyers” sidebar in Chapter 1_06). It is still recommended that you
be familiar with the procedure even if you retain counsel. Finally, I strongly caution
2. ICANN maintains a list of approved Dispute Resolution Providers https://www.icann.org/resources/pages/
providers-6d-2012-02-25-en
38
|
www.it-ebooks.info
against representing yourself on either side of a UDRP unless you are a full time pro‐
fessional domainer or otherwise immersed in the industry and are familiar with the
governing rules and precedents.
• Complainant selects a Dispute Resolution Provider prepares background material,
submits complaint and remits fees.
• The Dispute Resolution Provider notifies the current Registrar for the domain and
requests that the Registrar verifies various aspects of the Registration.
• The Registrar then sets clientTransferProhibited and clientUpdateProhibited flag
on the domain status. This prevents the domain from updating it’s Whois record
or from transferring away, but the domain will continue to resolve over the internet.
• The Resolution Provider will then forward a copy of the complaint to the Re‐
spondant.
• Unless the respondant elects to use a three-member panel to hear the case, the
procedure will be heard by a one-member panel. If the respondant goes with a threemember panel, additional fees apply and the total fees will be split between the
Complainant and Respondant.
• The Respondant will have until the stated deadline to file its rebuttal. If the Re‐
spondant fails to file a response, the Panel will decide the case without input from
the Respondant. There have been rare cases where a Panel has decided in favor of
an unresponsive Respondant.
Transfer Dispute Resolution Procedure (TDRP)
The TDRP procedure3 is not invoked by end-user Registrants but rather by the Regis‐
trars themselves when faced with a situation in the Losing Registrar will not relenquish
control over a given domain and allow it to transfer-out to the Gaining Registrar.4
Under the ICANN Inter-Registrars Transfer Policy5 there are very clear reasons why a
Losing Registrar may deny a transfer-out to another Registrar, those reasons are:
1. Evidence of Fraud (see “What is “fraud” within the context of denying a domain
transfer?”)
2. an in-progress UDRP
3. https://www.icann.org/resources/pages/tdrp-2012-02-25-en
4. When a domain is transfered between Registrars the two parties are commonly referred to as the “Gaining
Registrar” and the “Losing Registrar” for obvious reasons.
5. https://www.icann.org/resources/pages/registrars/transfers-en
Dispute Mechanisms
www.it-ebooks.info
|
39
3. a court order by a court of competent jurisdiction6
4. dispute over identity of the Registrant of Admin Contact (this is why you never use
bogus information in these fields)
5. lack of payment for the previous registration period - including credit card chargebacks or NSF cheques.
6. the current Registrant objects to the transfer (unauthorized transfer)
7. the domain itself is less than 60 days old
These are the only valid reasons for a Losing Registrar to deny a transfer-out. Unfortu‐
natey at the time of writing however, there is no mechanism available to end-user Reg‐
istrants who feel their domains are being held captive in contravention of these condi‐
tions to directly initiate a dispute. It has to be initiated by the Registrar, thus a Registrant
with captured domains must engage a Gaining Registrar with the will to initiate and
pursue this process.
The first step in doing so is for a Registrar to file a “Request For Enforcement” (RFE)
with the Registry of the domains in question. The Registry will solicit the Losing Reg‐
istrar for a response and render one of three possible decisions:
1. in favor of Gaining Registrar
2. in favor of Losing Registrar
3. no decision
If the Gaining (or Losing) Registrar disagrees with the decision and still wants to pursue
the manner it must now do so via an appeal, which is facilitated via a Transfer Dispute
Resolution Provider in a manner similar to the UDRP above. Whichever Registrar in‐
itiates the appeal must pay the panelist fees associated with the arbitration (starting at
roughly $1100 USD for 1 domain in a 1-member panel and $2,500 USD for a 3-member
panel7) The arbitration loser ultimately pays these fees. If the initiator wins, the loser
must then remit the fees and the initiator receives a refund.
TDRPs rarely get to the second stage. My company successfully filed one in 2014 where
we prevailed but were surprised to learn it was only the second time a second-level
TDRP appeal had ever been filed.
6. See the NAF ruling in the case of easyDNS v Public Interest Registry http://blog.easydns.org/2014/01/09/
domains-locked-in-london-police-takedown-ordered-to-be-transferred/
7. http://domains.adrforum.com/main.aspx?itemID=643&hideBar=False&navID=270&news=26
40
|
www.it-ebooks.info
Uniform Rapid Suspension System (URS)
The URS8 is a newer policy designed to make a faster and more affordable dispute
resolution mechanism available to rights holders. A URS action can only be initiated
against New gTLDs.
The URS contains similar elements to the UDRP:
• Complainant files her complaint via a sanctioned URS provider.
• Fees must be paid by the Complainant within 24 hours of filing or it is summarily
denied.
• Details of the complaint as outlined in the URS procedure
As with the UDRP, three key elements must be asserted and all must be present:
1. That the domain is identical or confusingly similar to an existing mark
2. That the Registrant has no legitimate interest or use for the name
3. That the name was registered in Bad Faith
What is “Bad Faith” ?
Other than a great name for a rock band, “bad faith” is a required element of any suc‐
cessful UDRP or URS proceeding. The URS cites a non-exclusive set of “bad faith”
conditions, including:
Illegitimate gain
That means Registrant has obtained the domain primarily for the purpose of profiting
from the domain (via sale, rent or otherwise transferring it) to the Complainant or to a
competitor of the Complainant. This is important. Offering a domain name for sale does
not in itself amount to bad faith. There has to be a specific impetus to somehow gain
from the Complainant’s own marks. Offering a domain for sale that happens to coincide
with a Complainant’s mark, but either predates it (was registered before the trademark)
or also has other legitimate uses or connotations is not bad faith.
Blocking / Denial of Service
Registration of a domain in order to specifically deny a rightsholder from obtaining it.
Grabbing “google.somenewtld” would qualify here, especially if it were done by say,
Bing. But that said, if somebody registered oreilly.blargh and their name, or business
really was O’Reilly, then it would not.
8. http://newgtlds.icann.org/en/applicants/urs
Dispute Mechanisms
www.it-ebooks.info
|
41
What if Somebody is infringing on your marks or
squatting on your name?
If you feel somebody’s domain is infinging on your intellectual property you should use
a UDRP in the case of legacy gTLDs (.com/.net/.org/.biz/.info) or the URS in the case
of new gTLDs (.website, .finance, .xyz, .wtf).
For ccTLDs you have to check with the Registry that operates the ccTLD in question.
(Insert table here of the larger country codes and their respective dispute resolution
protocols)
What If Somebody Tries to Take Your Domains?
Provided that you have a legitimate interest in the domain and you are not cybersquat‐
ting (leveraging other people’s IP), you should be able to prevail in a UDRP or URS
challenge.
Things that will help you win:
• A matching registered trademark (domain: example.com with a trademark: “ex‐
ample”)
• If you registered the domain prior to the Complainant’s trademark or commence‐
ment of business activities
• Unambiguous legitimate use, such as your own active business, blog, hobby page,
etc.
It is becoming a more frequent occurance that various entities are attempting to use the
existing domain dispute proceedings to strip domains away from their registrants,
however in many cases those current registrants are not cybersquatting. The term for
this is “Reverse Hijacking”.
Fortunately, dispute panels are recognizing this and when they see it and they often
penalize the aggressor for it. We’ve covered the three “must-have” conditions that need
exist in order for a dispute resolution process to strip a domain and order it transferred.
In lieu of any of those three, and especially in absence of all of them, you would have a
case for reverse hijacking and can be awarded your costs plus damages.
What Happens When Somebody Initiates a UDRP Against Your
Domain
This plays out as the flipside of the dispute protocol outlined earlier. Instead of being
the complainant, you are now the respondent.
42
|
www.it-ebooks.info
Your Registrar will send notice via email to your admin contact email address (and
possibly others) that they have received a UDRP complaint from either WIPO or the
National Arbitration Forum. They will ask you to confirm or correct the data in the
domain Whois record. They will also put the domain on “registry-lock” status: this let’s
the domain continue to resolve over the internet but it cannot be transferred or other‐
wise modified until after the UDRP proceeding concludes.
As the Respondent, you have 20 days to file your reply. One of the decisions is whether
to go with a 1-person or a 3-person panel. If both you and the Complainent seek a single
panelist, then one will be appointed by the governing body (WIPO or NAF). If the
Complainant specifies a 1-person but the Respondent wants 3, the additional costs in
doing do will be split between the Complainant and Respondent.
Domain Aftermarket
Buying or selling a domain name between private parties in the aftermarket warrants a
separate description than a routine inter-registrar domain transfer or even a plain vanilla
change of registrant, because it involves two separate entities and more importantly,
money.
There are various mechanisms that can be employed in transferring control of a domain
from one party to another, it is strongly suggested when dealing with arm’s length entities
to use one of the following methods in conjunction with a reputable escrow service.
Account Push
When the buyer and seller hold accounts within the same Registrar platform, most
systems have the ability to “push” a domain between accounts. In some cases it is pref‐
erable to employ this method when available, even if ultimately you will transfer-out
the domain to your preferred Registrar. By doing so you obtain control over the domain
faster and can even begin using it.
Further, with some registrars, any material change to the contact data of a domain (such
as the name of the Registrant) will trigger it to be “locked” against a transfer-out for a
fixed amount of time (such as 60 days).9
The main advantage of account push over Registrar transfer is speed, as this can be
facilitated instantly while a Registrar transfer can take 5-7 days.
9. such locks technically contravene the ICANN policy on inter-registrar domain transfers, thus they can be
overridden or released early if you push hard enough and use the correct Masonic lingo. I.e. “Holding this
domain for 60 days contravenes the ICANN Inter-Registrar Transfer Policy, so please release it immediately.
Thx”
Domain Aftermarket
www.it-ebooks.info
|
43
Registrar Transfer
(Also see the section on Domain Transfers in next chapter “Managing Your Portfolio”)
If the buyer decides to immediately go with the Registrar transfer to assume the domain,
it is highly advisable to do so in conjunction with a reputable escrow service.
Once funds have been secured to the vendor’s satisfaction, she then:
• drops whois privacy, if enabled
• disables the transfer lock
• transmits the auth-key to the buyer or escrow agent
Once the buyer initiates the transfer-out, the seller may then further confirm the
transfer-away thus facilitating a faster handover 10
The presence of Whois privacy can also be an impediment to this type of transaction,
as it often has to be dropped before it can be transferred-out or pushed to another
account. In some cases turning off Whois privacy is somewhat more cumbersome than
turning it on in the first place.
Occasionally you may find yourself having to go out into a domain aftermarket to obtain
a domain name, or in a case where an unintended expiry - a backorder service.
The largest domain aftermarket is the combined Godaddy / Afternic marketplace.
Godaddy is at present the world’s largest Registrar and has long operated their own
aftermarket on behalf of their Registrants. In 2013 they acquired Afternic.com, itself a
large marketplace which carried its own listings as well as syndicated listings from thirdparty Registrars and independent aftermarkets. Other significant marketplaces include
Uniregistry.com and Sedo.
Backordering and Registrar Expiry Frontrunning
Backorder Services perform the specialized function of attempting to re-register do‐
mains that have recently expired. In this context, “recently” means less than a second
ago. If a domain name of any value whatsoever expired when you started reading this
sentence, it will in all likliehood be re-registered by somebody else (sometimes referred
to “domain snipers” or “drop catchers”) by the time you finish it. That’s why under‐
standing the expiry cycle is so important (See section: The Domain Expiry Cycle).
10. not all Registrars support explicit transfer-away confirmations. If they do not, you simply wait the 5-7 days
for the Registry to effect the transfer
44
|
www.it-ebooks.info
The original back ordering service was Snapnames.com which was later acquired by
Web.com. It is important to know the landscape of the backordering services because
in many cases, knowing which Registrars are associated with which backordering serv‐
ices helps you narrow your scope when your customer’s pet domain slipped through
the cracks and you need to claw it back.
Other backordering services include Namejet and Pool.com.
Most backordering services operate on a contigency basis: you place your order on a
domain name but you will only be charged if they successfuly secure it. If multiple parties
backorder the same domain and the backorder service is successful in securing the
domain, it will go into an auction process where the highest bidder will obtain the name.
Alas, it’s not as simple as placing an order with a backorder service (or even multiple
backorder services if you’re in a hair-on-fire situation) for two reasons:
1) Where the domain was registered before it went into the expiry process influences
which service will be able to successfully “snap” it. Web.com owns Network Solutions
(former monopoly and formerly the largest Registrar) and Register.com. All of their
expiring domains feed into Snapnames, which it owns. This means if you are looking
at a domain registered via NetSol your odds will be better to backorder via Snapnames
than Namejet. Conversely, Namejet is owned by the eNom. When you are after a domain
expiring via eNom or their associated brands (Bulkregister, Name.com) you would look
first at Namejet.com. Godaddy, the largest Registrar operating today, offers backorders
on its expiring domains via its own system and it its acquired Afternic platform.
2) The above point is moot if the Registrar actively front runs its own expiry channel
and sells backorders or auctions expired domain names while they are still in the expiry
grace period (and most Registrars now do this, unless they have active relationships
with their backordering services, like Web.com/Snapnames or eNom/Namejet above).
Escrow Services
At some point it is likely you will end up buying or selling a domain in the domain
aftermarket, most likely the other side of the transaction will be an entity or person with
whom you have no past dealings and may not even have a verifiable identity beyond an
opaque holding company or other shell entity.
It is still possible to conduct a transaction under these circumstances by using a reputable
escrow service to facilitate the transaction.
Reputable Escrow services include:
• escrow.com
• escrowhill.com
www.it-ebooks.info
|
45
• moniker.com
In some cases large ticket domain names sales are constructed as buy/lease arrange‐
ments and take place over time. In such cases you can use a lawyer well versed in domain
name law (see sidebar on domain name lawyers in “Managing Your Portfolio” section)
to hold the domain in escrow over the term of the payout schedule.
Other Legal Issues
When managing domain names on behalf of mutliple downstream users you will likely
find yourself being contacted by third parties antagonistic to your customers. These
communications may take the form of takedown requests, demands that you turn over
customer data or in extreme cases, that you turn over control over domain names to
those making the request.
In these situations it is important that you do not panic or allow yourself to be harassed
into taking action that runs counter your own best interests and those of your customers.
The way to do this is two-fold:
1) Have policies in place in advance that clearly spell out under what circumstances you
will take action against a customer domain. Having a defined position in the form of a
policy that you consistently adhere to provides a certain amount of legal cover should
you find matters really heating up. Ideally these policies have been reviewed by legal
counsel familair with domain name law and intellectual propery issues in your juris‐
diction.
Domain Name Lawyers
Yes, there are lawyers who specialize in domain name matters and the closely related
area of intellectual property law. Here are a few.
Canada:
Zak Muscovitch http://dnattorney.com
United States:
John Berryhill http://johnberryhill.com
Mark Randazza http://randazza.com
Ari Goldberger Esq. http://esqwire.com
Stevan Lieberman http://APLegal.com
From experience I can tell you, if you are embroiled in a legal issue you are served best
by retaining a lawyer that specializes in the field. Leave your uncle the family lawyer to
46
| Chapter 4: Intellectual Property & Legal Issues
www.it-ebooks.info
file your incorporation documents and draw up your will. If you get a UDRP against
your prized domain, don’t mess around and call in a specialist.
2) Know your place within the ecosystem you inhabit and understand your legal and
contractual obligations withing that space.
An ICANN accredited domain Registrar is bound by their Registrar Accreditation
Agreement (RAA), which gives you certain obligations. An example would be to abide
by the UDRP or URS processes against any of your customer domains and lockdown
such a domain pending the outcome of a decision. But a non-Registrar DNS provider
or web host is not bound by the ICANN RAA (unless they are reselling for an ICANN
accredited Registrar)
Many of the issues you will face will fit into the following buckets:
• Privacy
• Copyright
• Defamation
• Fraud
• Network Abuse
You need to know your legal stance for these ahead of time. It’s out of scope here to
attempt to cover these in depth and I can’t give you legal advice. Just general principals.
Obviously the law differs wildly from country to country and even jurisdiction to ju‐
risdiction. Something that is legal wherever you happen to be reading this book may
get you beheaded someplace else. In some countries there are specific safe-harbour laws
for ISPs and service providers. In others, not so much.
Your key tool for mitigating legal risk and upholding your customers’ rights is your
Terms of Service or Acceptable Use Policy. It should be part of your onboarding process
that your customers agree to abide by it, but I also think it’s important that these terms
be as brief and straightforward as possible.
Further, you should make it clear, and understand yourself that your AUP is an agree‐
ment between you and your customers and that third parties typically have no standing
in that agreement. I mention this because many times when you receive a takedown
request for a domain under management, the complainant will cite your own Terms of
Service as grounds for the takedown.
While the following should not be construed as legal advice, consult a competent at‐
torney before ingesting, the following bullet points cover off most of the big issues you
will face in the course of managing large numbers of disparate customer domains:
Other Legal Issues
www.it-ebooks.info
|
47
• What constitutes a violation of your terms is at your sole discretion.
• Third parties have no standing in your agreements with your customers (i.e. they
cannot point at your own terms and expect to be able to use them to compel you
to take down a domain)
• Have a suitably open definition of “network abuse” that covers spamming, hacking,
phishing, running botnets, etc as grounds for takedowns. It is important you act on
this, swiftly and with zero tolerance. You want to cultivate a reputation among the
criminal underground that it’s not worth the effort to try setting up shop on your
system. There will always be exceptions who will want to try. Shut them down in
rapid, spectacular fashion. Send a message.
• Decide what your legal threshold is to take action from third party requests and
enforce it. For example, on a domain that is not otherwise violating your terms of
service and is not subject to a UDRP proceeding, require a court order in a com‐
petent jurisdiction (yours).
• Law Enforcement Agencies should be used to following due process. The ones in
your own jurisdiction should come equipped with proper warrants, subpoenas or
court orders when requesting customer data. In foreign jurisdictions you are within
your rights to tell them to have their court orders, warrants or subpoenas enforced
in your jurisdiction.
48
|
www.it-ebooks.info
Chapter Summary
Hopefully this chapter has reduced the paralysis that can be induced once the full spec‐
trum of possible Top Level Domains available is fully comprehended. As venture cap‐
italist Rick Segal once quipped “Choice = Confusion = Inaction”. You can create a well
defined scope for your organizations’ domain name portfolio.
You should also have an understanding of rules that govern disputes. You’ll know how
to proceed against parties infringing on your IP rights. You’ll also know what to expect
and how to respond if a third-party makes a move against a domain owned by you or
your customers.
Chapter Summary
www.it-ebooks.info
|
49
You’ll be familiar with the aftermarkets and domain backordering that you’ll need in
the case of emergency claw-backs or even for those times when you your eye on that
perfect name that is coming up for expiry.
Finally you’ll have a general framework for constructing an Acceptable Use Policy that
can guide you through takedown requests, data sharing requests and other interactions
with the general public, rightsholders and Law Enforcement Agencies (LEA).
50
|
www.it-ebooks.info
CHAPTER 5
Managing Your Portfolio
Multi-Domain Architectures
Organizational Best Practices
The Domain Portfolio Audit
{ Appendix? }
Managing Customer Domains
Authentication
Security
Scaling
It may sound simple but there are various permutations of a plain vanilla “domain
transfer”, the phrase can have very different connotations to different parties, and to
make matters even more complicated, any given “transfer” can involve one or more of
these disparate meanings within the same “transaction” or operation.
In other words, a domain transfer could refer to:
• Changing the “owner” of a domain name from one entity to another (“Change of
Registrant”)
51
www.it-ebooks.info
• Moving a domain from one Registrar to another (“Registrar transfer”)
• Changing the nameserver delegation of a domain name (“Nameserver redelega‐
tion”)
• Moving a domain name between user accounts within a Registrar, Web Provider,
Managed DNS Provider or similar (“domain push”)
Change of Registrant
This refers to changing the “owner” of a domain name.1
In the olden days (during the Network Solutions monopoly) this was considered a nontrivial undertaking and required sending in a notarized piece of photo ID and cost
somewhere in the neighborhood of $150 to process.
Now in its simplest form this is just a matter of navigating to your Registrar’s control
panel, finding the place where you edit your domain’s “Whois Settings” and change it.
But there is still more to it if the reason for the change is because the domain is being
sold or transferred from one entity to another. In such cases refer back to the “Domain
Aftermarket” section of Chapter 5.
Nameserver Redelegations
A change of nameserver delegation is the act of moving a domain’s DNS settings from
one set of nameservers to another. There are two permutations to this operation:
1. Changing the delegation and changing the primary master for the domain.
2. Changing the delegation while preserving the primary master for the domain.
In the first case the approach is simply to setup the new environment in stealth (meaning
the zone is live on the new nameservers but they are not receiving any queries) and then
pick a “band-aid moment” when you throw the switch and cut everything over to the
new delegation:
1. Eetup new master nameserver, modify the NS RRset to reflect the new/incoming
nameserver delegation.
2. Setup the new secondaries as slaving their zone from the new master
3. Change the delegation for the zone at the Registry of the zone’s TLD
1. I always put “quotes” around “owner” because in various jurisdictions domain names can alternately be viewed
as “property” while in others (such as here in Canada) they merely convey “rights”. In either case, the domain’s
Registrant is the party who either owns the domain (if it’s property) or to whom the rights accrue.
52
|
Chapter 5: Managing Your Portfolio
www.it-ebooks.info
4. Leave the old nameservers up to answer queries for at least as long as the TTL for
the NS RRSET.
5. Finally, decommission the zone on the old nameservers and master.
The second case is a little more streamlined:
1. Setup the zone on the new nameservers
2. Modify your zone’s NS records to reflect the new nameserver delegation.
3. Update the nameserver delegation in the parent zone (usually parent TLD)
4. After NS RRSET TTL expires for the old nameservers, remove their NS records
from the zone.
The modifications to the NS RRSET are done with the DNS provider.
The nameserver delegation update is done via the Registrar for the zone (domain) will
which update the Registry with the new list of nameservers for the domain.
Most gTLD registries will modify the delegation without checking if you’ve actually
done this coherently and the new nameservers are authoritative for the zone. Many
ccTLDs will test the new nameservers first and will not implement the delegation if they
are not authoritative for the zone or if the NS RRSET for the zone being reported by the
new nameservers do not match the new delegation.
Redelegating DNSSEC signed domains
In the above situation there may be an interval of time in which some resolvers receive
data which is not entirely consistent, but gets the job done from the client’s perspective.
For example, the resolver may obtain a referal to the old NS RRSET from the root servers
for the domain, and upon following the glue to an old authorative nameserver, end up
seeing an NS RSSET with additional data (the new NS RRSET coming into effect). This
isn’t a big deal …until you are dealing with DNSSEC, and then it is.
Now, with DNSSEC (see Chapter 2_11) you have to effect this nameserver delegation
in a way where ideally the trust chain will not break.
Changing the nameserver delegation for a DNSSEC signed zone should proceed along
the following lines:
1. New DNS provider generates a new ZSK
2. Old DNS provider generates DNSKEY signatures with old KSK over both the old
and the new ZSK .
Before the NS records (and the delegation) can be changed to the new DNS Provider,
the following steps should be all resolvers need have a clean cache or else they have to
www.it-ebooks.info
|
53
have a DNSKEY RRSet which has a signature made by the old KSK over both the old
and the new ZSK.2 Then, all of the DS Keys have t reference the new KSK.
Registrar Transfer
Registrar Transfer and Nameserver Redelegation
2. Changing DNS Operators for DNSSEC signed Zones draft-koch-dnsop-dnssec-operator-change-06 https://
tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-06
54
|
Chapter 5: Managing Your Portfolio
www.it-ebooks.info
CHAPTER 6
Common Pitfalls
Domain Slamming
The term “slamming” owes its ancestry to the practice of “telephone slamming” where
a subscribers phone service would be unwittingly transferred to another telecom pro‐
vider. In our context it means having your domain name transferred to another domain
Registrar without the Registrant explicitly intending to do so, or understanding that it
has occurred.
This is particularly pernicious in the context of domain slamming because it is fairly
common that the DNS service for a victim domain can stop operating in the course of
the transfer (see “Domain Transfers” in preceeding chapter) and thus take the domain
offline.
Domain slamming works by mining whois data for domain contact information and
then sending “notices” or what appears to be invoices to those contacts. Billing depart‐
ments unwittingly complete these forms and remit payment, and in the process trigger
the initiation of a domain transfer.
Phishing
Unintentional Expiry
The Domain Expiry Cycle
Domain Scams
Anywhere you find readily available data that is for the most part wide open to harvesting
and mining, the scams are not far behind.
55
www.it-ebooks.info
Because domain names are listed in Whois databases, that information is frequently
used against you in nefarious attempts ranging from socially engineering toward gaining
unauthorized access somewhere, to tricking targets into paying for vaporware or out‐
right fraud attempts.
The various domain related vectors are outlined below, we still see these passed onto us
by our customers every day.
The “Foreign Infringer” Scam
This is simply an attempt to entice registrants under one TLD to register (“defend their
marks”) in some other Top Level Domain which they would usually have no interest in
doing. The approach is to make the solicitation sound less like an advertisement and
more like a grave intellectual property affront.
Here’s a literal email I recieved recently:
Dear Manager,
(If you are not the person who is in charge of this, please forward this to your
CEO,Thanks)
This email is from China domain name registration center, which mainly deal with the
domain name registration and dispute internationally in China.
We received an application from Huaxing Ltd on August 11, 2014. They want to register
" esurveys " as their Internet Keyword and " esurveys .cn “危” esurveys .com.cn " 危”
esurveys .net.cn “危” esurveys .org.cn " domain names etc.., they are in China domain
names. But after checking it, we find “esurveys " conflicts with your company. In order
to deal with this matter better, so we send you email and confirm whether this company
is your distributor or business partner in China or not?
Best Regards,
Jim General Manager Shanghai Office (Head Office) 3002, Nanhai Building, No. 854
Nandan Road, Xuhui District, Shanghai 200070, China Tel: +86 216191 8696 Mobile:
+86 1870199 4951 Fax: +86 216191 8697 Web: www.yg-registry.cn
This could most accurately be summed up as follows:
Dear Sir, we datamined your contact details from the whois database and see that you
own esurveys.com. Would you like to also register esurveys.cn, esurveys.com.cn, esur‐
veys.net.cn, and esurveys.org.cn?
This is just a sales pitch, it’s not a matter of “life and death” intellectual property in a far
off land.
Aftermarket Scams
56
| Chapter 6: Common Pitfalls
www.it-ebooks.info
ICANN Suspensions
Whois Accuracy Program
Incorrect or Bad Whois Reports
DNS Failures
ICANN Suspensions
www.it-ebooks.info
|
57
www.it-ebooks.info
CHAPTER 7
Types of Nameservers
As distinct from various nameserver daemons, software or appliances (which we’ll look
at later in this section), nameservers can be typed by what kind of function the are
fulfilling.
Most of issues we examine in this book (namely, running DNS for a bunch of domain
names and making sure that anybody and anything that queries your domain names
always, reliably, obtains a valid response), involve three distinct “types” of nameservers
(as distinct from different nameserver daemons, which we’ll look at in 2-6).
They are:
1. Root Nameservers
2. Resolvers or Recursors
3. Authoritative Nameservers
Since you are reading this book, you are likely running the third type: authoritative
nameservers, that answer queries for specific domains. Your clients are of the second
type: resolvers are asking your nameservers for answers they will take back to their
applications.
The Root servers are required in order for the resolvers to know which authoritative
nameservers to send a given query to.
Root Nameservers
Also known as “Top Level Domain Servers”. These are specialized nameservers that can
be said to handle “nameserver delegations” for “Top Level Domains”. In other words,
these are specialized nameservers for the chunk of domain names to the right of the “.”
59
www.it-ebooks.info
- i.e. in the case of example.com, the relevant Root Nameservers would be the .com
nameservers:
~ markjeftovic$ dig +short -t ns com
f.gtld-servers.net.
m.gtld-servers.net.
d.gtld-servers.net.
e.gtld-servers.net.
j.gtld-servers.net.
h.gtld-servers.net.
i.gtld-servers.net.
c.gtld-servers.net.
a.gtld-servers.net.
b.gtld-servers.net.
g.gtld-servers.net.
k.gtld-servers.net.
l.gtld-servers.net.
Every Top Level Domain (that is every chunk to the right of the “.” in a domain name)
has it’s associated Top Level Nameservers, or Root Nameservers:
~ markjeftovic1$ dig +short -t ns ca
c.ca-servers.ca.
any.ca-servers.ca.
j.ca-servers.ca.
k.ca-servers.ca.
tld.isc-sns.net.
e.ca-servers.ca.
l.ca-servers.ca.
~ markjeftovic1$ dig +short -t ns mil
EUR2.NIPR.mil.
PAC1.NIPR.mil.
CON2.NIPR.mil.
PAC2.NIPR.mil.
CON1.NIPR.mil.
EUR1.NIPR.mil.
Here’s one of those new-fangled new gTLDs…
~ markjeftovic1$ dig +short -t ns website
d.nic.website.
a.nic.website.
b.nic.website.
c.nic.website.
And finally, the top node of the inverted-tree structure that forms the DNS is simply
“the root” or “.”
~ markjeftovic1$ dig +short -t ns .
b.root-servers.net.
d.root-servers.net.
a.root-servers.net.
m.root-servers.net.
60
|
Chapter 7: Types of Nameservers
www.it-ebooks.info
l.root-servers.net.
e.root-servers.net.
f.root-servers.net.
i.root-servers.net.
j.root-servers.net.
k.root-servers.net.
g.root-servers.net.
h.root-servers.net.
c.root-servers.net.
Nameserver Order
One thing you may notice when you look at these results, is that even
though a lot of these nameserver delegations appear to be named in
alphabetical or numerical order, they are not necessarily returned in
that order. It’s a commonly held fallacy that nameservers are quer‐
ied in listed order, they are not. We’ll learn more about why in Anat‐
omy of a DNS Query
Root nameservers are for the most part populated with “sub-delegations”, which are
nameserver records for all the child zones (otherwise known as a nameserver delega‐
tion, a nameserver subdelegation or a DNS delegation)
Looking at example.com again:
~ markjeftovic1$ host -t ns example.com
example.com name server b.iana-servers.net.
example.com name server a.iana-servers.net.
This means that the authoritative nameservers for example.com are b.ianaservers.net and a.iana-server.net. How did we find that out? By asking the .com Top
Level Nameservers
~ markjeftovic1$ dig -t ns @a.gtld-servers.net example.com
; <<>> DiG 9.8.5-P1 <<>> -t ns @a.gtld-servers.net example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58516
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;example.com.
;; AUTHORITY SECTION:
example.com.
example.com.
172800
172800
IN
NS
IN
IN
NS
NS
a.iana-servers.net.
b.iana-servers.net.
;; ADDITIONAL SECTION:
Root Nameservers
www.it-ebooks.info
|
61
a.iana-servers.net.
a.iana-servers.net.
b.iana-servers.net.
b.iana-servers.net.
;;
;;
;;
;;
172800 IN
172800 IN
172800 IN
172800 IN
A
AAAA
A
AAAA
199.43.132.53
2001:500:8c::53
199.43.133.53
2001:500:8d::53
Query time: 83 msec
SERVER: 192.5.6.30#53(192.5.6.30)
WHEN: Sat Sep 06 18:26:45 EDT 2014
MSG SIZE rcvd: 165
How did we know that a.gltd-servers.net was a Top Level Nameserver for .com? Be‐
cause our resolvers went out and asked the root “.” zone who the nameservers were
for .com, and then went and asked those nameservers for the nameservers for exam‐
ple.com.
In other words:
~ markjeftovic1$ dig +trace -t ns example.com
; <<>> DiG 9.8.5-P1 <<>> +trace -t ns example.com
.
517845 IN
NS
g.root-servers.net.
.
517845 IN
NS
f.root-servers.net.
.
517845 IN
NS
i.root-servers.net.
.
517845 IN
NS
b.root-servers.net.
.
517845 IN
NS
l.root-servers.net.
.
517845 IN
NS
k.root-servers.net.
.
517845 IN
NS
d.root-servers.net.
.
517845 IN
NS
a.root-servers.net.
.
517845 IN
NS
j.root-servers.net.
.
517845 IN
NS
h.root-servers.net.
.
517845 IN
NS
m.root-servers.net.
.
517845 IN
NS
e.root-servers.net.
.
517845 IN
NS
c.root-servers.net.
;; Received 496 bytes from 64.68.200.205#53(cns3.easydns.com) in 2678 ms
com.
172800 IN
NS
b.gtld-servers.net.
com.
172800 IN
NS
l.gtld-servers.net.
com.
172800 IN
NS
c.gtld-servers.net.
com.
172800 IN
NS
k.gtld-servers.net.
com.
172800 IN
NS
f.gtld-servers.net.
com.
172800 IN
NS
j.gtld-servers.net.
com.
172800 IN
NS
g.gtld-servers.net.
com.
172800 IN
NS
m.gtld-servers.net.
com.
172800 IN
NS
a.gtld-servers.net.
com.
172800 IN
NS
d.gtld-servers.net.
com.
172800 IN
NS
h.gtld-servers.net.
com.
172800 IN
NS
e.gtld-servers.net.
com.
172800 IN
NS
i.gtld-servers.net.
;; Received 489 bytes from 192.112.36.4#53(g.root-servers.net) in 3804 ms
example.com.
62
172800
IN
NS
a.iana-servers.net.
| Chapter 7: Types of Nameservers
www.it-ebooks.info
example.com.
172800 IN
NS
b.iana-servers.net.
;; Received 165 bytes from 192.26.92.30#53(c.gtld-servers.net) in 110 ms
example.com.
172800 IN
NS
b.iana-servers.net.
example.com.
172800 IN
NS
a.iana-servers.net.
;; Received 165 bytes from 199.43.133.53#53(b.iana-servers.net) in 131 ms
To find the authoritative nameservers for any given domain, your resolver has to start
at the root “.” domain, and iteratively ask each level what the nameservers are for the
next level (the chunk before the preceeding dot or the next “zone cut”), this process
continues until the resolvers know what nameservers are authoritative for the label being
queried.
Root Nameservers
www.it-ebooks.info
|
63
Wait! How does a resolver know what the “.” nameservers are?
That’s an excellent question, if the root “.” is the DNS equivilent of a “Buck
Stops Here” plaque on the president’s desk, how does one know where to
find the desk in the first place?
It’s called a “root hints” file, it’s a flat file that sits on a resolver’s or pretty well
anything running a nameserver’s local storage and contains the initial set of
hostname to IP address mappings for the “.” zone:
~ markjeftovic1$ cat /var/named/named.ca |less
;
This file holds the information on root name servers needed to
;
initialize cache of Internet domain name servers
;
(e.g. reference this file in the "cache . <file>"
;
configuration file of BIND domain name servers).
;
;
This file is made available by InterNIC
;
under anonymous FTP as
;
file
/domain/named.cache
;
on server
FTP.INTERNIC.NET
;
-ORRS.INTERNIC.NET
;
;
last update:
Jun 17, 2010
;
related version of root zone:
2010061700
;
; formerly NS.INTERNIC.NET
;
.
3600000 IN NS
A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.
3600000
A
198.41.0.4
A.ROOT-SERVERS.NET.
3600000
AAAA 2001:503:BA3E::2:30
;
; FORMERLY NS1.ISI.EDU
;
.
3600000
NS
B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.
3600000
A
192.228.79.201
;
; FORMERLY C.PSI.NET
;
.
3600000
NS
C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.
3600000
A
192.33.4.12
;
; FORMERLY TERP.UMD.EDU
;
.
3600000
NS
D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.
3600000
A
128.8.10.90
;
; FORMERLY NS.NASA.GOV
;
.
3600000
NS
E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.
3600000
A
192.203.230.10
;
; FORMERLY NS.ISC.ORG
;
.
3600000
NS
F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.
3600000
A
192.5.5.241
F.ROOT-SERVERS.NET.
3600000
AAAA 2001:500:2F::F
64
|
www.it-ebooks.info
In our discussion of Root Nameservers in the preceeding section, we were hinting at
both sides of a DNS lookup process. Those Root Nameservers were answering queries
and directing clients to the next level in the DNS tree, in most cases toward the Au‐
thoritative Nameservers - those servers who would ultimately answer “authoritatively”
the original DNS queries from the end-user application.
So what is on the other end of all these queries? Where are they coming from and what
is actually making them? That’s what this section is about.
Recall my original “elevator pitch” about how DNS works:
“Everytime you send an email, or visit a web page, type or receive an instant message,
text or SMS, place a VOIP call (or skype), or 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 to? What server is holding the file that this
web browser is asking for? Where is the VOIP gateway that needs to route this call?”
Well the computers that are actually asking these questions are the resolvers.
Resolvers are nameservers that find out answers to DNS queries that applications need
answered, and they report those answers back to those applications.
They will also cache the response for the amount of time specified in time-to-live (TTL)
for the record, so if the application needs to know this again anytime soon, it can provide
an answer out of it’s local DNS cache rather than going all the way out to the Root
Nameservers and then to the Authoritative Nameservers to find it.
If the individual response record has it’s own TTL attached, it will cache the response
for that amount of time, if not, it uses the default TTL as specified in the zone’s StartOf-Authority record (SOA):
$ORIGIN example.net.
@
IN SOA
604800 10800
@
IN NS
@
IN NS
@
IN NS
@
IN NS
dns2
600
docs
docs.sandbox
IN A
IN A
dns1.easydns.com. zone.easydns.com. 1409454364 43200 10800
dns1.easydns.com.
dns2.easydns.net.
dns3.easydns.org.
dns4.easydns.info.
198.41.222.254
205.210.42.47
IN A
205.210.42.45
Above we have a bind format snippet of a zonefile for example.net, we can see that the
global TTL for the entire zone, as defined in the SOA record is 10800 seconds, but the
A record for dns2.example.net has a TTL of 10 minutes (600 seconds).
www.it-ebooks.info
|
65
That means if a resolver asks one of the Authoritative Nameservers for example.net,
once it receives an answer it will cache it for 3 hours (10800 seconds) if it were to query
docs.example.net or docs.sandbox.example.net but only for 10 minutes if it had quer‐
ied dns2.example.net.
Of course, the details of those nameservers it would ultimately query (presumeably from
one of the nameservers from the listed NS records - and we’ll see why it’s “presumeably”
later) would also be cached locally and subject to TTLs defined in their parent zones or
RR sets.
You can see this in vivid detail from a simple “dig” command:
Marks-MacBook-Pro:temp markjeftovic1$ dig example.net
; <<>> DiG 9.8.5-P1 <<>> example.net
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19688
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 6
;; QUESTION SECTION:
;example.net.
IN
A
;; ANSWER SECTION:
example.net.
600
IN
A
216.220.40.250
;; AUTHORITY SECTION:
example.net.
example.net.
example.net.
example.net.
172448
172448
172448
172448
IN
IN
IN
IN
NS
NS
NS
NS
dns1.easydns.com.
dns4.easydns.info.
dns3.easydns.org.
dns2.easydns.net.
;; ADDITIONAL SECTION:
dns1.easydns.com.
dns1.easydns.com.
dns2.example.net.
dns3.easydns.org.
dns4.easydns.info.
dns4.easydns.info.
249
249
10448
22
42848
42848
IN
IN
IN
IN
IN
IN
A
AAAA
A
A
A
AAAA
64.68.192.210
2001:1838:f001::10
198.41.222.254
64.68.195.10
194.0.2.19
2001:678:5::13
;;
;;
;;
;;
Query time: 55 msec
SERVER: 64.68.200.205#53(64.68.200.205)
WHEN: Wed Sep 10 17:15:54 EDT 2014
MSG SIZE rcvd: 275
We see in the ANSWER SECTION what we actually queried and how much longer it
will be cached for in our responding resolver’s cache.
In the ADDITIONAL SECTION we see the details around the various Authoritative
Nameservers it has available to query, and we see the individual cache intervals left for
each one of them.
66
|
www.it-ebooks.info
Negative Caches
TODO - enter section on negative caches here - mjr
Resolvers are often effectively invisible to many end users. They are often assigned via
DHCP from your upstream connectivity provider. On the server side, they are defined
in /etc/resolv.conf and whatever is in there will be used to answer nearly all queries any
applications on a given server will originate.1
In other words, DNS resolution is often so far abstracted from both end-users and
application layers that until quite recently hardly anybody ever thought much about
them, unless they were DNS geeks or hapless sysadmins who had to debug resolution
issues.
This has been changing, in 2006 OpenDNS 2 launched DNS resolution as a service and
there have been a few other entrants into the space since, including Google’s Public DNS
3
.
The final component of the magical three-way lookup process that results in a successful
DNS lookup are the Authoritative Nameservers which actually hold the zonedata for
the domains being queried and that respond to those queries for domains and sub-hosts
they are authoritative for (is it just me or this an incredibly clumsy sentence? - mj)
Much of this book is specific to operating Authoritative Nameservers which is why
this sub-section may seem relatively scant compared to our look at Root Nameservers
and Resolvers.
Suffice it to say here that in broad terms, Authoritative Nameservers are often split into
two sub-categories, “masters” and “slaves” or else “primaries”, “secondaries” (and even
“tertiaries”, which really just means, “additional secondary”)
Primary Nameserver
The Primary Nameserver is the Authoritative Nameserver which contains the actual
zonedata from which all other nameservers obtain their copy. Traditionally, since the
vast majority of nameservers still run bind, this means it’s the nameserver that has the
1. add notable exceptions, postfix, etc
2. http://www.openDNS.com
3. https://developers.google.com/speed/public-dns/
www.it-ebooks.info
|
67
domain zonefiles on it’s local storage, and the nameserver daemon loads that data from
disk and into memory.
Hidden Primaries
In this day and age, especially when running DNS for large numbers of domains, it is
common to run what are called “hidden primaries or “hidden masters”
These are primary authoritative nameservers which are not listed in the various domain
delegations in those domains’ rootzones.
In other words, hidden primaries typically don’t receive DNS queries from rsolvers in
the outside world. They are just there to feed the zonedata out to the other secondary
(and tertiary) nameservers.
There are a few reasons you would want to do this, especially as the number of domains
under management goes up:
1. Your hidden primary could be inside a DMZ
2. It may employ some proprietary methods of organizing it’s zonefiles (i.e. enjoy close
access to internal databases)
3. You don’t want your source repository of live zonedata taking actual queries from
the outside world
4. You don’t want to expose the location (IP address) of your hidden primary to the
outside world
In practical terms what ends up happening with more regularity is that all of the public
facing authoritative nameservers end up being secondary nameservers obtaining their
data from hidden primaries.
68
|
www.it-ebooks.info
Hidden Primary “gotchas”
For reasons consisting (seemingly) of bureaucratic puritanism,
some Top Level Domains do not play nicely with domains utiliz‐
ing hidden primaries. Some of them insist, that as per RFC 1035 4,
the “mname” field of the SOA record (which we’ll look at in 2-3)
contain “The <domain-name> of the name server that was the
original or primary source of data for this zone.”
The problem is, when you’re employing a hidden primary you might
put something else in the MNAME field, or put a host there with
an internal IP because. Some ccTLDs will not delegate a domain to
your nameservers unless the MNAME field contains the host‐
name of a nameserver that is also defined amongst your NS re‐
cords for the zone and that they can query directly (because some
ccTLDs will actually want to test your nameservers that the do‐
main is setup ahead of time before they will delegate to it).
If you run into this, you have to adjust your systems to accommo‐
date this (i.e. here at easyDNS we have a data structure called $FIN‐
ICKY_CCTLDS which has the country codes for all the ccTLDs that
enforce this and we rewrite the SOA’s in those zones accordingly)
( TODO need to check if bind still skips NOTIFY - to mname’s if it
thinks it’s local - mj )
Secondary Nameservers
Secondaries are Authoritative Nameservers which obtain their copy of the zonedata
from the Primary Nameserver or Master.
If you are running bind, they typically do this via a zone transfer (known as an “AXFR”,
defined in RFC 5936) or an Incremental Zone Transfer (IXFR, defined in RFC 1995).
When a zone is reloaded on the Primary or Master Nameserver, it will send a NOTIFY
packet to each of the listed NS records for the zone (those are the Secondary Name‐
servers).
That said, the zone transfer mechanisms built into the DNS protocols itself owe their
origins to the early days of DNS and were developed in lieu of reliable, portable methods
for syncing data across servers, many of which exist today. Not the least of which are
SQL based backends.
It is not surprising then, that there are alternative methods for handling DNS syndica‐
tion across nameservers which blur the distinctions between Primaries and Secondaries.
As hinted above, you could use a nameserver with a database backend (i.e MySQL),
such as powerdns or bind-dlz with a mysql, postgres or other SQL backend. In those
4. https://www.ietf.org/rfc/rfc1035.txt
www.it-ebooks.info
|
69
cases your zone modifying processes would update the database backend which may be
a completely disparate server or storage cluster, and they may transmit those changes
to their Secondaries via database replication.
There have also been implementations where all nameservers use a file-based method‐
ologies, such as rsync, to incrementally copy zonefiles across to the Secondary Name‐
servers. This is the preferred methodology used by djbdns (a.k.a “tinydns”) and is
sometimes even used in bind implementations. Zonefiles can even be managed across
the nameservers by using source code repository tools such as git.
(Question: is this the place to have the larger conversation around syncing data between
servers or does it go someplace else?)
Other Nameserver Types
Forwarders
70
|
www.it-ebooks.info
CHAPTER 8
DNS Queries In Action
In this chapter we’ll explore the nuances of dns queries. Having an understanding of
the underlying mechanisms of the actual DNS queries themselves gives one increased
understanding and helps in troubleshooting and isolating problems.
Generally, DNS lookups occur of UDP, there are notable exceptions described below.
An actual DNS query packet can be represented as follows:
• there will be a pretty diagram here in the final version
Note the flags section, these will be of interest when we want to debug issues. You can
use the “dig” command to see these packet responses in more detail than is available via
other diagnostic tools (such as “host” or the historically disparaged “nslookup”)
QR - Query Response. This is set to 0 in a packet that is a question, and 1 in a response
packet that is an answer.
AA - This flag is set in a response by the nameserver when it is answering authoritatively
for the hostname that was queried.
RD - Recursion Desired. If set to one, the querying nameserver is asking the remote
nameserver to resolve the query recursively. It is important to understand that if the
nameserver being queried is an authoritative nameserver for the hostname being quer‐
ied, it wouldn’t (or shouldn’t) do recursion, so it will set this bit to 0 in it’s response.
TC - Truncate. This will be set to 1 if the response packet is larger than 512 bytes. See
“Large Responses” below.
You may notice in your diagnostic travels when something like this happens:
$ dig oreilly.com @NSAUTHA.OREILLY.COM
...
; <<>> DiG 9.8.5-P1 <<>> oreilly.com @NSAUTHA.OREILLY.COM
71
www.it-ebooks.info
;;
;;
;;
;;
Got answer:
->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59374
*flags: qr aa rd;* QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
*WARNING: recursion requested but not available*
One circumstance this affects is when you are querying a hostname that is a CNAME
(Alias), and the destination (RDATA) of that CNAME is under another domain that
has it’s authoritative nameservers elsewhere.
In other words, given:
cname.managingmissioncriticaldomains.com IN CNAME www.oreilly.com.
If you query one of the authoritative nameservers for the LHS directly and set the RD
bit when you do, you will receive an NXDOMAIN response:
$ host cname.managingmissioncriticaldomains.com dns1.easydns.com
Host cname.managingmissioncriticaldomains.com not found: 3(NXDOMAIN)
And yet, the record seems to be resolving…
$ host cname.managingmissioncriticaldomains.com
cname.managingmissioncriticaldomains.com is an alias for www.oreilly.com.
www.oreilly.com is an alias for www.oreilly.com.edgesuite.net.
www.oreilly.com.edgesuite.net is an alias for a629.g1.akamai.net.
a629.g1.akamai.net has address 184.150.157.154
a629.g1.akamai.net has address 184.150.157.105
Because when we don’t specify the nameserver in our lookup and query the authoritative
nameserver directly, we end up going via our local resolvers, and those resolvers will
know not to set that bit when they query the authoritative nameserver.
However, most command line diagnostic tools will set the RD bit by default, thus gen‐
erating spurious support pages at 3am when one of your users is trying to debug some‐
thing and thinks that it’s a DNS problem when they try this.
The way to do it that best mimics what a resolver will actually do is to make sure you
unset the RD bit in your query:
$ host -r cname.managingmissioncriticaldomains.com dns1.easydns.com
cname.managingmissioncriticaldomains.com is an alias for www.oreilly.com.
$ dig +norecurs +short cname.managingmissioncriticaldomains.com @dns1.easydns.com
www.oreilly.com.
As previously mentioned, most of the time DNS happens over UDP. It’s lightweight and
faster than TCP. There have been tradeoffs as a result of the design decision (it’s easier
72
|
Chapter 8: DNS Queries In Action
www.it-ebooks.info
to spoof UDP packets, so you have to worry about things like cache poisoning or DDoS
attacks involving forged packet headers)
But nameservers still need to be available on TCP as well as UDP.
Zone Transfers Happen Over TCP
The AXFR and IXFR methods of transferring updated zone data from the master to it’s
secondaries occur over TCP, as may the SOA preamble.
An SOA Preamble is distinct from a normal SOA query in that the former is a query
sent by a secondary authoritative nameserver to its master in anticipation of the sub‐
sequent zone transfer. Some clients open a TCP session (the same one they will use to
transfer the zone if needed), while others do the preamble over UDP and then only open
a TCP session of the zone transfer is required. (An SOA preamble is simply when the
secondary sends it’s current copy of the SOA to the master where the serial is compared
to the master’s, if they match then no update is required. If the master’s serial is higher
then a zone transfer ensues.)
Large Responses, EDNS and DDOS Mitigation (Oh My!)
If the response to a query is larger than 512 bytes then the TC flag is set and this should
signal the client / resolver to retry the query over TCP.
Example, it is possible in this context to have “too much redundancy” in your name‐
server delegation by simply adding so many that the response to a query is larger than
512 bytes:
When running a lookup via dig or host you will see a warning that the retry over TCP
will occur:
$ dig -t ns managingmissioncriticaldomains.com @dns1.easydns.com|less
;; Truncated, retrying in TCP mode.
...
;; Query time: 38 msec
;; SERVER: 64.68.192.210#53(64.68.192.210)
;; WHEN: Thu Dec 11 10:52:30 EST 2014
;; MSG SIZE rcvd: 589
<- note the size of the response
There exists one use case where the TC bit is set even if the reponse is under 512 bytes
and involves no EDNS extensions, and that is during a DDoS attack against your name‐
servers. One common mitigation strategy is to reply to all queries with the TC bit set
so that all clients are signaled to retry over TCP. The logic behind this is that only the
real/legitimate resolvers will actually retry. If participants in the attack also retry, it will
occur over TCP and be easier to filter. Usually the first response forcing the retry is sent
by a firewall or other mitigation appliance, not the nameserver itself.
www.it-ebooks.info
|
73
Anatomy of a DNS Query: How Nameserver Selection
Actually Works
One of the more commonly held fallacies about nameservers concerns what order
nameservers in a given delegation are queried.
Take our archetypical example.com with a delegation as follows:
ns1.example-dns.com
ns2.example-dns.com
ns3.example-dns.com
ns4.example-dns.com
Many people think the nameservers will be queried in that literal order, and redundancy
comes about when and if the first listed nameserver is unavailable (ns1.exampledns.com), then the next one is queried (ns2.example-dns.com), and so on. In other
words, it is not uncommon to assume that nameserver selection works somewhat how
MX record selection is supposed to work, in that they are ostensibly 1 used in order of
preference and availability.
But that isn’t what happens.
What really happens when a resolver needs to query a record it doesn’t have cached
already, is it starts at the roots (using it’s root hints to find those) and obtains the name‐
servers for the record’s superdomain. It then obtains the nameservers for that super‐
domain and (let’s assume the record being queried is within that superdomain) it does
something many people find unexpected:
It asks every one of the listed nameservers the same query
It then times how long it took to get an answer back from each nameserver (RTT or
Round-Trip Time) and it remembers which nameserver replied the fastest. It then re‐
members that for future reference and favors the fastest nameserver in subsequent
queries.
To facilitate an approximate “load balancing”, it gradually increments the RTT score
each time it queries the current authoritative nameserver; eventually that score surpasses
the next-best RTT result and the resolver starts using that nameserver instead. If the
currently in-use authoritative nameserver times out or SERVFAIL’s on a query, the re‐
solver penalizes its score heavily, making it use another one from the authoritative set
right away.
1. I say “ostensibly” because anybody operating mail servers knows that mail can and will arrive at backup mail
spoolers even when the primary MX handlers are online and available
74
|
Chapter 8: DNS Queries In Action
www.it-ebooks.info
Summing Up
The main takeaways from this chapter should be:
• an understanding on the interplay between UDP and TCP, why your nameservers
are required to respond on both
• knowing the important query response flags and what the ramifications are when
a given one is set or not.
• an understanding of nameserver selection and how DNS queries progress from the
roots through the authoritative servers.
Summing Up
www.it-ebooks.info
|
75
www.it-ebooks.info
CHAPTER 9
Types and Uses of Common Resource
Records (and some not-so-common
ones…)
Good overview of all the RR’s can be found on the Wikipedia page: http://en.wikipe
dia.org/wiki/List_of_DNS_record_types.
We won’t list them all here, we’ll cover the common ones and the less known ones that
you will eventually run across.
This section does not purport to deconstruct and define the RR types in exhaustive
detail. Both Cricket Liu’s DNS and Bind as well as Ron Aitchison’s exchaustive Pro DNS
and Bind 10 do superb jobs of this. The latter also provides a comprehensive open
source resource “DNS For Rocket Scientists”.1
What we will concentrate on here are the “things to know” when using these record
types, considerations when managing large portfolios of domains and how that affects
a given record type.
We always plan our record naming conventions and strategies with 2 things in mind:
outages and changes.
A / Hostnames
Hostname / A records could very well be the most commonly used Resource Record in
DNS. These records quite simply map a hostname to it’s IPv4 address (IPv6 addresses
are mapped via “AAAA” records, see below).
1. http://www.zytrax.com/books/dns/
77
www.it-ebooks.info
The Left Hand Side (LHS) of the record specifies the hostname. If the label is not ter‐
minated with a trailing dot, the current $ORIGIN is appended to it. (This is one of the
more common DNS configuration errors, leading to records seemingly inexplicably
disappearing, only to resurface in the form of www.example.com.example.com).
In other words, given:
$ORIGIN example.com.
www
IN
A
192.168.1.1
;
; maps www.example.com to 192.168.1.1
www.example.com.
IN
A
192.168.1.1
;
; also maps www.example.com to 192.168.1.1
; but
;
www.example.com
IN
A
192.168.1.1
;
; creates an hostname called www.example.com.example.com!
It is legal to specify multiple labels as A records with different IP addresses. Doing so
creates a round-robin set for the label (see the Round Robin section in DNS Use Cases)
It is also legal to have additional RR types with the same label as an A record (and in
some cases, a requirement):
• If your nameservers are in bailiwick then there must be corresponding A records
for each NS record within the zone.
• When creating Mail Exchangers (MX records) the Right Hand Side (RHS) will need
an accompanying A record - whether it’s inside the current zone or an external one.
(It cannot be a CNAME nor can it be a naked IP address).
• TXT records frequenly correspond to a matching A record, such as SPF data or
validation strings for third party integrations.
• Your SOA record will most usually have a matching A record, often corresponding
to the zone’s apex.
CNAME/ Alias
The CNAME or Alias is a “canonical name” - the easiest way to understand it is as an
alias for “the actual name”2
2. Ron Aitchison’s Pro DNS & Bind 10 explains “canonical” as “the genuine or expected name”
78
|
Chapter 9: Types and Uses of Common Resource Records (and some not-so-common ones…)
www.it-ebooks.info
Given:
web.example.com.
IN
CNAME
www.example.com.
It would mean that web.example.com “is another label for” www.example.com. In prac‐
tical terms it means that when a resolver does a lookup on web.example.com and gets
a CNAME in response, it will restart the query process using the alias (www.exam‐
ple.com)
The most important thing to know about CNAMEs is that there can be no other RR’s
present within a zone with the same label or nodename as a CNAME. That is, the LHS
of a CNAME RR must be unique and there can be no other RR’s with the same hostname,
or label. (The only exception to this rule is in the case of DNSSEC signed zones, see the
section on DNSSEC).
In other words this:
www.example.com.
www.example.com.
IN
IN
CNAME
MX
example.com.
5 mail.example.com.
Will hose your DNS, and about the only processes that are going to be emailing ad
[email protected] are probably broken scripts anyway (but it’s not uncommon
to see this error).
This also means you cannot round-robin CNAME records:
ca.php.net.
ca.php.net.
IN
IN
CNAME
CNAME
ca1.php.net.
ca2.php.net.
The above example is a real life use case by PHP.net, which we’ll cover more in the Geo
DNS section of “DNS Use Cases”.
This “CNAME cannot have other data rule” is probably the one rule the most people
wish they could break. The most common reason why is because a lot of people really
which that they could alias their domain apex to another hostname.
The motivations for doing this are often credible: like hosting your domain on a thirdparty application platform or on a content-delivery network (CDN), life would be so
easy if you could just do this:
; quick and dirty point your domain at your Content Delivery Network (CDN)
; too bad it will blow up your DNS
example.com
IN CNAME
example.com.some.network.cdn.
Suffice it to say that demand for these capabilities has become so widespread that more
than one DNS provider (including easyDNS) has come up with ways to delicately break
the rule, and at least one nameserver daemon is coming out with native support for
domain apex aliasing. (See “Domain Apex Aliasing” section of “DNS Use Cases” Chap‐
ter).
CNAME/ Alias
www.it-ebooks.info
|
79
When to use Aliases vs Hostnames?
This can be hotly debated. Within a single zone it’s often customary to create the zone
apex as an A record and then alias “www.<domain>” to the apex. That way if the IP
address ever changes, you need only update one record in the zone.
This begins to make a bigger difference as you start to scale your portfolio. Suppose
you’re running a content delivery network or a web hosting farm and you’re stacking
up hundreds or thousands of domains per IP address or hostname for your application.
Strategic use of CNAMEs can make your life a lot easier, and in extreme cases, save your
butt. Consider the scenario where you have 5000 client hostnames on a shared hosted
application on a single IP address.
If you’ve setup your application on an IP:
voip.voips-r-us.dom. IN A 205.210.42.89
If you have each record setup as a hostname:
$ORIGIN example.com. voip.example.com. IN A 205.210.42.89
$ORGIN thosegermans.de. voip.thosegermans.de. IN A 205.210.42.89
and you have thousands of these out there, what do you when 205.210.42.89 blows up
and you end up having to renumber onto 205.210.41.30 ? Imagine that you’re not even
in control of the DNS for a sizable chunk of these client domains? You’ve got a serious
problem on your hands.
Through the strategic use of CNAMEs you can handle it all in one update:
Either in single step:
$ORIGIN example.com. voip.example.com. IN CNAME voip.voips-r-us.dom.
or if your setup is more complicated:
$ORIGIN voips-r-us.dom. server-a IN A 205.210.42.89 voip.example.com.voips-rus.com. IN CNAME server-a.voips-r-us.dom.
then for all clients:
$ORIGIN example.com. voip.example.com. IN CNAME voip.example.com.voips-rus.com.
You can now move your entire client base around without requiring them to update
their DNS settings. This is desireable because from experience I can tell you that in many
cases once you get your client to implement the DNS settings required for your app (i.e.
nameserver delegations) they will frequently ossify that way, remaining in place and
immutable for the remaining lifespan of the domain name.
80
| Chapter 9: Types and Uses of Common Resource Records (and some not-so-common ones…)
www.it-ebooks.info
The MX Record
The mail exchanger record (a.k.a “MX record “or “MX handler”) was originally defined
in RFC 1035.
If you look at an email address you see it has two parts divided by an @sign. The left
hand side sign is the recipient and the right hand side is the hostname or a domain name
of that recipient’s logical mailbox. So [email protected] means that you are sending
an e-mail to the recipient Mark (that is me) @easydns.com.
The MX record tells other mail servers where to send that email destined for
easydns.com.
In DNS parlance it would look like this:
easydns.com. IN MX
mxspool.easydns.com.
5
mail.easydns.com.
easydns.com.
IN
MX
10
The mail server itself sorts out what to do with the email it receives addressed to the
recipient and how to process the messages. They may get forwarded somewhere, it may
get expanded out into multiple recipients or sent through a program. Or silently dis‐
carded.
At the DNS level what we are concerned with here is the right hand side of the address,
the hostname. That is what MX records describe. Basically, when an MTA sends an email it does a DNS lookup for the hostname part of the email address and will get back
one or more mail exchangers as a result. Then it will try deliver the e-mail to the mail
exchanger with the lowest preference number.
Preferences, Priorities and Delivery Order
You’ll notice that MX records have an extra field for “Preference”,
which is also known as “Priority” in some circles (PowerDNS, for
example, usually refers to it the latter).
The important thing to know is that remote mail servers will at‐
tempt delivery to the MX handlers in ascending order of the prefer‐
ence. In other words, the lower the “preference” number, the higher
it’s “priority” is. This is also sometimes described as “distance”, which
does make it somewhat more intuitive if you think in terms of MTA’s
preferring to attempt delivery to the shortest distanced MX handler.
If the originating (or intermediary) mailserver cannot deliver the email to the most
preferred MX handler, either because it cannot connect or if it receives a “soft” error 3
3. soft errors mean the failure is temporary and should be retried later, wheras a hard error means the error is
permanent and and a non-delivery announcement should be returned to the sender
The MX Record
www.it-ebooks.info
|
81
it will attempt deliver it to the next highest preference - and those are known as the
backup mail spool, or “backup MX”
There are a couple of things to know about backup MX handlers:
One is that once you define a backup MX, it is going to end up receiving a certain amount
of email for your destination even if the main mail handler is up and functional. It’s just
one of those things that could be caused by nearly anything, like any kind of transient
network glitch; - also spammers may try to use the backup mail exchanger to inject
spam “through the backdoor” into a given mail host.
The other thing you have to understand is that defining a backup mail exchanger in the
DNS for a zone doesn’t magically convey backup MX capabilities onto the server that
is defined as the backup MX . That server actually, has to be configured to accept mail
for those domains. This is out of scope of DNS but it’s something you have to be aware
of. You can’t just define a backup MX and expect it to work .
A couple of special case MX-isms:
If there is no MX record present, the protocol is to try to deliver the email to the A
record in the destination. For example an email is sent to [email protected] but let’s
say antisocial.dom has no MX records, it will then do an A record lookup for antiso‐
cial.dom and attempt delivery there.
There is also the special case of the “null MX” which is usually defined as a “.” and that
means “no email for this domain”, in other words, email for it goes nowhere.
You would probably define that in conjunction with the SPF record in the domain that
disavows all email that is claimed to originate from it and that is basically how you can
signal to the world that a given domain has absolutely no email associated with it at all:
antisocial.dom.
IN MX
0 .
; Translation: Don't talk to me!
antisocial.dom.
IN TXT "v=spf1 -all"
; Translation: I'm not saying anything to anybody!
Pro Tip
If you are managing large numbers of domains, perhaps as a do‐
main registrar or web hosting provider, it’s a goood practice to make
something like this a standard component of your default DNS tem‐
plate. That way your users are not receiving random spam directed
at newly minted domains, and those same domains are insulating
themselves from any autobot spam that may forge their envelopes.
In other words, turn on your email signalling within the DNS when
your end user specifically wants it on, don’t enable it by default.
82
|
www.it-ebooks.info
The SOA record is the “start of authority record”. An SOA RR must be present in every
zone at every zone cut. What it does is to signal basic information about the zone to
other name servers. Primarily it signals to other name servers information about how
long to cache data about the records inside this zone.
What is a “Zone Cut”?
DNS orders itself in an “inverted tree” hierarchy, flowing down from the “.” root at the
top, through the root-level domains (.com, .net, .org, .ca, etc) and then through the
various domain names and subdomains.
A zone cut occurs when a subdomain of the current level is sub-delegated to different
nameservers.
In other words, if example.com creates a subdomain www.example.com, but does so
within the current zone, using the same zone $ORIGIN and thus on the same name‐
servers as example.com, there is no “zone cut” (but there is one between the .com root
and the example.com sub-delegation).
If however, there is a reason to sub-delegate www.example.com away to different name‐
servers than those that are authoritative for example.com, a zone cut has occurred.
The Right Hand Side (RHS) or “rdata” of an SOA record consists of 7 fields:
1. originating nameserver
2. the responsible person
3. serial
4. refresh
5. retry
6. expire
7. minimum
$ dig +short -t soa oreilly.com
nsautha.oreilly.com. nic-tc.oreilly.com. 201202488 600 1800 604800 3600
Originating Nameserver
This is supposed to be the hostname of the originating master nameserver, the primary
nameserver from which the secondaries slave the zone. Some country code registries
will complain if this hostname is not part of your nameserver delegation, as will some
DNS diagnostic tools.
www.it-ebooks.info
|
83
Point of Contact
This looks like a host name but if you translate the first dot as an @ sign you’re supposed
to wind up the e-mail address of the responsible person for the zone. In our example
SOA for oreilly.com, the point-of-contact address would then be [email protected]
Serial
The Serial number is the most important field here because when the serial number
increases it means that the zone has been updated. It’s the value in this field being higher
than what the secondaries have locally that signals them that there has been an update
on the master nameserver and that the secondaries need to refresh.4
There are a few different methods of formatting the serial number:
Date based:
YYYYMMDDNN This is the “standards compliant” method of specifying the serial,
which corresponds to the current date with the last field (NN) being the numeric iter‐
ation of a zone being loaded for that day.
Unix timestamp
This is my preferred method, where you simply use the 32-bit unix timestamp of the
moment you generate the zonefile from whatever process you have doing so.
Raw count
Alluded to in the original RFC 1035, this just starts at 1 and simply increments a raw
count whenever the zone is updated.
Again, some DNS diagnostic systems have an opinion on this and if you get enough
DNS geeks in a room and add alcohol you can ignite a low intensity war around the
“best format” for this one field. In reality it’s pointless. Make sure it increments every
time you update the zone. That’s it.
When the format of the Serial actually matters
Aside from every time you update the zone, conflicting formats of the serial number
can become an issue when you are moving domains between nameserver delegations,
moving masters or adding secondaries. If your master is using one format (i.e. Unix
timestamp) and your new secondaries are using Date based, you can wind up with the
4. A common mistake (when hand editing zones) is to make changes to your zone file but neglect to increment
the serial number. After reloading your primary nameserver, the secondaries never reflect the updates.
84
| Chapter 9: Types and Uses of Common Resource Records (and some not-so-common ones…)
www.it-ebooks.info
latter never refreshing the zone because it thinks it’s current copy is more recent than
the master:
find an example log entry here
What you can do in these situations is force an unconditional “retransfer” to the sec‐
ondaries.
You can do this in bind with an “rndc retransfer” command:
/usr/sbin/rndc retransfer example.com
The Refresh interval
This is how long your own secondary name servers should hold on to the zone before
they check their master for an updated serial. This number should err are on the side
of longer, especially if the number of zones under management is large. If you have
thousands or hundreds of thousands of zones under management and this interval is
too short, then you may end up with a bottleneck as at any given time you have a lot of
SOA preambles in progress for zones checking if they have been updated.
Once the use of the NOTIFY packet was widely implemented, we don’t have to be so
rigourous about checking. The master will let us know when an update happens. If we
are using an alternative nameserver such as powerDNS with database replication or
tinydns copying zones to secondaries via rsync, then it becomes largely moot.
The Retry interval
This next value controls how soon a secondary should retry a refresh if the refresh didn’t
work the first time.
Again, both of these values, in practice, are becoming increasingly superseded now that
master nameservers send NOTIFY packets (if they aren’t using some other method of
syncing data entirely).
The Expire Interval
The next value is the expire interval; this is how long an authoritative nameserver should
hang on to the zone and keep answering authoritatively for queries about it even if it
can’t check to see if the master has been updated. Again we err to the side of longer,
most of the time. 10 days to two weeks are common values, sometimes even a month.
It means that if the master nameserver is down or unreachable, the remote secondaries
will keep answering authoritatively out of it’s local copy of the zone until that expire
interval elapses.
www.it-ebooks.info
|
85
After that interval the secondary will make a fateful assumption, that the copy of the
zone it has is now stale or out-of-date, and it will drop its local copy and cease answering
queries about the zone. Or more accurately, it will reply with NXDOMAIN (not found).
The Minimum (a.k.a Time To Live)
This is how long resolvers (a.k.a recursors, non-authoritative nameservers) will keep a
reply from an authoritative nameserver in its local cache, and answer subsequent queries
for those records from its local cache, before it will refresh the records from one of its
authoritative nameservers.
Contrast Expire with Minimum: the former governs how long an authoritative slave or
secondary will continue replying authoritatively from its local cache before discarding
it as stale; while the latter controls how long third-party clients such as resolvers and
recursors will answer subsequent queries from it’s local cache before refreshing from
one of the zone’s authoritative nameservers.
You need to pay attention to this when planning migrations, cutovers, maintanence
windows and the like. The most misunderstood aspect of this value is that it needs to
be set to your desired value before your “event”, not at the same time.
In other words: you are going to move www.example.com from it’s current datacenter
10.0.2.34 to a new IP address in a new datacenter at 192.168.5.50. You want the traffic
to move from the old one to the new one as fast as possible.
The SOA record before your scheduled maintainece window may look as follows:
Marks-MacBook-Pro:tmp markjeftovic1$ host -t soa example.com
example.com has SOA record sns.dns.icann.org. noc.dns.icann.org. 2014121611 7200 3600 1209600 8640
The current Minimum is thus 1 day (86400 seconds). Once you spin up the new web‐
server you want as much traffic as possible to stop hitting the old one as fast as possible.
A common error is to change the SOA minimum at the same time that you change the
IP address of www.example.com and reload the zone. This will not have the desired
effect.
You need to do it in two steps:
First you lower your Minimum to your desired value, say 300 seconds (5 minutes) or
even 60 seconds.
Then after waiting for a longer interval than the previous TTL to elapse you go back and
change www.example.com to its new value.
Only then, when all resolvers and recursors are already primed with their lower TTL,
will they refresh their copy of the www.example.com RR in your desired timeframe
(excepting broken resolvers, of which there are many, which will ignore your TTLs and
keep the old IP and keep serving it anyway. You have no control over that.)
86
|
www.it-ebooks.info
Can You Just Set Your Minimum To 0 So All Your DNS Changes Will Propagate Like Greased
Lightning?
You could do that. By doing that you are telling all client resolvers and recursors to not
cache your zone (or specific RR’s within the zone) and come back and ask one of your
authoritative nameservers every single time they get a query for it.
It’s expensive to do that, not only in the “engineering-speak” meaning of “expensive”, in
that every query has to go through the entire lookup process all the way up to the
authoritative nameservers (see “Anatomy of a DNS Query”)
But since many commercial DNS providers charge by the query (usually in terms of
cost-per-million), it can be literally, expensive.
NS / Nameserver
The NS RR provides a list of the authoritative nameserver hostnames for the current
origin. You can also specify authoritative nameservers for a sub-delegation (zone cut)
by entering a subdomain in the LHS of the NS record:
$ORIGIN example.com. IN NS ns1.example.com. IN NS ns2.example.com. ; authori‐
tative nameservers for the current origin (example.com)
subzone IN NS dns1.example.net. subzone IN NS dns2.example.net. ; delegation of
subzone.example.com to other nameservers
In bind9 when you increment a zone’s serial number and reload it, NOTIFY packets
will be sent to each listed NS RR in the current zone, along with any other IPs listed
either in a global or zone’s also-notify option.
If the NS RR’s are within the current zone (“in bailiwick”) then there must be present
corresponding A (and optionally AAAA) records to “glue” the nameserver hostnames
to their appropriate IP addresses.
In our preceeding example, the nameservers for example.com are “in bailiwick” while
those for subzone.example.com are “out of bailiwick” (because the nameservers for
subzone.example.COM are both under the example.NET domain). We’ll look more at
this in the section “Nameserver TLD redundancy”.
TXT / Text Records
The data section of TXT records contain freeform text data which were historically
comments, but have since evolved into specialized “add-on” purposes that take on a type
of pseudo-record functionality or contain meta-data.
Examples include:
NS / Nameserver
www.it-ebooks.info
|
87
• Sender Policy Framework data (SPF)
• Domain Keys and DKIM
• DMARC data
The TXT data can be any length, however if it is larger than 255 characters it must be
chunked into miltiple strings of 255 chars or less. Further, care should be taken on the
size, if it is over 512 bytes then you will force queries into TCP retry mode, which incurs
additional overhead.
SPF Records
We mention SPF records here because the use of Sender Policy Framework (SPF) data
became so widespread it eventually received it’s own RTYPE (defined in RFC 4408),
alas it was later deprecated in RFC 72085
The important thing to know is that SPF-aware MTAs will always look for and process
SPF data found in the applicable TXT records, while only maybe look for it in an SPF
record. In other words, the SPF RR Type is an evolutionary dead-end. Even though
some versions of the bind package’s named-checkzone still throw warnings about SPF
RR Type data being missing:
zone example.com/IN: 'example.com' found SPF/TXT record but no SPF/SPF record found, add matching
You’re best off keeping your SPF data within TXT records and if you haven’t already
made provisions for SPF RR Types in your architecture, you can safely ignore them.
They are mentioned here because it is not widely known that the SPF RR Type has been
deprecated.
SRV
SRV records are like a Swiss-Army Knife for DNS.
Calling all web browser developers
Want to change the world?
Make the internet a better place?
Improve humanity?
Then put SRV rec support into the browser you are working on
Really. This would be a game-changer. If just one of the “big ones” (Chrome, Firefox,
Safari, Opera et al) added support for SRV record lookups then the others would quickly
5. HOWTO - Define an SPF Record http://www.zytrax.com/books/dns/ch9/spf.html
88
|
www.it-ebooks.info
follow suit and Things Would Be Different (in a good way). See “In a Perfect World,
Browsers Would Support SRV Lookups” sidebar in the URL Redirects section of the
Pseudo Record Types chapter)
SRV records can be thought of an all purpose “MX-like” record that can convey pref‐
erences and weightings of hostnames that are available to provide specific services be‐
yond SMTP.
The format of a SRV record is:
<_service>.<_protocol>.<name> <TTL> IN SRV <priority> <weight> <port> <target>
Where:
_service is the symbolic name of the service, such as _sip, _ldap, _autodiscover, etc.
taken from IANA service names list (formerly Assigned Numbers STD-2) or a local
label.
_protocol is the protocol, most often _tcp or _udp (case insenstive) but can contain
other values such has _http or _ldap.
Even though underscores are typically precluded from use in hostnames, _service and
_protocol are prefixed with an underscore to avoid name collisions with other labels
within the zone.
name is the hostname of the service you are defining, i.e. voip.example.com.
TTL is the Time-To-Live as in any other record.
priority functions the same as that of an MX handler’s priority (or “preference”). The
lower this number, the sooner it will be used (the shorter the “distance”).
weight is something SRV records provide which MX handlers do not. SRV records being
applicable to an open-ended set of use cases, we have here the ability to facilitate load
balancing from within the DNS. Which really makes it a shame that none of the major
web browsers, for example, don’t have SRV record support.
port let’s us define the port for the given service, and could thus facilitate running well
known services on non-standard ports. Another reason why SRV records are really the
under-appreciated over-acheivers of the DNS protocol.
target is the hostname which will ultimately fulfill the service requests.
NAPTR
NAPTR stands for “Naming Authority Pointer”.
NAPTRs are primarily used in IP telephony applications in conjunction with SRV RR
records within the context of ENUM.
NAPTR
www.it-ebooks.info
|
89
ENUM - mapping telephone numbers into DNS
ENUM provides a mechanism for mapping e164 format telephone num‐
bers into the DNS. The full mechanism is described in RFC 6116, but it
is basically any telephone number in the form A.BBBBBBBBBBB, where +
is a literal "" character, A is the NPA Country Code,
BBBBBBBBBBBB is the telephone number with all non-numerals strip‐
ped out.
The process works by reversing the digits of the phone number and then
putting a “.” between each digit, finally (in the case of public ENUM)
appending the special domain e164.arpa.6
For example the phone number: 1-(416)-555-3231 would map as follows:
e164: +1.4165553231 ENUM: 1.3.2.3.5.5.5.6.1.4.e164.arpa
It is within the 1.3.2.3.5.5.5.6.1.4.e164.arpa zone then, where we can use
NAPTR records to setup our IP telephony magic for this phone number:
$ORIGIN 1.3.2.3.5.5.5.6.1.4.e164.arpa.
IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:[email protected]!"
IN NAPTR 102 10 "u" "E2U+mailto" "!^.*$!mailto:[email protected]!"
The format of a NAPTR record is as follows:
preference
weight
flag Double quoted and can be any alphanumeric digit (case insensitive). It’s meaning
is defined by the application, but there a few that are conventionally used. (My personal
shorthand for them is to mentally think of them as “what comes next” indicators).
“U” the result of processing this NAPTR record will be an URN “A” the result of pro‐
cessing this NAPTR will be a hostname which can be queried via A or AAAA lookups.
“S” the result of processing will be a SRV record.
U, A & S flags are all “terminal” rules in that signify the end of processing NAPTR records
within the current origin (because a “U” flag will yield a URN which may query a NAPTR
record in the parent zone of the URN’s DNS hostname).
“P” means there are no more NAPTR records to process (but the application may con‐
tinue processing other RR types along its own rules).
service
regex
6. There are also private ENUM islands, in which case the organization would define its own private ENUM
namespace
90
|
www.it-ebooks.info
destination
The process of starting with an old-world telephone number and winding up with a
VOIP call, or a fax or some other internet telephony application is commonly a twostep (or multi-step) process utilizing NAPTR records( depending on the value of the
flag).
First off, we map the telephone number to a URN, as in our example in the ENUM
sidebar (which we copied from Wikipedia’s NAPTR page7):
$ORIGIN 1.3.2.3.5.5.5.6.1.4.e164.arpa.
IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:[email protected]!"
IN NAPTR 102 10 "u" "E2U+mailto" "!^.*$!mailto:[email protected]!"
The “U” flag means you are going to end up with a URN, in our case above we start
with the first NAPTR record (lowest preference) and we end up with the URN “sip:pho‐
[email protected]”
Within the example.net zone we will have another NAPTR record which will catch his
query and provide the application with the rest of the information it will need to com‐
plete construction of a SIP session:
$ORIGIN example.net.
IN NAPTR 100 10 "S" "SIP+D2U" "!^.*$!sip:[email protected]!" _sip._udp.example.com.
IN NAPTR 102 10 "S" "SIP+D2T" "!^.*$!sip:[email protected]!" _sip._tcp.example.com.
Here the “S” flag means that processing will lead us to a SRV record lookup, after we’ve
applied the regex search/replace to the final destination.
In other words,
DNAME
PTR
it did a SRV lookup at _sip._udp.example.com to get the location of the relevent SIP
server or gateway. Think of a PTR record as the corollory of an A record or a hostname
lookup. A records specify IP addresses of a hostname, while PTR records go the opposite
direction: they lookup the hostname of a given IP address.
What people often miss about this process is that we are actually talking about two
completely different namespaces or DNS trees when we discuss a forward and a reverse
lookup.
Consider:
7. http://en.wikipedia.org/wiki/Telephone_number_mapping
DNAME
www.it-ebooks.info
|
91
www.example.com. IN A 192.168.13.56
we are looking at this tree:
level 0: . (the internet root) level 1: com (the .COM TLD) level 2: example (the domain
“example.com” delegated from .COM) level 3: www (the subdomain, subhost or host‐
name www.example.com)
Now let’s break down the IP address assigned to www.example.com in the same fashion.
Notice in the sequence above, when we broke down www.example.com we actually went
in reverse order, starting at the internet root (“(”.") and proceeding from right to left.
Each . was subdelegation of the label before it.
The reverse mapping will work in the same way, so the IP address will be represented
in reverse-octet form, under a special TLD called .arpa (Address Routing and Parameter
Area):
56.13.168.192.in-addr.arpa
Because this is an IPv4 address, it is within the in-addr.arpa tree. If we were looking at
an IPv6 address it would be under ipv6.arpa.
level 1: 192 (“192” would be a “Class A” netblock /8) level 2: 168 (“192.168” would be a
“Class B” netblock /16 or ) level 3: 13 (“192.168.13” would be a “Class C” netblock,
a /24) level 4: 56 (“192.168.13.56” is a single IPv4 address, a /32)
What is important to understand is that the reverse mapping for an IP address is under
a completely different namespace than it’s forward mapping. In other words, when you
define this in a zonefile:
$ORIGIN example.com. www IN A 192.168.12.56
You will never put the PTR record in this same zone because the PTR for 192.168.12.56
belongs in a completely different zone (a different “Origin”), namely one under the
12.168.192.in-addr.arpa zone:
$ORIGIN 12.168.192.in-addr.arpa. 56 IN PTR www.example.com.
Also important to know is that the authoritative nameservers for example.com are not
necessarily the same nameservers that will be authoritative for 12.168.192.in-addr.arpa,
in fact that is probably not the case more often than it is.
This is because the domain names are delegated from the registry of it’s parent TLD,
while the netblocks for the address space are delegated from regional numbering au‐
thorities. It is possible, and common(ish) to have forward and reverse nameservers
coincide but it involves obtaining the relevant delegations from two separate authorities.
In the case of the address space, i.e. the netblocks you will either be assigned a block of
addresses from your regional numbering authority, or you will be subdelegated a net‐
block from your immediate upstream network connectivity provider.
92
|
www.it-ebooks.info
In the case of the former, you will have your own ASN (Autonomous System Number)
and be responsible for maintaining your own routing announcements for your net‐
blocks. You will enter your nameserver delegations for your netblocks directly to your
regional numbering authority. Your blocks will be along Classful borders of Class C’s,
on boundries of /24 or larger.
Delegating /24’s and larger is simply a matter of specifying NS records for the corre‐
sponding in-addr.arpa notations:
$ORIGIN 168.192.in-addr.arpa.
13 IN NS ns1.telecom.dom. 13 IN NS ns2.telecom.dom. ; delegates the Class C netblock
192.168.13.0/24 to the ns1.telecom.dom and ns2.telecom.dom. nameservers
14 IN NS dns1.otherco.dom. 14 IN NS dns2.otherco.dom. ; delegates 192.168.14.0/24
range of addresses to otherco.dom nameservers
Then ns1.telecom.dom. will contain the relevent PTR records for it’s delegated netblock:
$ORIGIN 13.168.192.in-addr.arpa. 1 IN PTR gateway.example.com. 2 IN PTR some‐
host.example.com.
In the latter case, when you are being issued sub-delegations from your upstreams, you
may be delegated netblocks smaller than a Class C, such as a /25 and smaller.
Now it gets tricky, because zone cuts for netblocks of IP addresses happen along /24
boundries at the smallest (Classful subnetting), we now need a methodology to further
subdivide these delegations into smaller address blocks.
Enter Classless in-arpa delegations.
IPv6
AAAA
A6
KEY
CERT
DNSSEC Specific RR Types
Uncommon / Obscure RR Types
IPv6
www.it-ebooks.info
|
93
RP
Defined in RFC 1183 along with four other types of experimental DNS records: AFSDB,
X25, ISDN and RT - the only two of these I’ve ever seen in the wild are RP and AFSDB,
so we’ll look at those here.
AFSDB
LOC
94
|
www.it-ebooks.info

Managing Mission-Critical Domains and DNS

Transcription

Similar documents

parathom - Stillwaters Law Firm

SyS64738: [email protected] Agris Krusts: agris@zone

Data Science - SourceMedia

Promoting Inter-ccTLD Cooperation in Africa - ISOC-NY

Internet of Things. A recent visit to CES:

Ftegistra" co,fll

DNS-The glue in IoT 12/10/2014

1. Run nslookup to obtain the IP address of a Web server

Prediction of laminar-turbulent transition with DNS, LES and RANS

Dignitaries on the high Table