Managing Mission - Critical Domains and DNS

Demystifying nameservers, DNS, and domain names

Mark E. Jeftovic

• Verlag: Packt Publishing
• Jahr: 2018
• ISBN:
  9781788999755
• Auflage: 1
• Thema: Informatik
• Thema: Computernetzwerke

This book will give you an all encompassing view of the domain name ecosystem combined with a comprehensive set of operations strategies. About This Book• Manage infrastructure, risk, and management of DNS name servers. Get hands-on with factors like types of name servers, DNS queries and and so on.• Practical guide for system administrators to manage mission-critical servers• Based on real-world experience - Written by an industry veteran who has made every possible mistake within this field.Who This Book Is ForIdeal for sysadmins, webmasters, IT consultants, and developers-anyone responsible for maintaining your organization's core DNSWhat You Will Learn• Anatomy of a domain - how a domain is the sum of both its DNS zone and its registration data, and why that matters.• The domain name ecosystem - the role of registries, registrars and oversight bodies and their effect on your names.• How DNS queries work - queries and responses are examined including debugging techniques to zero in on problems.• Nameserver considerations - alternative nameserver daemons, numbering considerations, and deployment architectures.• DNS use cases - the right way for basic operations such as domain transfers, large scale migrations, GeoDNS, Anycast DNS.• Securing your domains - All aspects of security from registrar vendor selection, to DNSSEC and DDOS mitigation strategies.In DetailManaging your organization's naming architecture and mitigating risks within complex naming environments is very important. This book will go beyond looking at "how to run a name server" or "how to DNSSEC sign a domain", Managing Mission Critical Domains & DNS looks across the entire spectrum of naming; from external factors that exert influence on your domains to all the internal factors to consider when operating your DNS. The readers are taken on a comprehensive guided tour through the world of naming: from understanding the role of registrars and how they interact with registries, to what exactly is it that ICANN does anyway? Once the prerequisite knowledge of the domain name ecosystem is acquired, the readers are taken through all aspects of DNS operations. Whether your organization operates its own nameservers or utilizes an outsourced vendor, or both, we examine the complex web of interlocking factors that must be taken into account but are too frequently overlooked. By the end of this book, our readers will have an end to end to understanding of all the aspects covered in DNS name servers.Style and approachThe book is divided into two parts, the first part looks at the wider domain name ecosystem: registries, registrars and oversight policies.The second and larger part goes into operations. Every aspect of naming is considered from the viewpoint of how this affects ones domains, what are the ramifications of different operating methods as portfolios scale.

DNS Operations and Use Cases

In this chapter, we'll cover the most common DNS use cases. While some may seem straightforward at first glance, there are usually some best practices to be applied that may not be obvious. In some cases, failure to adhere to them can lead to outages.

We'll start with a few domain operations that are typically done on domain names, such as transferring a domain, changing a domain's registrant, or adding secondary nameservers.

From there, we will move to DNS use cases that involve doing something to the zone data within a zone, such as global load balancing, implementing GeoDNS, or configuring the DNS component of email deliverability schemes, such as SPF and DKIM.

Some typical use cases we'll cover include the following:

• Transferring domain names
  • Changing a domain registrant
  • Moving nameservers (redelegations)
  • Redelegating DNSSEC-signed domains
  • Registrar transfers
• Adding additional nameservers
• Moving to new nameservers
• Moving entire portfolios of domains to new nameservers
• Round-robin DNS
• Load balancing/global weighted load balancing
• DNS failover
• Dynamic DNS
• Geo DNS
• Zone apex aliasing
• Reverse DNS and Netblock subdelegations
• Implementing SPF, DKIM, and DMARC

Transferring domain names

It may sound simple, but there are various permutations of a plain "domain transfer." The phrase can have very different implications 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 operation.

In other words, a domain transfer could refer to any of the following:

• Changing the owner or registrant of a domain name from one entity to another (Change of registrant)
• Moving a domain from one registrar to another (Registrar transfer)
• Changing the nameserver delegation of a domain name (nameserver redelegation, Change of Operator or even DNS Transfer–the last of which can easily be confused with AXFR or IXFR zone transfers)
• Moving a domain name between user accounts within a registrar, web provider, managed DNS provider or similar (domain push or account push)

Change of registrant

This refers to changing the owner of a domain name.

In the olden days (during the Network Solutions monopoly), this was considered a non-trivial undertaking and required sending in a notarized piece of photo ID, and this cost somewhere in the neighborhood of $150 to process.

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.

The way a change of registrant procedure works today came into effect relatively recently with an ICANN policy that took effect December 1, 2016. This applies to all TLDs under the oversight of ICANN (.COM/.NET/.ORG and all new TLDs).

The new process requires that both the current (outgoing) Registrant and the new (incoming) Registrant explicitly approve the change request.

It also adds a new transfer lock period of 60 days; this is similar to the way new domain registrations cannot be transferred to a new registrar within 60 days of initial registration. The new change-of-registrant process also imposes the 60-day transfer lock period.

This is typically done as follows:

1. The current registrant navigates to their registrar control panel for the domain and makes the edit (usually in the Whois or Domain Contact or Domain Information sections of their domain).
2. The change assumes a pending state, and a confirmation is sent out-of-band to the current registrant and the proposed new registrant.
3. Both the current and the new Registrant explicitly acknowledge and accept the change.

At this point, the Registrant contact set for the domain is updated.

Nameserver redelegations

A change of nameserver delegation is the act of moving a domain from one set of nameservers to another. There are two permutations to this operation:

• Changing the delegation and changing the primary master for the domain
• Changing the delegation while preserving the primary master for the domain

In the first case, the approach is simply to set up 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.Look at these steps:

1. Set up new master nameserver, modify the NS RRset to reflect the new/incoming nameserver delegation.
2. Set up 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.
4. Leave the old nameservers up to answer queries for at least as long as the greater of a) the TTL for the NS RRSET or b) the TTL of the zone apex (while optionally setting up the old nameservers to slave from the new master).
5. Decommission the zone on the old nameservers and master.

The second case is a little more streamlined:

1. Set up the zone on the new nameservers.
2. Add your new nameserver NS RRs to your zone's existing NS.
3. Update the nameserver delegation in the parent zone (usually parent TLD)–this includes removing the old nameservers from the delegation.
4. After NS RRSET TTL expires for the old nameservers, remove their NS records from your zone.

The modifications to the NS RRSET are done with the DNS provider, or on your master nameserver if you are the DNS operator.

The nameserver delegation update is done via the Registrar for the zone (domain), which will update the Registry with the new list of nameservers for the domain in its TLD.

Most gTLD registries will modify the delegation without checking whether you've actually done this coherently and the new nameservers become 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.

There may be an interval of time in which some resolvers receive data that is not entirely consistent, but still gets the job done from the client's perspective.

For example, the resolver may obtain a referral to the old NS RRSET from the delegating TLD the domain, and upon following the glue to an old authoritative nameserver, end up seeing an NS RRSet with additional data (the new NS RRSet coming into effect). This is normal.

Redelegating DNSSEC-signed domains

With DNSSEC (see Chapter 13, Securing your Domains and DNS), you have to execute this nameserver redelegation in a way where the trust chain will not break (RFC6781).

While there is work being done to help facilitate key transfers between DNS operators using the Registry/Registrar EPP protocol, interest in this from registrars and registries is currently lacklustre at best. Until that changes and deployment gets further along, we are stuck working with redelegating zones across (hopefully cooperative) DNS operators.

This is done in a fashion somewhat akin to DNSSEC key rollovers, where you prepublish new keys with the new provider while signing the current zone with both sets of keys: the losing DNS provider's key and a new key with the new DNS provider.

Given the Gaining and Losing DNS providers, where the zone is moving away from Losing nameservers and on to those of the Gaining, consider the following:

• Gaining generates new ZSK, KSK, and DS records
• Losing publishes both new and old ZSKs in the current zone
• Losing signs the zone containing both ZSKs
• Gaining obtains Losing's ZSK and KSK
• Gaining signs the zone containing Losing's ZSK
• Gaining signs both ZSKs with its own KSKs
• New DS record into the parent zone/TLD
• Nameservers redelegated
• Both sets of nameservers operate past length of TTL
• After TTL elapses, Gaining may drop Losing KSK and ZSK and resign zone

The objective of all this is to provide resolvers that have cached data the ability to validate records, regardless of whether they have data from the losing provider or are receiving fresh responses from the gaining provider.

This scenario describes how to redelegate between cooperating DNS providers. If the loser is uncooperative, it gets a lot harder. So much harder, in fact, that I wil...