Learning CoreDNS Configuring DNS for Cloud Native Environments 1st Edition John Belamaric

Visit https://ebookultra.com to download the full version and
explore more ebooks
Learning CoreDNS Configuring DNS for Cloud
Native Environments 1st Edition John Belamaric
_____ Click the link below to download _____
https://ebookultra.com/download/learning-coredns-
configuring-dns-for-cloud-native-environments-1st-
edition-john-belamaric/
Explore and download more ebooks at ebookultra.com

Here are some suggested products you might be interested in.
Click the link to download
Resource management of mobile cloud computing networks and
environments 1st Edition Mastorakis
https://ebookultra.com/download/resource-management-of-mobile-cloud-
computing-networks-and-environments-1st-edition-mastorakis/
Learning to Solve Problems A Handbook for Designing
Problem Solving Learning Environments 1st Edition David H.
Jonassen
https://ebookultra.com/download/learning-to-solve-problems-a-handbook-
for-designing-problem-solving-learning-environments-1st-edition-david-
h-jonassen/
Interactive and Digital Media for Education in Virtual
Learning Environments 1st Edition Cai Yiyu
https://ebookultra.com/download/interactive-and-digital-media-for-
education-in-virtual-learning-environments-1st-edition-cai-yiyu/
E Infrastructures and Technologies for Lifelong Learning
Next Generation Environments 1st Edition George Magoulas
https://ebookultra.com/download/e-infrastructures-and-technologies-
for-lifelong-learning-next-generation-environments-1st-edition-george-
magoulas/

Gender and Early Learning Environments 1st Edition Beverly
Irby
https://ebookultra.com/download/gender-and-early-learning-
environments-1st-edition-beverly-irby/
DNS BIND Cookbook 1st Edition Cricket Liu
https://ebookultra.com/download/dns-bind-cookbook-1st-edition-cricket-
liu/
Visible Learning for Teachers Maximizing Impact on
Learning 1st Edition John Hattie
https://ebookultra.com/download/visible-learning-for-teachers-
maximizing-impact-on-learning-1st-edition-john-hattie/
Theoretical Foundations of Learning Environments 2nd
Edition Susan Land
https://ebookultra.com/download/theoretical-foundations-of-learning-
environments-2nd-edition-susan-land/
Communities of Practice An Alaskan Native Model for
Language Teaching and Learning 1st Edition Patrick E.
Marlow
https://ebookultra.com/download/communities-of-practice-an-alaskan-
native-model-for-language-teaching-and-learning-1st-edition-patrick-e-
marlow/

Learning CoreDNS Configuring DNS for Cloud Native
Environments 1st Edition John Belamaric Digital Instant
Download
Author(s): John Belamaric, Cricket Liu
ISBN(s): 9781492047964, 1492047961
Edition: 1
File Details: PDF, 7.48 MB
Year: 2019
Language: english

John Belamaric
& Cricket Liu
Learning
CoreDNS
Configuring DNS for Cloud Native
Environments

John Belamaric and Cricket Liu
Learning CoreDNS
Configuring DNS for
Cloud Native Environments
Boston Farnham Sebastopol Tokyo
Beijing Boston Farnham Sebastopol Tokyo
Beijing

978-1-492-04796-4
[LSI]
Learning CoreDNS
by John Belamaric and Cricket Liu
Copyright © 2019 John Belamaric and Cricket Liu. 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://oreilly.com). For more information, contact our corporate/institutional
sales department: 800-998-9938 or corporate@oreilly.com.
Acquisitions Editor: John Devins
Development Editor: Melissa Potter
Production Editor: Christopher Faucher
Copyeditor: Octal Publishing, LLC
Proofreader: Christina Edwards
Indexer: Ellen Troutman-Zaig
Interior Designer: David Futato
Cover Designer: Karen Montgomery
Illustrator: Rebecca Demarest
September 2019: First Edition
Revision History for the First Edition
2019-08-30: First Release
See http://oreilly.com/catalog/errata.csp?isbn=9781492047964 for release details.
The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Learning CoreDNS, the cover image,
and related trade dress are trademarksvof O’Reilly Media, Inc.
The views expressed in this work are those of the authors, and do not represent the publisher’s views.
While the publisher and the authors have used good faith efforts to ensure that the information and
instructions contained in this work are accurate, the publisher and the authors disclaim all responsibility
for errors or omissions, including without limitation responsibility for damages resulting from the use of
or reliance on this work. Use of the information and instructions contained in this work is at your own
risk. If any code samples or other technology this work contains or describes is subject to open source
licenses or the intellectual property rights of others, it is your responsibility to ensure that your use
thereof complies with such licenses and/or rights.

Table of Contents
Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
What Is CoreDNS? 1
CoreDNS, Containers, and Microservices 2
CoreDNS Limitations 3
CoreDNS, Kubernetes, and the Cloud Native Computing Foundation 4
2. A DNS Refresher. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
What Is the Domain Name System? 5
Domain Names and the Namespace 6
Domains, Delegation, and Zones 7
Resource Records 9
DNS Servers and Authority 10
Resolvers 11
Resolution and Recursion 12
Caching 15
Resource Records 15
NAME 16
TTL 16
CLASS 17
Resource Record Types 17
The A Record 17
The AAAA Record 18
The CNAME Record 18
The MX Record 19
The NS Record 20
iii

The SRV Record 21
The PTR Record 23
The SOA Record 24
An Annotated Zone Data File 26
3. Configuring CoreDNS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Getting CoreDNS 29
CoreDNS Command-Line Options 31
Corefile Syntax 32
Environment Variables 34
Reusable Snippets 35
Import 35
Server Blocks 35
Query Processing 37
Plug-ins 38
Root 39
File 39
Secondary 40
Forward 42
Cache 44
Errors 45
Log 47
Common Configuration Options 50
fallthrough 50
tls 50
transfer to 51
Sample DNS Server Configurations 51
Caching-Only DNS Server 51
Primary DNS Server 52
Secondary DNS Server 52
4. Managing Zone Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
The file Plug-in 55
The auto Plug-in 58
Using the auto Plug-in with Git 59
The hosts Plug-in 60
The route53 plug-in 62
5. Service Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Introduction to Service Discovery 65
Solving the Service Discovery Problem 66
iv | Table of Contents

Service Discovery with CoreDNS and etcd 68
The etcd Plug-in 69
Other Service Discovery Options 74
Service Discovery and Container Orchestration 75
6. Kubernetes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Basic Concepts 77
Kubernetes Networking 79
Cluster IP Services 80
Headless Services 81
Kubernetes DNS Specification 82
CoreDNS Integration 91
Default Configuration 93
Stub Domains and Federations 96
Cluster DNS Deployment Resources 98
Role-Based Access Control 98
Service 100
Deployment 101
Autoscaling 105
A Better Configuration 106
The kubernetes Plug-in 109
CoreDNS Extensions 111
Pod Options 111
Wildcard Queries 112
Autopath and the Dreaded ndots:5 113
Zone Transfer Support 115
Exposing Services Externally 116
Modifying the Available Records 117
7. Manipulating Queries and Responses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
The template Plug-in 121
The rewrite Plug-in 124
Using the rewrite Plug-in for EDNS0 Options 127
Multiple rewrite Rules 128
The metadata Plug-in 129
Signing Responses with the DNS Security Extensions 130
Managing a DNSSEC-Signed Primary Zone 131
On-the-Fly DNSSEC Signing with the dnssec Plug-in 136
Case Study: Infoblox’s BloxOne Threat Defense 137
Identifying Users 138
Applying Policy 139
Table of Contents | v

8. Monitoring and Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
The prometheus Plug-in 141
The log Plug-in 143
The dnstap Plug-in 147
The errors Plug-in 150
The trace Plug-in 151
The debug Plug-in 154
9. Building a Custom Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Compiling CoreDNS with an External Plug-in 157
Building Using Docker 158
Building on Your Workstation 159
Modifying plugin.cfg 161
Replacing main 164
Writing a Custom Plug-in 170
There Can Be Only One 173
Integrating with Metrics, Trace, and Metadata 178
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
vi | Table of Contents

1 Which wins the award for most prosaic name, hands-down.
Preface
Why a New DNS Server?
Upon seeing this book, the first question that might occur to you is, “Why does the
world need another DNS server?” There are, after all, lots of implementations of DNS
servers to choose from. For starters, there’s BIND, for Berkeley Internet Name
Domain, the granddaddy of DNS servers. BIND has been around in some incarna‐
tion since the 1980s and supports just about every DNS standard written. There’s
Microsoft’s DNS Server,1
which is widely used in Active Directory environments.
NSD from NLnet Labs and Knot are excellent authoritative DNS servers, and
Unbound, also from NLnet Labs, is a fast, lean recursive DNS server. So what does
CoreDNS offer that these others don’t?
To begin with, CoreDNS is written in Go, and Go is a memory-safe programming
language. Why is that important? Well, if you’ve ever run a BIND-based DNS infra‐
structure and had to upgrade 100 DNS servers ASAP because of a buffer overrun, you
know. A healthy proportion of vulnerabilities in DNS servers of all stripes (at least
those written in C and C++) stem from buffer overflows or overruns and dangling
pointers. Written in memory-safe Go, CoreDNS isn’t subject to these.
Programs written in Go can also support concurrency, or parallel execution. This can
be useful in wringing more performance out of multiprocessing or multitasking sys‐
tems. BIND’s performance somewhat notoriously doesn’t scale well on multiproces‐
sor systems, whereas CoreDNS’s performance scales nicely the more processors it has
to work with.
vii

2 Meaning that the same algorithm implemented the same way in Go, C, and C++ will probably run slightly
faster in C and C++.
Improving performance can be important because Go tends to run somewhat more
slowly than C or C++,2
partly thanks to the overhead imposed by its many features. In
most cases, however, this isn’t an issue: What’s important is that CoreDNS performs
well enough to handle the workload you offer it, and in the vast majority of cases, it
does, Go or no Go.
Probably the most significant capability CoreDNS offers, though, is its ability to com‐
municate with container infrastructure and orchestration systems such as etcd and
Kubernetes.
Who Needs CoreDNS?
The short answer: basically anyone running Kubernetes, and most folks running con‐
tainerized applications.
The function CoreDNS fulfills in a containerized environment is that of a service
directory, which we talk about in detail in this book. A service directory helps con‐
tainers determine the IP address or IP addresses where the containers that offer a
particular service are running. For example, a container might look up a domain
name that represents the database service for a specified application in order to
retrieve some data. The service directory function is critical because, in the world of
containers and microservices, applications are usually decomposed into many small
services (hence, “microservices”!), and each service might be offered by several con‐
tainers, each running at a different IP address.
But CoreDNS’s utility isn’t limited to containerized environments. CoreDNS’s plug-
ins support advanced DNS functionality that even the big boys like BIND don’t sup‐
port. You can rewrite queries and responses on the fly, for example. You can
automatically load zone data from GitHub or Amazon Route 53. And because Core‐
DNS itself is small and usually runs in a container, it’s suitable for use in scenarios in
which a big DNS server such as BIND would not be.
viii | Preface

Who This Book Is For
This book is aimed at the following audiences:
• Administrators of containerized environments that need DNS-based service dis‐
covery, particularly when those environments are managed by Kubernetes.
• DNS administrators looking for a small, flexible DNS server that can run in a
container.
• DNS administrators looking for a DNS server that
— Integrates with Route 53
— Supports flexible rewriting of queries and responses
— Supports DNS over Transport Layer Security (TLS) and general-purpose
Remote Procedure Call (gRPC)
• Developers looking to implement custom DNS functionality by writing their own
CoreDNS plug-ins.
What You Will Learn
Readers of this book will learn:
• What distinguishes CoreDNS from other DNS servers
• Basic DNS theory, including the DNS namespace, domain names, zones,
resource records, recursion, caching, and forwarding
• Basic CoreDNS configuration, including configuring common DNS servers such
as primaries and secondaries and caching DNS servers
• CoreDNS’s options for managing zone data, including advanced options such as
loading from Git and Route 53
• How DNS-based service discovery works, and how to configure CoreDNS ser‐
vice discovery with etcd and Kubernetes
• How to rewrite queries and responses
• How to monitor and troubleshoot CoreDNS
• How to build custom versions of CoreDNS and write new plug-ins
Preface | ix

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 ele‐
ments such as variable or function names, databases, data types, environment
variables, statements, and keywords.
This element signifies a general note.
This element indicates a warning or caution.
Using Code Examples
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 signifi‐
cant amount of example 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: “Learning CoreDNS by John Belama‐
ric and Cricket Liu (O’Reilly). Copyright 2019 John Belamaric and Cricket Liu,
978-1-492-04796-4.”
If you feel your use of code examples falls outside fair use or the permission given
above, feel free to contact us at permissions@oreilly.com.
x | Preface

O’Reilly Online Learning
For almost 40 years, O’Reilly Media has provided technology
and business training, knowledge, and insight to help
companies succeed.
Our unique network of experts and innovators share their knowledge and expertise
through books, articles, conferences, and our online learning platform. O’Reilly’s
online learning platform gives you on-demand access to live training courses, in-
depth learning paths, interactive coding environments, and a vast collection of text
and video from O’Reilly and 200+ other publishers. For more information, please
visit http://oreilly.com.
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: https://oreil.ly/learning-coreDNS.
To comment or ask technical questions about this book, please send an email to
bookquestions@oreilly.com.
For more information about our books, courses, conferences, and news, see our web‐
site 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
Preface | xi

Acknowledgments
The authors would like to thank their able reviewers Miek Gieben, François Tur, and
Michael Grosser for catching errors both subtle and egregious. They would also like
to thank all the other members of the CoreDNS community for creating such an
incredible product.
John would like to thank his amazing wife, Robin, for her support, encouragement,
and assistance. He couldn’t have done it without her. He also would like to acknowl‐
edge the support of his son, Owen, and daughter, Audrey, who have put up with all
the nonsense that goes along with their dad writing a book. He gives thanks to Tim
Hockin, Bowei Du, and the rest of the Kubernetes SIG-Network team for helping
guide CoreDNS into Kubernetes, and to his former colleagues at Infoblox, particu‐
larly Chris O’Haver and Sandeep Rajan, who worked hard to make CoreDNS the
right choice for Kubernetes. Finally, he would like to thank his former colleague Alan
Conley, without whose support, CoreDNS would not be what it is today.
Cricket would like to acknowledge his friends and colleagues at Infoblox, particularly
his boss, Alan Conley. Without Alan’s regular harassment, this book would never
have gotten off the ground. And he sends his love and thanks to Kristin, for her
steadfast support; to his kids, Walt (née Walter B) and Greta (née Baby G), sources of
amusement and amazement and no small amount of eye-rolling; and, finally, to
Charlie and Jessie, who provided sisterly canine companionship through much of this
project but, sadly, didn’t make it to see the end.
xii | Preface

CHAPTER 1
Introduction
This book is about CoreDNS, a new DNS server that’s been designed to work well
with containers, such as Linux and Docker containers, and especially well in environ‐
ments managed by Kubernetes, the popular container orchestration system.
This first chapter explains CoreDNS’s raison d'être, and how it differs from other
DNS servers, including its limitations. The chapter also covers a little of the history of
CoreDNS, such as its relationship to the Cloud Native Computing Foundation.
What Is CoreDNS?
CoreDNS is DNS server software that’s often used to support the service discovery
function in containerized environments, particularly those managed by Kubernetes.
Miek Gieben wrote the original version of CoreDNS in 2016. He’d previously written
a DNS server called SkyDNS and a popular library of DNS functions in the Go lan‐
guage called Go DNS. Like its successor, CoreDNS, SkyDNS’s main purpose was to
support service discovery. But Miek admired the architecture of a Go-based web
server called Caddy, so he forked Caddy to create CoreDNS. CoreDNS thus inherited
the major advantages of Caddy: its simple configuration syntax, its powerful plug-in-
based architecture, and its foundation in Go.
Compared to the syntax of, say, BIND’s configuration file, CoreDNS’s Corefile, as it’s
called, is refreshingly simple. The Corefile for a basic CoreDNS-based DNS server is
often just a few lines long and—relatively speaking—easy to read.
CoreDNS uses plug-ins to provide DNS functionality. So there’s a plug-in for caching
and a plug-in for forwarding, a plug-in for configuring a primary DNS server that
reads zone data from a file and a plug-in for configuring a secondary DNS server. Not
only is configuring each plug-in straightforward (see the previous paragraph), but if
1

you don’t need a plug-in, you don’t configure it and its code isn’t executed. That
makes CoreDNS faster and more secure.
Plug-ins are also fairly easy to develop. That’s important for two reasons. First, if you
want to extend CoreDNS’s functionality, you can write your own plug-in; we cover
that in Chapter 9. Second, because writing new plug-ins isn’t rocket science, many
have been developed, and more are being written all the time. You might find one
that provides functionality you need.
The Go language is “memory-safe,” which means that it’s protected from “memory
access errors” such as buffer overflows and dangling pointers. That’s particularly
important for a DNS server such as CoreDNS, which anyone on the internet could
conceivably access. A malicious actor might exploit a buffer overflow to crash a DNS
server or even to gain control of the underlying operating system (OS). In fact, over
the decades of its history, a substantial number of the serious vulnerabilities in BIND
have been caused by memory access errors. With CoreDNS, you don’t need to worry
about those.
Probably the most significant advantage CoreDNS offers, though, is its ability to
communicate with container infrastructure and orchestration systems such as etcd
and Kubernetes. We discuss this in much more detail later in the book, but let’s take a
quick look at this functionality here.
CoreDNS, Containers, and Microservices
If you’re in the tiny subset of humanity to whom this book appeals, you’ve probably
heard of containers. If you haven’t, think of a container as a very lightweight, efficient
virtual machine (VM). Whereas VMs can share a single hardware platform, courtesy
of a hypervisor, containers provide execution environments that run under the same
OS kernel but provide a similar level of isolation as VMs. Containers are much
smaller than VMs and can be started and stopped much more quickly.
Containers are often used in software based on a microservices architecture. With
microservices, an application, often a complex one, is decomposed into many micro‐
services. Each microservice is responsible for providing a small but useful and clearly
defined set of functionality. For example, one microservice might handle authentica‐
tion of users, whereas another manages authorization of those users. An application,
in total, might comprise dozens or hundreds of microservices, communicating with
one another over a network.
In practice, each microservice might be provided by one or more containers. The
authentication service, for example, might be implemented as a container. It’s so quick
and easy to start and stop containers that the application—or a higher-level con‐
tainer orchestrator—might start and stop additional authentication containers dynam‐
ically as demand for authentication waxes and wanes.
2 | Chapter 1: Introduction

In such an environment, though, tracking where a particular service is running can
be challenging. Say a container supporting the database service needs to communi‐
cate with the authorization service to determine whether a given user should be
allowed to conduct a particular search. If the containers that implement the authori‐
zation service are being started and stopped dynamically to accommodate load, how
do we get a list of all running authorization containers?
The answer is most often DNS, the Domain Name System. Since the communications
between containers is almost always based on IP, the Internet Protocol, and because
developers have been using DNS to find the IP addresses of resources for literally
decades, using DNS to identify containers that offer a given service is natural.
It’s in this capacity that CoreDNS really shines. Not only is CoreDNS a flexible, secure
DNS server, but it integrates directly with many container orchestration systems,
including Kubernetes. This means that it’s easy for the administrators of container‐
ized applications to set up a DNS server to mediate and facilitate communications
between containers.
CoreDNS Limitations
CoreDNS does currently have some significant limitations, though, and it won’t be
suitable for every conceivable DNS server. Chief among these is that CoreDNS, at
least in the latest version as of this writing, doesn’t support full recursion. In other
words, CoreDNS can’t process a query by starting at the root of a DNS namespace,
querying a root DNS server and following referrals until it gets an answer from one
of the authoritative DNS servers. Instead, it relies on other DNS servers—usually
called forwarders—for that. In Chapter 2, we talk more about recursion and
forwarders.
If you’re still on the fence about whether CoreDNS is the right choice for your partic‐
ular needs, Table 1-1 might help; it summarizes the key differences between
CoreDNS’s functionality and BIND’s.
Table 1-1. Key functional differences between CoreDNS and BIND
CoreDNS BIND
Full recursion No Yes
Dynamic updates No Yes
Integration with Kubernetes Yes No
Integration with Amazon Route 53 Yes No
Domain Name System Security Extensions (DNSSEC) support Limited Full
Support for DNS over Transport Layer Security (DoT) Yes No
What Is CoreDNS? | 3

If you’re unsure about what some of these terms mean, don’t worry, we cover them
later in the book. Before we do, though, let’s talk briefly about the formal relationship
between CoreDNS, Kubernetes, and something called the Cloud Native Computing
Foundation.
CoreDNS, Kubernetes, and the Cloud Native Computing Foundation
Kubernetes, the container orchestration system with which CoreDNS integrates so
nicely, was originally written at Google and then converted to an open source project
in 2015. To manage the newly open sourced Kubernetes, Google partnered with The
Linux Foundation to create the Cloud Native Computing Foundation, or CNCF for
short.
The CNCF has become the home for many technologies important to building cloud-
based applications, including Prometheus, which supports collecting metrics and
alerting, and Envoy, a service proxy. Projects managed by the CNCF move through
various “maturity levels,” from “sandbox,” for early-stage projects; to “incubating,” for
projects gaining acceptance; to “graduated,” for mature projects suitable for broad
adoption.
CoreDNS was submitted to the CNCF in 2017 and moved to “graduated” status in
January 2019. As testament to CoreDNS’s criticality to Kubernetes environments,
CoreDNS became the default DNS server shipped with Kubernetes with Kubernetes
version 1.13, which was released in December 2018. Given that CoreDNS is now
installed with almost every new Kubernetes implementation, and Kubernetes is a jug‐
gernaut in the world of containers (and containers themselves seem to be taking the
world by storm), we expect the installed base of CoreDNS to explode.
Enough of singing CoreDNS’s praises. We’ve talked about what CoreDNS is good for
and what it isn’t, and how it’s had its fate lashed to Kubernetes. Next, we give you a
whirlwind refresher on DNS theory so that we can begin talking about how to config‐
ure CoreDNS to do useful work!
4 | Chapter 1: Introduction

CHAPTER 2
A DNS Refresher
So far, we’ve talked about practical matters like what CoreDNS is, what’s it’s good at
(vis-à-vis DNS functionality) and what it’s not good at. Of course, that discussion had
to include some DNS terminology—terminology that, in fairness, not everyone is
familiar with.
We deliberated for a while over how much DNS theory to include in this book. We
could, of course, “Begin at the beginning, and go on till... the end, then stop,” but
that’s been done in other books, including books we’ve written. Still, it didn’t seem fair
to send you out into the world without at least a grounding in DNS.
Our compromise is to try to give you just enough DNS theory to get by, and then to
point you in the direction of, for example, DNS and BIND if you’re interested in more
detail. (Hopefully that doesn’t seem too self-serving.)
What Is the Domain Name System?
The DNS is a naming system that maps names to other data, such as IP addresses,
mail routing information, and more. And DNS isn’t just any naming system: it’s the
internet’s standard naming system as well as one of the largest distributed databases
in the world.
DNS is also a client–server system, with DNS clients querying DNS servers to retrieve
data stored in that distributed database. Because the database is distributed, DNS
servers will often need to query one or more other DNS servers to find a given piece
of data. DNS clients are often called resolvers, whereas DNS servers are sometimes
5

1 We’ll refer to them as DNS servers in this book, though in other books we referred to them as name servers.
People change!
2 And yes, George Foreman is the canonical counterexample of this. But George’s five sons named “George” all
have name suffixes (II, III, etc.) and nicknames to help tell them apart.
called name servers.1
Resolvers ask DNS servers for information about particular
indexes into the distributed database.
Domain Names and the Namespace
Those indexes into DNS’s distributed database are called domain names. These are the
dotted names that should be familiar to you from internet email addresses and URLs.
In an email address, the domain name appears to the right of the “@” sign. In a URL,
the domain name appears after the “://” and before the next “/,” if any. So in the email
address cricket@foo.example, “foo.example” is the domain name. In the URL http://
www.bar.example/, “www.bar.example” is the domain name.
These domain names actually represent nodes in DNS’s namespace. DNS’s namespace
is an inverted tree, with the root node at the top. Each node can have an arbitrarily
large number of child nodes, and is usually depicted with links between it and its chil‐
dren. Each node also has a label, which can be up to 63 ASCII characters long. The
root node has a special label: the null label, which has zero length. Only the root node
has the null label. Beyond that, there aren’t many restrictions on labels—mainly that
the child nodes of a single node must all have different labels. That makes sense: It
helps avoid ambiguity and confusion, just as giving your children unique first names
does.2
Figure 2-1 shows a portion of a fictional DNS namespace to help illustrate
these concepts.
Figure 2-1. A (semi-)fictional DNS namespace
6 | Chapter 2: A DNS Refresher

Clearly a label is useful only in distinguishing one node from its siblings; some other
identifier is needed to identify a particular node in the entire namespace. That identi‐
fier is the domain name.
A node’s domain name is the list of labels on the path from that node upward to the
root of the namespace, with a single dot separating each label from the next. For
example, in Figure 2-2, the indicated node has the domain name www.baz.example.
Figure 2-2. The node www.baz.example
Once upon a time, in the early days of the internet, domain names at the bottom of
the namespace (the “leaves” of the tree, if you will) represented individual hosts.
Nowadays, that’s less and less true. Individual hosts do have domain names, of course
(though in some cases they can have more than just one), but domain names can rep‐
resent the following:
• Websites, such as www.google.com, which can be served by many individual hosts
• Email destinations, such as gmail.com, which again can be served by many hosts
• Other resources not necessarily tied to a single host, such as an FTP service
• Some combination of these. infoblox.com, for example, is a website, an email des‐
tination, and more
Next, let’s look at how domain names are grouped, and how they’re managed.
Domains, Delegation, and Zones
There are a few other bits of theory we need to introduce before diving into the world
of how DNS servers work, so please bear with us. The first is a domain. A domain is a
group of nodes in a particular subtree of the namespace; that is, at or below a particu‐
lar node. The domain is identified by the node at its apex (the topmost node in the
Domains, Delegation, and Zones | 7

3 Berkeley historically has not been fond of central authority.
domain): it has the same domain name. For example, Figure 2-3 shows the domain
foo.example, with the node foo.example at its apex.
Figure 2-3. The domain foo.example
Given that foo.example can indicate either the node and the domain, it’s important
that we specify the context when identifying it: the node foo.example or the domain
foo.example.
In practice, domains are usually managed by particular organizations. For example,
Google manages google.com, Infoblox manages infoblox.com, and UC Berkeley man‐
ages berkeley.edu. This means that these organizations can create new nodes in their
domain and attach data to those nodes. (More on that to come.)
Sometimes, an organization wants to allow a different organization to manage a por‐
tion of their domain. For example, the folks at UC Berkeley who run berkeley.edu
might decide that their computer science (CS) department is capable of running a
portion of berkeley.edu themselves, and that allowing the CS department to do so
directly would avoid the unnecessary headache of having the CS department request
changes to berkeley.edu through some central authority.3
This is accomplished through delegation. The folks in Berkeley’s IT department can
create a subdomain of berkeley.edu, which is simply a subtree of the berkeley.edu

4 For those of you jumping up and down, shouting about Hesiod and Chaosnet, sit down, both of you.
domain, and delegate it to the CS department. They might well name it something
intuitive, such as cs.berkeley.edu (and in fact they have).
We’ll leave aside for the time being the mechanics of how delegation is done. For now,
suffice it to say that the berkeley.edu domain now contains information on where peo‐
ple can find information in the cs.berkeley.edu subdomain, rather than containing that
information itself.
Thanks to delegation, the IT folks at Berkeley no longer control nodes at or below
cs.berkeley.edu; those belong to the CS department. What do we call the set of nodes
at or below berkeley.edu that the IT folks still control? That’s the berkeley.edu zone. A
zone is a domain minus the subdomains that have been delegated elsewhere. What if
there’s no delegation within a domain? In that case, the domain and the zone contain
the same nodes. For example, if there’s no further delegation below cs.berkeley.edu,
the domain cs.berkeley.edu and the zone cs.berkeley.edu are effectively the same.
There are zones above berkeley.edu, too, of course. The edu domain is run by a non‐
profit association called EDUCAUSE, which delegates berkeley.edu and umich.edu
and many other subdomains to educational institutions around the world. What
they’re left with—what they directly manage—is the edu zone.
Okay, we’ve covered the structure of the indexes into DNS’s distributed database. But
what about the data?
Resource Records
If, as we said, DNS is a distributed database, where’s all the data? So far, we have
indexes (domain names) and partitions of the database (zones), but no actual data.
Data in DNS is stored in units of resource records. Resource records come in different
classes and types. The classes were intended to allow DNS to function as the naming
service for different kinds of networks, but in practice DNS is used only on the inter‐
net and TCP/IP networks, so just one class, “IN,” for internet, is used.4
The types of
resource records in the IN class specify both the format and application of the data
stored. Here’s a list of some of the most common resource record types in the IN
class:
A (IPv4 address)
Maps a domain name to a single IPv4 address
AAAA (IPv6 address)
Maps a domain name to a single IPv6 address
Resource Records | 9

CNAME (alias)
Maps a domain name (the alias) to another domain name (the canonical name)
MX (mail exchanger)
Names a mail exchanger (mail server) for an email destination
NS (name server)
Names a name server (or DNS server) for a zone
PTR (pointer)
Maps an IP address back to a domain name
SOA (start of authority)
Provides parameters for a zone
Each record type requires record-specific data, called RDATA for short, in a particu‐
lar format. For example, an A record requires RDATA of a single, 32-bit IPv4 address.
When you see A records in zone data files (more on them later) or in the output of
various tools, the RDATA will usually be formatted as a dotted-octet value (e.g.,
192.168.0.1). Similarly, a AAAA (pronounced “quad A”) record takes a single, 128-bit
address as RDATA, which in zone data files is usually formatted in the standard,
colon-separated hexadecimal format used for IPv6 addresses (e.g.,
2001:db8:ac10:fe01::1).
There are dozens of types besides the seven in this list, and many with more complex
RDATA formats than A and AAAA. We cover the format and semantics of resource
records at the end of this chapter For now, let’s move on to the types of DNS servers.
DNS Servers and Authority
DNS servers have two chief responsibilities: answering queries about domain names,
and querying other DNS servers about domain names. Let’s begin with the first
responsibility: answering queries.
DNS servers can load zone data from files called, appropriately enough, zone data
files or, equivalently, master files. Each zone data file contains a complete description
of a zone: all of the records attached to all of the domain names in the zone. A DNS
server that loads information about a zone from a zone data file is called a primary
DNS server for that zone.
DNS servers can also load zone data from other DNS servers via a mechanism called
a zone transfer. A DNS server that loads information about a zone from another DNS
server using zone transfer is said to be a secondary DNS server for that zone. The
DNS server from which the secondary DNS server transfers the zone is referred to as
its master DNS server. After transferring the zone, the secondary DNS server might
save a copy of the zone data to disk, sometimes in what’s called a backup zone data

5 In Unix-y operating systems, the resolver is often part of the standard shared C library, libc, or glibc.
file. When the secondary periodically transfers a new version of the zone from its
master DNS server, it updates the data on disk. The backup data is useful if the secon‐
dary DNS server should restart because it can initially load the backup data, then
check to see whether that data is still up to date with the version of the zone on the
master DNS server. If it is, no zone transfer is necessary. And if the master DNS
server is unavailable, the secondary DNS server still has zone data it can answer with.
Figure 2-4 shows you the relationship between primary and secondary DNS servers.
Figure 2-4. The relationship between primary and secondary DNS servers
Both the primary and secondary DNS servers for a zone are said to be authoritative
for the zone. This means that they can answer any query for a domain name in the
zone definitively. (Other DNS servers, you’ll see, might have cached answers to quer‐
ies, which might or might not still be current.)
A single DNS server can be authoritative for many zones at the same time and can be
primary for some and secondary for others. Internet service providers and DNS
hosting companies often run DNS servers that are authoritative for hundreds of thou‐
sands of zones.
That’s enough about DNS servers for now. Let’s move on to resolvers, the other main
software component of the Domain Name System.
Resolvers
Resolvers are the client half of the DNS. Unlike DNS servers, they’re often not distinct
pieces of software. Instead, they’re functionality built in to an OS such as Windows,
MacOS X, or iOS.5
Even very simple internet devices usually have resolvers built in to
their firmware.
Resolvers take applications’ requests for information about a domain name and
translate them into DNS queries. They then send those queries to DNS servers and
Resolvers | 11

await responses. If the resolver doesn’t receive a response to a given query within a
reasonable amount of time (typically a second or a few seconds at most), it might
retransmit the query to the same DNS server, or it might try querying a different
DNS server. When it receives a response, the resolver unpacks it into a data structure
that it passes back to the application. Some resolvers do even more, including caching
recently returned answers.
Resolvers are useful because they obviate the need for all applications that need DNS
data to speak the DNS protocol, which isn’t particularly friendly. Instead, applications
can use well-defined library functions such as getaddrinfo() or gethostbyname() to
request the information they need about a domain name, and can then retrieve that
information in a straightforward way. Resolvers aren’t very useful by themselves,
though: they need DNS servers to help them perform their function.
Resolution and Recursion
Resolution is the process by which resolvers and DNS servers cooperate to find
answers (in the form of resource records) stored in DNS’s distributed database.
Sometimes resolution is simple: A resolver sends a query to a DNS server on behalf of
an application, and the DNS server is authoritative for the zone that contains the
domain name in the query, so it responds directly to the resolver with the records
that make up the answer. However, for cases in which the DNS server isn’t authorita‐
tive for the zone that contains the answer, the resolution process is more complicated.
By default, the resolution process proceeds from the top of the DNS namespace
down. Remember that the namespace is an inverted tree: Starting at the top of the
inverted tree, you can reach any node. And the domain name in the query tells the
DNS server which “branch” to take from each node, as shown in Figure 2-5.
Figure 2-5. Resolving www.baz.example

DNS servers need a “hint” to direct them where to start, though. Clearly, they should
start at the root, but which DNS servers are authoritative for the root zone? That
information is provided by the root hints, which are usually either compiled into a
DNS server or contained in a file. The hints themselves are NS records, which we
mentioned earlier: these records give the domain names of the DNS servers authori‐
tative for the root zone. Each of the NS records has a corresponding A and AAAA
record, providing the IPv4 and IPv6 address of each root DNS server. Example 2-1
shows what the beginning of the current root hints file looks like.
Example 2-1. Beginning of the current root hints file
;
; FORMERLY NS.INTERNIC.NET
;
. 3600000 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 199.9.14.201
B.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:200::b
This excerpt shows just two of the 13 root DNS servers, a.root-servers.net and b.root-
servers.net, as well as their addresses. The single dots (“.”) at the beginning of the two
NS records stand for the root zone, whereas the dots at the end of the domain names
of the root DNS servers unambiguously anchor those domain names to the root of
the namespace, a bit like a leading slash in a pathname (/etc/hosts) anchors that path‐
name to the root of the filesystem. The numerical fields (3600000) are the time-to-live
values for the records, which we discuss shortly.
A DNS server can start resolution by sending a query to any of the root DNS servers.
The root DNS server probably won’t be authoritative for the zone containing the
domain name in the query, but will at least know the DNS servers authoritative for
the top-level zone (e.g., com, net) the domain name falls under. The root DNS server
will return the list of DNS servers authoritative for the appropriate top-level zone in a
referral to the querying DNS server. The referral contains yet more NS records, these
for the top-level zone.
The DNS server continues by querying one of the DNS servers for the top-level zone,
following referrals until it reaches the DNS servers authoritative for the domain name
in the query. When it queries one of those DNS servers, it should receive an answer
instead of a referral, as shown in Figure 2-6.
Resolution and Recursion | 13

6 You might have noticed that the terminology is backward: The DNS server that forwards the query should, by
rights, be called the forwarder. Instead, it’s the DNS server that receives the forwarded query that’s called the
forwarder.
Figure 2-6. A DNS server following referrals until receiving an answer
The process that the first DNS server follows—starting with the root DNS servers and
following referrals until it receives an answer—is called recursion. Note that the other
DNS servers in the process—the DNS servers that return the referrals—don’t perform
recursion. For example, the root DNS server doesn’t query a DNS server authoritative
for the top-level zone on behalf of the first DNS server. The root DNS server simply
replies with the most useful information it already has, NS records from its authorita‐
tive zone data. That’s because resolvers generally send recursive queries to DNS
servers, whereas DNS servers send nonrecursive, or iterative, queries to each other by
default. Accepting a recursive query obliges a DNS server to do whatever work is nec‐
essary to answer the query, including possibly following several levels of referrals. A
DNS server receiving a nonrecursive query need only respond with a referral to help
the querying DNS server on its way.
There’s one case in which a DNS server sends another DNS server a recursive query,
and that’s when the first DNS server is configured to use the second as a forwarder.
When configured to use a forwarder, a DNS server that receives a query first looks in
its authoritative zone data and cache for an answer, and if it doesn’t find one, it for‐
wards the query to its forwarder.6
Forwarders are often used to provide the ability to resolve domain names in the
internet’s namespace to DNS servers without direct connectivity to the internet: the
“internal” DNS servers are configured to use a DNS server with internet connectivity
as a forwarder.
Whoops, we slipped a little earlier. We said that DNS servers configured to use for‐
warders check their authoritative zone data and cache before consulting a forwarder.
What is this “cache” of which we speak?

7 This actually a lie. Each of the 13 root DNS servers is actually a distributed group of DNS servers that share a
single IP address using a technique called anycast. But they could still be overwhelmed.
Caching
If all recursive DNS resolution had to start with the root DNS servers, resolution
would take a long time. There are only 13 root DNS servers, after all, so in addition to
lengthening the resolution process, starting at the roots would overwhelm them with
queries.7
In practice, most DNS servers processing recursive queries don’t need to query the
root DNS servers very often. That’s because they cache the resource records in
responses.
As you saw in the root hints file, resource records have time-to-live values associated
with them. That time-to-live value is an indication to recursive DNS servers of how
long they can cache those records. Take a recursive DNS server that’s worked its way
down to the google.com DNS servers to resolve www.google.com’s AAAA records.
Along the way, it’s learned:
• The domain names and (IPv4 and IPv6) addresses of the DNS servers authorita‐
tive for com
• The domain names and addresses of the DNS servers authoritative for google.com
• The IPv6 addresses of www.google.com
Should the same DNS server receive a query for maps.google.com soon afterward, it
can skip querying a root DNS server or a com DNS server and query a google.com
DNS server first, reducing query load on the root and com DNS servers and shorten‐
ing the resolution time substantially. Similarly, resolving infoblox.com’s MX records
could begin at the com DNS servers, saving at least the roundtrip to a root DNS
server.
Next, let’s go back for a closer look at resource records, which store the data in the
DNS namespace.
Resource Records
We introduced several types of resource records earlier in this chapter, and you’ve
even seen a few in what’s called their master file format: the NS, A and AAAA records
in the root hints file. Master file format is the format in which resource records
appear in zone data files: primary DNS servers read zone data in this format, as do
secondary DNS servers (when they read backup zone data files).
Caching | 15

Records in master file format have the following general format:
[NAME] [TTL] [CLASS] TYPE RDATA
We walk through each field in the following sections, starting with the NAME field.
NAME
The NAME field contains the domain name to which this resource record is attached.
This can be a fully qualified domain name (FQDN), ending in a dot, or a relative
domain name, which doesn’t end in a dot. Relative domain names are interpreted as
ending in the current origin, which by default is the domain name of the zone that the
zone data file describes. That’s handy, because if you’re writing the zone data file for
foo.example, you’d rather not have to type “foo.example” at the end of each name.
If you want to refer to the origin itself, rather than have it appended to the name you
type, you use “@” in the NAME field, with no trailing dot. You can also use a single dot
(“.”) to refer to the root, though you usually wouldn’t use that in the NAME field of a
resource record unless you were editing the root zone data file or root hints file.
As you can see from the format we showed you a moment ago, the NAME field is
optional. If the NAME field is omitted, the line must start with whitespace, and the
resource record specified on the line is attached to the most recently specified domain
name.
Example 2-2 demonstrates some NAME fields.
Example 2-2. NAME fields in the foo.example zone data file
@ 3600 IN A 10.0.0.1 # Attached to foo.example, the origin
foo.example. 3600 IN A 10.0.0.2 # Also attached to foo.example
www 3600 IN A 10.0.0.3 # Attached to www.foo.example
3600 IN A 10.0.0.4 # Also attached to www.foo.example
Next comes the TTL field.
TTL
The TTL field specifies the time-to-live (TTL) value for the resource record, which
governs how long a recursive DNS server can cache the record. The TTL is natively
(i.e., on the wire) a 32-bit integer number of seconds, and you can specify TTLs that
way, but you can now also use scaling factors such as “s” for seconds, “m” for minutes,
“h” for hours, “d” for days, and “w” for weeks, as in “1d,” “30m,” or “1h30m.” This will
obviate the need for you to waste precious brain capacity remembering things like
“There are 86400 seconds in a day.”

If the TTL is not specified for a resource record, the record inherits the most recently
specified TTL value. Example 2-3 shows the TTL field in action.
Example 2-3. TTL fields in the foo.example zone data file
@ 3600 IN A 10.0.0.1 # TTL of 3600 seconds, or 1 hour
1h IN A 10.0.0.2 # Same thing
www 1h30m IN A 10.0.0.3 # TTL of 1 hour and 30 minutes, or 90 minutes
IN A 10.0.0.4 # TTL from precious record, so 90 minutes
After the TTL field comes the CLASS field.
CLASS
As stated previously in this chapter, the CLASS field is almost always IN, for internet,
so it should come as no surprise that IN is the default. There are other classes, such as
CH for ChaosNet and HS for Hesiod, but you’ll rarely see them in use, because the
functions those other classes were meant to serve never took off.
Resource Record Types
The resource record types that we introduced earlier, such as A for an IPv4 address
and AAAA for an IPv6 address, are properly called type mnemonics. Each resource
record type has a unique type mnemonic. On the wire, the type mnemonic translates
into a numeric type code, but it’s much easier to remember the mnemonic (or they
wouldn’t call it a mnemonic, would they?).
As we said earlier, each resource record type requires a certain syntax for the data that
follows the type mnemonic, called RDATA. Let’s go through some of the most com‐
mon record types and their RDATA syntax.
The A Record
The A record maps the domain name to which it’s attached to a single IPv4 address.
Consequently, the A record’s RDATA field is a single IPv4 address in dotted-octet nota‐
tion, as demonstrated in Example 2-4.
Example 2-4. An A record
www.foo.example. 300 IN A 10.0.0.1
To map a single domain name to multiple IPv4 addresses, you simply add multiple A
records to the domain name, as shown in Example 2-5.
Resource Record Types | 17

8 This is described in RFC 4291, if you’re interested.
Example 2-5. Multiple A records
www 1h IN A 10.0.0.1
1h IN A 10.0.1.1
The AAAA Record
Like the A record, the AAAA record maps the domain name to which it’s attached to
an IP address, but an IPv6 address rather than an IPv4 address. The AAAA record’s
RDATA field, then, contains a single IPv6 address in the standard, colon-separated,
hexadecimal notation,8
as illustrated in Example 2-6.
Example 2-6. An AAAA record
www 30m IN AAAA 2001:db8:42:1:1
As with A records, to map a single domain name to multiple IPv6 addresses, you just
add multiple AAAA records to the domain name, as shown in Example 2-7.
Example 2-7. Multiple AAAA records
www 30m IN AAAA 2001:db8:42:1:1
30m IN AAAA 2001:db8:42:2:1
The CNAME Record
You use the CNAME record to create an alias from one domain name to another. The
CNAME record is attached to the domain name that is the alias; the CNAME
record’s RDATA is the domain name that the alias points to, called a canonical name
(hence, “CNAME”). Example 2-8 demonstrates how it works.
Example 2-8. A CNAME record
alias.foo.example. 1d IN CNAME canonicalname.foo.example.
There are several rules that govern the use of CNAME records:
• The domain name that is the alias can’t have any other record types attached to it.
That’s because of the way DNS servers process CNAME records: a recursive DNS
server looking up alias.foo.example’s AAAA records, for example, would receive
the record in Example 2-8 from an authoritative DNS server for foo.example. The
recursive DNS server would then restart the query, this time looking for AAAA

records for canonicalname.foo.example. If attaching a AAAA record directly to
alias.foo.example were permitted, the results of looking up AAAA records for
alias.foo.example would be ambiguous.
• A corollary to the preceding rule is that the domain name of a zone (e.g.,
foo.example) can’t own a CNAME record, because by definition it must own a
start of authority (SOA) record.
• CNAME records can point one alias to another alias, but you should be careful
not to create a loop (a is an alias for b and b is an alias for a), and you shouldn’t
create too long a chain of aliases, because recursive DNS servers typically limit
the number of CNAME records that they’ll follow.
The MX Record
You use the MX record to direct email addressed to a particular domain name; in
particular, it designates mail exchangers (hence, “MX”) for a domain name.
When a mail transport agent (or MTA) has an email message addressed to some
user@domain.name, it must determine where to send that message. The MTA could
just look up the A or AAAA records for domain.name, but MTAs on the internet look
up MX records first. (They often fall back to looking up A and AAAA records if no
MX records are available.)
An MX record specifies the domain name of a mail exchanger for a domain name
and a preference value associated with that mail exchanger. The preference is an
unsigned, 16-bit value, so between 0 and 65535, in decimal terms. (The preference
actually precedes the mail exchanger.) Example 2-9 shows an MX record.
Example 2-9. An MX record
foo.example. 3d IN MX 10 mail.isp.net.
This MX record tells an MTA, “If you have an email message addressed to a user at
foo.example such as cricket@foo.example), send it to mail.isp.net. It’s handy to be able
to specify the domain name of a mail exchanger rather than its address because
nowadays so many organizations use email hosting services rather than running their
own mail servers, and you wouldn’t want to have to track changes your hosting ser‐
vice made to the addresses of its mail servers.
The preference value is significant only if a domain name owns multiple MX records.
In that case, an MTA is supposed to sort the MX records it finds for the domain
name, lowest preference value (i.e., closest to zero) to highest preference value, and
attempt delivery first to the mail exchanger with the lowest value. The MTA can try a
mail exchanger at a higher preference value only after it has attempted delivery to all

mail exchangers with lower preference values. This makes it possible to list backup
mail servers for your domain name, as shown in Example 2-10.
Example 2-10. Multiple MX records
@ 3d IN MX 0 mail.foo.example.
3d IN MX 10 mail.isp.net.
The NS Record
The NS record is somewhat similar to an MX record: it designates a name server for a
given zone. The NS record’s RDATA is the domain name of a DNS server authorita‐
tive for the zone to which the record is attached. For example, the NS record in
Example 2-11 says that you’ll find a DNS server authoritative for foo.example running
at ns1.foo.example:
Example 2-11. NS record
foo.example. 1d IN NS ns1.foo.example.
Unlike most types of resource records, NS records attached to a given domain name
typically appear in two different zones: the zone with the specified domain name and
in that zone’s parent zone. Take the foo.example NS record in Example 2-11. We’d find
it in the foo.example zone, of course, but also in the example zone.
In the example zone, the NS record is responsible for delegating the foo.example sub‐
zone to ns1.foo.example. In fact, it’s probably part of a larger set of NS records for
foo.example, as shown in Example 2-12.
Example 2-12. Multiple NS records
foo.example. 1d IN NS ns1.foo.example.
1d IN NS ns2.foo.example.
1d IN NS ns1.isp.net.
A DNS server authoritative for the example zone would return these NS records any
time it was queried for a domain name in foo.example, effectively saying, “If you’re
interested in domain names that end in foo.example, you should talk to one of these
three DNS servers.” This is called a referral.
So what function do the foo.example NS records in the foo.example zone serve? After
all, it’s not as though, after it finds its way to the DNS servers authoritative for
foo.example, a recursive DNS server needs another referral to those same DNS
servers.

9 These symbolic names are often taken from STD 2, RFC 1700.
Actually, in many cases, when the authoritative foo.example DNS server responds to
the recursive DNS server’s query, it will include its list of NS records for foo.example
in the response. That way, if the set of NS records in the foo.example zone differs from
the set in the example zone, recursive DNS servers will still eventually learn and use
the NS records in the authoritative zone data.
The set of NS records in the foo.example zone is also used by the zone’s primary DNS
server to determine where to send the NOTIFY messages that let the zone’s secondary
DNS servers know that the zone data has changed. (In fact, the secondaries might
also use the NS records, if they send NOTIFY messages to other secondaries.)
Finally, the NS records also inform clients attempting to dynamically
update foo.example domain names as to which DNS servers to try sending them to.
The SRV Record
The MX record provides a helpful level of abstraction between the domain name
used in an email address and the mail servers that handle email for that destination.
Similarly, the SRV record provides a layer of abstraction between domain names and
the servers for, well, clients of just about any service.
SRV records are unique in that the domain names they are attached to have a
prescribed format:
_service._protocol.domainname
The first label of the domain name is an underscore character followed by the sym‐
bolic name of a service, such as HTTP; the second label is an underscore followed by
the symbolic name of a protocol, such as UDP, for the User Datagram Protocol or
TCP, for the Transmission Control Protocol.9
The domain name is any domain name.
Clients interested in a particular service running over a particular protocol at a cer‐
tain destination domain name would concatenate the service, protocol, and destina‐
tion domain name to form a new domain name and then look up the SRV records for
that domain name.
The underscore characters were chosen deliberately to minimize the chance that the
domain names to which SRV records are attached would collide with existing domain
names.
The RDATA of an SRV record has four fields:
Priority
An unsigned, 16-bit integer that functions like the MX record’s preference. Cli‐
ents of the service would first try to connect to the target with the lowest priority

value; they would try targets with higher priority values only after trying all tar‐
gets at lower values.
Weight
Another unsigned, 16-bit integer. When two or more targets share the same pri‐
ority, clients are supposed to try to communicate with them in proportion to
their associated weights. All of the weights of targets at the same priority are
added; each target should receive a share of clients in proportion to its weight rel‐
ative to the sum. So, two targets with the same priority and equal weights of 10
should each receive half of the clients. If one target has a weight of 200 and
another has a weight of 100, the first target should receive two-thirds of the cli‐
ents. (Of course, if a client can’t successfully connect to the first target, it will try
the other.)
Port
Yet another unsigned, 16-bit integer specifies the port on which the service runs.
This is handy because it allows you to run services on any available port: if you’re
already running a web server on the HTTP port, TCP port 80, you can run an
HTTP-based API server on another port and direct clients to it with an appropri‐
ate SRV record.
Target
This is the domain name of a server that offers the specified service. The domain
name must own one or more A or AAAA records.
Examples 2-13 and 2-14 present two samples of SRV records.
Example 2-13. One example of SRV records
api.foo.example. 1m IN SRV 10 100 8080 api1.foo.example.
# Connection to this server half the time
1m IN SRV 10 100 8080 api2.bar.example.
# ...and to this server half the time
Example 2-14. A more complicated example of SRV records
api.bar.example. 60 IN SRV 100 200 80 api1.bar.example.
# First try this server 2/3 of the time
60 IN SRV 100 100 8080 api2.bar.example.
# ...or this server 1/3 of the time
60 IN SRV 200 100 8080 api1.foo.example.
# And this server if neither of the others are available

The PTR Record
Mapping domain names to IP addresses is straightforward: you look up the A or
AAAA record associated with the domain name. But what about mapping IP
addresses back to domain names—something you might want to do for logging pur‐
poses or as a (weak) check of a client’s identity? How do you do that?
To provide this function, DNS requires a special namespace—two, in fact. One is the
domain in-addr.arpa, used to “reverse-map” IPv4 addresses to domain names. The
other is ip6.arpa, used to reverse-map IPv6 addresses to domain names.
The labels under in-addr.arpa are the four octets of an IPv4 address, in reverse order:
octet4.octet3.octet2.octet1.in-addr.arpa. Putting the most significant octet of the IPv4
address last makes sense, when you think about it: This way, the domain 32.128.in-
addr.arpa corresponds to the IPv4 network 128.32/16, which happens to be owned by
U.C. Berkeley. The folks who run in-addr.arpa can then delegate 32.128.in-addr.arpa
to the folks at Berkeley responsible for the network.
So to reverse-map the IPv4 address 10.0.0.1 to a domain name, you look up PTR
records for 1.0.0.10.in-addr.arpa. The format of the PTR record is very simple: The
RDATA is just a single domain name, the domain name that the corresponding IP
address should map to, as shown in Example 2-15.
Example 2-15. A PTR record
1.0.0.10.in-addr.arpa. 1d IN PTR host.foo.example.
IPv6 works in a similar fashion, though it requires longer domain names. To form the
domain name that corresponds to an IPv6 address, you write all 32 of the hexadeci‐
mal digits of the IPv6 address in reverse order, each digit separated from the next by a
dot, with ".ip6.arpa" appended to the end. So, for example, the IPv6 address
2001:db8:42:1:1 expands to 2001:0db8:0042:0001:0000:0000:0000:0001 and is
then transformed into the domain name shown here:
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.2.4.0.0.8.b.d.0.1.0.0.2.ip6.arpa
As with IPv4, encoding the most significant hexadecimal digit of the address first
makes delegation easier. And just as with IPv4, you attach a PTR record to the result‐
ing domain name, as shown in Example 2-16.
Example 2-16. A PTR record for an IPv6 address
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.2.4.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
1d IN PTR host-v6.foo.example.

The SOA Record
The SOA record provides summary information about a zone; consequently, there’s
only one SOA record per zone, and it must be attached to the domain name of the
zone. The SOA record’s RDATA format consists of seven fields:
• The MNAME field, which by convention is the domain name of the primary
DNS server for the zone.
• The RNAME field, which by convention is the email address of a person or per‐
sons responsible for the zone. The format of the email address is a little peculiar:
The “@” symbol in the email address is replaced with a dot (“.”), so
“cricket@foo.example” would become “cricket.foo.example.”
• The zone’s serial number, an unsigned 32-bit value.
• The zone’s refresh interval, also an unsigned 32-bit value representing a duration.
It can also be written as a scaled value, such as “1d” for one day or “30m” for 30
minutes.
• The zone’s retry interval, likewise an unsigned 32-bit value representing a
duration.
• The zone’s expiration interval, an unsigned 32-bit value representing a duration.
• The zone’s negative-caching TTL, an unsigned 32-bit value representing a
duration.
Example 2-17 shows an SOA record.
Example 2-17. An SOA record
foo.example. 1d IN SOA ns1.foo.example. root.foo.example. (
2019050600 ; Serial number
1h ; Refresh interval
15m ; Retry interval
7d ; Expiration interval
30m ) ; Default and negative-caching TTL
Note the "(" at the end of the first line of the record and matching ")" on the last line:
This tells the DNS server to ignore carriage returns and newlines that occur between
the parentheses. This syntax is legal for use with any record type, but you’ll rarely see
an SOA record that doesn’t use it. The comments (beginning with ";" and extending
to the end of the line) are also legal anywhere in a zone data file, but are particularly
handy in the SOA record for DNS administrators who can’t always remember what all
seven RDATA fields mean.
The MNAME and RNAME fields are mostly read by people and ignored by software.
For example, another DNS administrator having a problem with your zone or its
DNS servers might look up your zone’s SOA record to find your RNAME field and
dash you off a quick question in email. The only exception is that some DNS software

uses the MNAME field to help decide where to send dynamic updates for a zone, and
secondary DNS servers for a zone typically don’t send NOTIFY messages to the pri‐
mary DNS server listed in MNAME.
The serial number and the refresh, retry, and expiration intervals are all related to
zone transfers. The serial number is an indication of the version of a zone that a given
authoritative DNS server holds. After each refresh interval, a secondary DNS server
for a zone checks with its master DNS server (often the zone’s primary) to see
whether the master’s serial number for the zone is higher than the secondary’s. If the
master has a higher serial number, the secondary requests a copy of the latest version
of the zone with a zone transfer. If the check fails for some reason, the secondary
keeps checking with the master at the retry interval (usually shorter than the refresh
interval) until it successfully learns whether it needs a new version of the zone. And if
the checks fail for the entire expiration interval (usually several refresh intervals), the
secondary assumes its zone data is now out of date and expires the zone. After expir‐
ing the zone, a secondary will respond to queries in the zone with a Server Failed
response code. This is illustrated in Figure 2-7.
Figure 2-7. The relationship between the refresh, retry, and expire timers
The importance of the refresh interval has diminished somewhat since the advent of
NOTIFY messages, which master DNS servers send to secondaries to inform them
that a zone’s data has changed. Still, it’s a good idea to set a zone’s refresh interval to a

sensible value, no more than an hour or so, because the cost of the secondary’s check
of its master DNS server is so low: a single DNS query. The retry interval should usu‐
ally be some fraction of the refresh interval; for instance, half or one-quarter. Because
the consequences are fairly severe—responding to any queries in the zone with an
error—the expiration interval should be long enough to give you time to notice that
your secondary DNS server hasn’t been able to communicate with its master and take
corrective action. In practice, we usually set the expiration to at least one week.
The final field is the zone’s negative-caching TTL. The negative-caching TTL specifies
to other DNS servers how long they can cache negative responses from this zone’s
authoritative DNS servers. Negative responses include the following:
• No such domain name, indicating that the domain name in the query doesn’t
exist
• No such data, indicating that the domain name exists but there are no records of
the type requested in the query
An authoritative DNS server for a zone includes the zone’s SOA record in its negative
responses so that the recursive DNS server that sent the query can determine how
long it can cache the response.
Negative caching is very helpful in preventing your authoritative DNS servers from
being bombarded with queries for the same, nonexistent domain name or record, but
you shouldn’t set the negative caching TTL too high, or it could hamper the resolu‐
tion of brand-new domain names you add to your zone.
Whew! For “just enough” DNS theory, that’s quite a bit. Let’s just walk through a com‐
plete zone data file and call it a chapter.
An Annotated Zone Data File
Let’s take a look at a complete (but hypothetical) zone data file. This should help give
you a feeling for what to expect when reading others’ zone data files or when writing
your own. You might even decide that you like the formatting we use and follow our
example.
Example 2-18 shows a zone data file for a zone we’ll call foo.example.
Example 2-18. A zone data file for foo.example
@ 1d IN SOA ns1.foo.example. root.foo.example. (
2019050800 ; Serial number
1h ; Refresh interval
15m ; Retry interval
7d ; Expiration interval
10m ; Negative-caching TTL

IN NS ns1.foo.example.
IN NS ns2.foo.example.
IN MX 0 mail.foo.example.
IN MX 10 mta.isp.net.
IN A 192.168.1.1
IN AAAA 2001:db8:42:1::1
www 5m IN CNAME @
ns1 IN A 192.168.1.53
IN AAAA 2001:db8:42:1::53
ns2 IN A 192.168.2.53
IN AAAA 2001:db8:42:2::53
mail IN A 192.168.1.25
IN AAAA 2001:db8:42:1::25
_http._tcp.www IN SRV 0 0 80 foo.example.
_https._tcp.www IN SRV 0 0 443 foo.example.
The zone data file starts, as most do, with the SOA record, providing overall informa‐
tion about the zone. The SOA record is attached to @, the origin in the zone data file,
which is foo.example by default.
The two NS records specify the authoritative DNS servers for foo.example,
ns1.foo.example, and ns2.foo.example. These NS records are used mainly by ns1 and
ns2 themselves, for determining where to send NOTIFY messages, and possibly by
software trying to determine where to send dynamic updates to the foo.example zone.
(There should be a matching set of NS records in the example zone that actually dele‐
gate foo.example to ns1 and ns2.)
The MX records designate mail.foo.example and mta.isp.net as the mail exchangers
for email addressed to foo.example. Given the preferences, mta.isp.net is likely a
backup mail exchanger.
The A and AAAA records for foo.example point to the IPv4 and IPv6 addresses,
respectively, of the foo.example web server. Attaching A and AAAA records directly
to foo.example lets users type just “http://foo.example/” instead of “http://
www.foo.example/”, saving a few keystrokes.
The CNAME record creates an alias from www.foo.example to foo.example. Now users
can type either “http://www.foo.example/” or “http://foo.example/” and get to the web
server, and the DNS administrator only needs to edit one IPv4 or IPv6 address if an
address changes. (The alias applies to protocols besides HTTP, of course, so users can
also send mail to someuser@www.foo.example.)
An Annotated Zone Data File | 27

The next six resource records give IPv4 and IPv6 addresses for ns1.foo.example,
ns2.foo.example, and mail.foo.example. Clearly the network administrators of
foo.example have done the work necessary to dual-stack their network—as should
you!
The final two records are SRV records that direct SRV-savvy web clients to foo.exam‐
ple: the first SRV record applies to HTTP traffic, whereas the second applies to
HTTP-S. Note that the target field contains foo.example, not www.foo.example:
www.foo.example is an alias, so it shouldn’t appear in the RDATA of an SRV record
(or an MX record, for that matter).
Hopefully that gives you a good overview of how the Domain Name System works,
including the roles of DNS servers and resolvers, the structure of the DNS name‐
space, and the syntax and semantics of various resource records. In the next chapter,
we finally dive into what you’ve probably been waiting for: configuring your first
CoreDNS-based DNS server!

CHAPTER 3
Configuring CoreDNS
In Chapter 2, we covered basic DNS theory. That was to prepare you for the fun and
excitement of configuring a CoreDNS server, which we do in this chapter.
CoreDNS is configured using a configuration file called the Corefile. The syntax of the
Corefile follows that of the Caddyfile, given that CoreDNS actually uses the Caddy
code to parse the configuration. First, though, we need to get CoreDNS set up.
Getting CoreDNS
Before configuring CoreDNS and writing your first Corefile, you need a copy of the
coredns executable for your OS. The easiest way to find executables of the latest ver‐
sion of CoreDNS for your OS is to start at the coredns.io website. There, you’ll see a
prominent button labeled Download, as shown in Figure 3-1.
Figure 3-1. The Download button on coredns.io
29

1 If you’re wondering why you’d want to do that, or how to do it, see Chapter 9.
Clicking Download takes you directly to the part of the CoreDNS GitHub repository
where you can download the coredns executable, as illustrated in Figure 3-2.
Figure 3-2. The CoreDNS GitHub repository
If you’d prefer to build your own copy of coredns, you can download the source code
(zip, tar, or GZIP, according to your preference) from one of the two links at the bot‐
tom of the page.1
Otherwise, choose the file appropriate for the OS you’re running
and the processor it’s running on. Here’s a guide:
• “Darwin” is MacOS X
• There are builds of CoreDNS for many different processors, including AMD,
ARM, 64-bit ARM, PowerPC, and IBM’s S/390
30 | Chapter 3: Configuring CoreDNS

• Windows is... well, Microsoft Windows
After you’ve downloaded the file, download the accompanying checksum file, which
has the same name as the file you’ve downloaded with .sha256 appended. Run your
favorite checksum program against the first file to generate its SHA-256 checksum.
For example, on MacOS X, you could run the following:
% shasum -a 256 coredns_1.4.0_darwin_amd64.tgz
On Linux operating systems, you might use the sha256sum program.
Compare the result to the contents of the .sha256 file and make sure they match. If
not, your download might have been corrupted.
After you’ve verified that the file downloaded correctly, you can extract the coredns
executable. For tar and gzip files, you can use the following:
% tar -zxvf coredns_1.4.0_darwin_amd64.tgz
x coredns
The coredns executable extracts into the current working directory; you can move it
wherever you’d like. You can make sure it works by running it with the -version
command-line option; it should print something like the following:
% coredns -version
CoreDNS-1.4.0
darwin/amd64, go1.12, 8dcc7fc
That looks reasonable, so we can move on to configuring CoreDNS.
CoreDNS Command-Line Options
Now that you have a working copy of CoreDNS, let’s look at the command-line
options it supports:
-conf
Specifies the path to CoreDNS’s configuration file. The default is Corefile in core
dns’s working directory.
-cpu
Specifies the maximum CPU percentage coredns is allowed to use. The default is
100%. You can specify the percentage either as an integer (e.g., “50”) or as a per‐
centage (e.g., “50%”).
This option has been deprecated, and might not be sup‐
ported in newer versions of CoreDNS.
CoreDNS Command-Line Options | 31

Another Random Scribd Document
with Unrelated Content

“Oh, there’s dear Sister Watt,” cried Miss Tremont, and she rose
precipitately, and crossing the aisle sat down beside a careworn
anxious-eyed woman who also wore the white ribbon.
“Come over by me until Miss Tremont comes back,” said Miss
Beale, with her brilliant smile. “Tell me, don’t you love her already?
Oh, you have no idea how good she is. She is heart and soul in her
work, and just lives for the Lord. She sometimes visits twenty poor
families a week, besides her Temperance class, her sewing school,
her Bible Readings, her Bible class, and all the religious societies, of
which she is the most active worker. She is also the Mariaville agent
for the Society for Prevention of Cruelty to Children, and trustee of
the Bible Society. You should hear her pray. I have heard all the
great revivalists, but I have never heard anything like Miss Tremont’s
prayers. How I envy you living with her! You’ll hear her twice a day,
and sometimes oftener. She has a nice house on the outskirts of
Mariaville. Her father left it to her twenty years ago, and she
dedicated it to the Lord at once. It is headquarters for church
meetings of all sorts. She has a Bible reading one afternoon a week.
Any one can go, even a servant, for Miss Tremont, like all true
followers of the Lord, is humble.”
Patience reflected that she had never seen any one look less
humble than Miss Beale. In spite of her old frock she conveyed with
unmistakable if unconscious emphasis that she possessed wealth
and full knowledge of its power.
“You look so happy,” Patience said, her curiosity regarding Miss
Tremont blunted for the present. “Are you?”
“Happy? Of course I am. I’ve never known an unhappy moment
in my life. When my dear parents died, I only envied them. And have
I not perfect health? Is not every moment of my time occupied?—
why, I only sleep six hours out of the twenty-four. And Him. Do I not
work for Him, and is He not always with me?”
“They are so funny about God,” thought Patience. “She talks as if
He were her beau; and Miss Tremont as if He were her old man
she’d been jogging along with for forty years or so.—Do you live
alone?” she asked.
“Yes—that is, I board.”

“And don’t you ever feel lonesome?”
“Never. Is not He always with me?” Her strong brown face was
suddenly illuminated. “Is He not my lover? Is He not always at my
side, encouraging me and whispering of His love, night and day?
Why, I can almost hear His voice, feel His hand. How could I be
lonesome even on a desert island with no work to do?”
Patience gasped. The extraordinary simplicity of this woman of
fifty fascinated her whom life and heredity had made so complex.
But she moved restlessly, and felt an impulse to thrust out her legs
and arms. She had a sensation of being swamped in religion.
“I shouldn’t think you’d like boarding,” she said irrelevantly.
“I don’t like it particularly, but it gives me more time for my work.
I make myself comfortable, I can tell you, for I have my own bed
with two splendid mattresses,—my landlady’s are the hardest things
you ever felt,—and all my own furniture and knick-knacks. And I
have my own tub, and every morning even in dead of winter, I take
a cold bath. And I don’t wear corsets—”
“Mariaville,” called the conductor.
“Oh, here we are,” cried Miss Tremont. She made a wild dive for
her umbrella and bag, seized Patience by the hand, and rushed up
the aisle, followed leisurely by Miss Beale.
The snow was falling heavily. Patience had watched it drift and
swirl over the Hudson, and should have liked to give it her undivided
attention.
As they left the station they were greeted by a chorus of shrieks:
“Have a sleigh? Have a sleigh?”
“What do you think, sister?” asked Miss Tremont, dubiously. “Do
you think Patience can walk two miles in this snow? I don’t like to
spend money on luxuries that I should give to the Lord.”
“Perhaps the sleigh man needs it,” said Patience, who had no
desire to walk two miles in a driving storm.
“We’d better have a sleigh,” said Miss Beale, decidedly. “We will
each pay half.”
“But why should you pay half,” said Miss Tremont, in her
protesting voice, “when there are three of us?”

“I will pay for myself,” said Patience. “Mr. Foord gave me a twenty
dollar gold piece, and I haven’t spent it.”
“Oh, dear child!” exclaimed Miss Tremont. “As if I’d let you.”
“Come, get in,” said Miss Beale; “we’ll be snowed under, here.”
And a few minutes later Patience, on the front seat, was enjoying
her first sleigh-ride. She slid down under the fur robe, and winking
the snow stars from her lashes, looked out eagerly upon Mariaville.
The town rose from the Hudson in a succession of irregular
precipitous terraces. The trees were skeletons, the houses old, but
the effect was very picturesque; and the dancing crystals, the faint
music of bells from far and near, the wide steep streets, delighted a
mind magnetic for novelty.
They left Miss Beale before a pretty house, standing in a frozen
garden, then climbed to the top of a hill, slid away to the edge of
the town, and drew rein before an old-fashioned white one-winged
house, which stood well back in a neglected yard behind walnut-
trees and hemlocks. Beyond, closing the town, were the stark
woods. Opposite was a prim little grove in which the snow stars
were dancing.
“Here we are,” said Miss Tremont, climbing out. “Welcome home,
Patience dear.” She paid the man, and hurried down the path. The
door was opened by an elderly square-faced woman, who looked
sharply at Patience, then smiled graciously.
“Patience, this is Ellen. She takes good care of me. Come in.
Come in.”
The narrow hall ran through the main building, and was
unfurnished but for a table and the stair. Miss Tremont led the way
into a large double room of comfortable temperature, although no
fire was visible. Bright red curtains covered the windows, a neat
black carpet sprinkled with flowers the floor. The chairs were stiffly
arranged, but upholstered cheerfully, the tables and mantels
crowded with an odd assortment of cheap and handsome
ornaments. The papered walls were a mosaic of family portraits. In
the back parlour were a bookcase, a piano piled high with hymn-
books, and a dozen or so queer little pulpit chairs. A door opened
from the front parlour into a faded but hospitable dining-room.

Patience for the first time in her life experienced the enfolding of
the home atmosphere, an experience denied to many for ever and
ever. She turned impulsively, and throwing her arms about Miss
Tremont, kissed and hugged her.
“Somehow I feel all made over,” she said apologetically, and
getting very red. “But it is so nice—and you are so nice—and oh, it is
all so different!”
And Miss Tremont, enraptured, first wished that this forlorn
homely little waif was her very own, then vowed that neither should
ever remember that she was not, and half carried her up to the
bedroom prepared for her, a white fresh little room overlooking the
shelving town.

III
The next afternoon a sewing woman came and cut down an old-
fashioned but handsome fur-lined cloak of Miss Tremont’s to
Patience’s diminutive needs. When Miss Tremont returned home,
after a hard day’s work, she brought with her a hood, a pair of
woollen gloves, and a pair of arctics; and Patience felt that she could
weather a New York winter.
But Patience gave little attention to her clothes. When she was
not watching the snow she was studying the steady stream of
people who called at all hours, and invariably talked “church” and
“temperance.” The atmosphere was so charged with religion that she
was haunted by an uneasy prescience of a violent explosion during
which Miss Tremont and her friends would sail upward, leaving her
among the débris.
Her coat finished, she went in town with Miss Tremont to
Temperance Hall. The snow had ceased to fall. The sun rode solitary
on a cold blue sky, the ground was white and hard. The bare trees
glittered in their crystal garb, icicles jewelled the eaves of the
houses. The telegraph wires, studded with pendent spheres, looked
like a vast diamond necklace of many strings which only Nature was
mighty enough to wear. The hills were snowdrifts. The Hudson, far
below, moved sluggishly under great blocks of ice. The Palisades
were black and white. Miss Tremont and Patience walked rapidly,
their frozen breath waving before them in fantastic shapes. It was all
very delightful to Patience, who thrust her hands into her deep
pockets and would have scorned to ride. At times she danced; new
blood, charged with electricity, seemed shooting through her veins.
Miss Tremont’s older teeth clattered occasionally. She bent forward
slightly, her brow contracted over eyes which seemed ever seeking
something, her long legs carrying her swiftly and with surprising
grace. Patience had solved the enigma of her voice after hearing her
pray, and she supposed that her eyes were on loyal watch for the
miseries of the world.

After a time they descended an almost perpendicular hill to the
business part of the town. Beyond a few level streets the ground
rose again, wooded and thickly built upon. On the left was another
hill, which, Miss Tremont informed her, was Hog Heights, the quarter
of the poor.
The streets in the valley twisted and doubled like the curves of
an angry python. In the centre was a square which might have been
called Rome, since all ways led to it.
Temperance Hall, a building of Christian-like humility, stood on a
back street flanked by many low-browed shops. On the first floor
were the parlour, reading-room, and refectory, on the second a large
hall, on the third bedrooms. The hall was already half full of boys
and girls, kept in order by the matron, Mrs. Blair, a middle-aged
woman with the expression of one who stands no nonsense.
“Now, Patience,” said Miss Tremont, “you listen attentively, and
next time you can take Mrs. Blair’s place.”
The occasion was the weekly assemblage of the Loyal Legion
children, who were being educated in the ways of temperance. Miss
Tremont opened with the Lord’s Prayer, which she invested with all
its meaning; then the children sang from a temperance hymn-book,
and the lesson began. Miss Tremont read a series of questions
appurtenant to the inevitable results of unholy indulgence, to which
Mrs. Blair read the answers, which in turn were repeated by the
children. Then they sang “Down with King Alcohol,” a minister came
in and made a dramatic address, and the children, some of whom
were attentive and some extremely naughty, filed out.
“I only come on alternate Fridays,” said Miss Tremont, as they
went downstairs; “Sister Beale takes the other. Come and see our
reading-room. These are our boarders,” indicating several prim old
maids that sat in the front room by the window.
In the dining-room a half dozen tramps were imbibing free soup.
The reading-room was empty.

IV
Before a week had passed Patience was so busy that her old life
slept as heavily as a bear in winter. She passed her difficult
examinations and entered the High School, selecting the three years
course, which included French, German, mathematics, the sciences,
literature, and rhetoric.
The recesses and evenings were spent in study, the afternoons in
assisting Miss Tremont; occasionally she snatched an hour to write
to her friends in California. Besides the temperance work, she had a
class in the church sewing school, kept the books of various
societies, and occasionally visited the poor on Hog Heights. The
work did not interest her, but she was glad to satisfactorily repay
Miss Tremont’s hospitality. But had she wished to protest she would
have realised its uselessness: she was carried with the tide. It might
be said that Miss Tremont was the tide. Her enthusiasm had no
reflex action, and tore through obstacles like a mill-race. When night
came she was so weary that more than once Patience offered to put
her to bed; but the offer was declined with a curious mixture of
religious fervour and hauteur. Miss Tremont had none of the ordinary
vanity of woman, but she resented the imputation that she could not
work for the Lord as ardently at sixty as she had at forty.
When she prayed Patience listened with bated breath. A torrent
of eloquence boiled from her lips. All the shortcomings and needs of
unregenerate Mariaville, individual and collective, were laid down
with a vehement precision which could leave the Lord little doubt of
His obligations. The Temperance Cause was rehearsed with a
passion which would have thrilled the devil. Sounding through all
was a wholly unselfconscious note of command, as when one pleads
with the pocket of an intimate friend for some worthy cause.
Patience saw so many disreputable people at this time that her
mother’s pre-eminence was extinguished. They had a habit of
commanding the hospitalities of Miss Tremont’s barn, sure of two
meals and a night’s lodging. Miss Tremont insisted upon their

attendance at evening prayers, and Patience assumed the task of
persuading them to clean up. Her methods were less gentle than
Miss Tremont’s: when they refused to wash she turned the hose on
them.
Projected suddenly into the dry bracing cold of an eastern winter
she quickly became robust. Before spring had come, her back was
straight and a faint colour was in her rounding cheeks. If there had
been time to think about it, or any one to tell her, she would have
discovered that she was growing pretty. But at this time, despite the
distant advances of the High School boys, Patience found no leisure
for vanity. Sometimes she paused long enough to wonder if she had
any individuality left; if environment was not stronger than heredity
after all; if immediate impressions could not ever efface those of the
past, no matter how deeply the latter may have been etched into the
plastic mind. But she was quite conscious that she was happy,
despite the vague restlessness and longings of youth. She loved Miss
Tremont with all the sudden expansion of a long repressed
temperament endowed with a tragic capacity for passionate
affection. In Monterey the iron mould of reserve into which
circumstance had forced her nature, had cramped and warped what
love she had felt for Mr. Foord and Rosita; but in this novel
atmosphere, where love enfolded her, where everybody respected
her, and knew nothing of her past, where there was not a word nor
an occurrence to remind her of the ugly experiences of her young
life, she quickly became a normal being, living, belatedly, along the
large and generous lines of her nature.
She had no friends of her own age with whom to discuss the
problems dear to the heart of developing woman. The girls at the
High School rarely talked during recess, and she left hurriedly the
moment the scholars were dismissed for the day. The “Y’s” she
persistently refused to join, as well as the young people’s societies of
Miss Tremont’s church.
“I’ll be your helper in everything,” she said to her perplexed
guardian; “but those girls bore me, and, you know, I really haven’t
time for them.”

And Miss Tremont, despite the fact that Patience gave no sign of
spiritual thaw, was the most doting of old maid parents. After the
first few weeks she ceased to dig in Patience’s soul for the stunted
seeds of Christianity, finding that she only irritated her, and trusting
to the daily sprinkling of habit and example to promote their ultimate
growth.

V
With summer came a cessation of school, Loyal Legion, and
sewing school duties; but the Poor took no vacation and gave none.
Nevertheless, Patience had far more leisure, and borrowed many
books from the town library. She read much of Hugo and Balzac and
Goethe, and in the new intellectual delight forgot herself more
completely than in her work.
Moreover, the town was very beautiful in summer, and she spent
many hours rambling along the shadowy streets whose venerable
trees shut the sunlight from the narrow side ways. The gardens too
were full of trees; and the town from a distance looked like a
densely wooded hillside, a riot of green, out of which housetops
showed like eggs in a nest. Over some of the steep old streets the
maples met, growing denser and denser down in the perspective,
until closed by the flash of water.
The woods on the slope of the Hudson were thick with great
trees dropping a leafy curtain before the brilliant river, and full of
isolated nooks where a girl could read and dream, unsuspected of
the chance pedestrian.
After one long drowsy afternoon by a brook in a hollow of the
woods, Patience returned home to find a carriage standing before
the door. It was a turnout of extreme elegance. The grey horses
were thoroughbreds; a coachman in livery sat on the box; a footman
stood on the sidewalk. She looked in wonder. Miss Tremont had no
time for the fine people of Mariaville, and they had ceased to call on
her long since. Moreover, Patience knew every carriage in the town,
and this was not of them.
She went rapidly into the house, youthfully eager for a new
experience. Miss Tremont was seated on the sofa in the front
parlour, holding the hand of a tall handsomely gowned woman.
Patience thought, as she stood for a moment unobserved, that she
had never seen so cold a face. It was the face of a woman of fifty,
oval and almost regular. The mouth was a straight line. The clear

pale eyes looked like the reflection of the blue atmosphere on icicles.
The skin was as smooth as a girl’s, the brown hair parted and
waved, the tall figure slender and superbly carried. She was smiling
and patting Miss Tremont’s hand, but there was little light in her
eyes.
As Patience entered, she turned her head and regarded her
without surprise; she had evidently heard of her. Miss Tremont’s face
illumined, and she held out her hand.
“This is Patience,” she said triumphantly. “I haven’t told you half
about the dear child. Patience, this is my cousin, Mrs. Gardiner
Peele.”
Mrs. Gardiner Peele bent her head patronisingly, and Patience
hated her violently.
“I am glad you have a companion,” said the lady, coldly. “But how
is it you haven’t the white ribbon on her?”
Miss Tremont blushed. “Oh, I can’t control Patience in all things,”
she said, in half angry deprecation. “She just won’t wear the ribbon.”
Mrs. Peele smiled upon Patience for the first time. It was a wintry
light, but it bespoke approval. “I wish she could make you take it
off,” she said to her relative. “That dreadful, dreadful badge. How
can you wear it?—you—”
“Now, cousin,” said Miss Tremont, laughing good-naturedly, “we
won’t go over all that again. You know I’m a hopeless crank. All I
can do is to pray for you.”
“Thank you. I don’t doubt I need it, although I attend church
quite as regularly as you could wish.”
“I know you are good,” said Miss Tremont, with enthusiasm, “and
of course I don’t expect everybody to be as interested in
Temperance as I am. But I do wish you loved the world less and the
Lord more.”
Mrs. Peele gave a low, well modulated laugh. “Now, Harriet, I
want you to be worldly for a few minutes. I have brought you back
two new gowns from Paris, and I want you, when you come to visit
me next week, to wear them. I have had them trimmed with white
ribbon bows so that no one will notice one more or less—”

“I’m not ashamed of my white ribbon,” flashed out Miss Tremont,
then relented. “You dear good Honora. Yes, I’ll wear them if they’re
not too fashionable.”
“Oh, I studied your style. And let me tell you, Harriet Tremont,
that fashionable gowns are what you should be wearing. It does
provoke me so to see you—”
But Miss Tremont leaned over and kissed her short. “Now what’s
the use of talking to an old crank like me? I’m a humble servant of
my dear Lord, and I couldn’t be anything else if I had a million. But
you dear thing, I’m so glad to see you once more. You do look so
well. Tell me all about the children.”
Patience, quite forgotten, listened to the conversation with deep
interest. There was a vague promise of variety in this new advent.
As she watched the woman, who seemed to have brought with her
something of the atmosphere of all that splendid existence of which
she had longingly read, she was stirred with a certain dissatisfaction:
some dormant chord was struck—as on the day she drove by Del
Monte. When Mrs. Peele arose to go, she thought that not Balzac
himself had ever looked upon a more elegant woman. Even
Patience’s untrained eye recognised that those long simple folds,
those so quiet textures, were of French woof and make. And the
woman’s carriage was like unto that of the fictional queen. She
nodded carelessly to Patience, and swept out. When Miss Tremont
returned after watching her guest drive away, Patience pounced
upon her.
“Who is she?” she demanded. “And why didn’t you tell me you
had such a swell for a cousin?”
“Did I never tell you?” asked Miss Tremont, wonderingly. “Why, I
was sure I had often talked of Honora. But I’m so busy I suppose I
forgot.”
She sat down and fanned herself, smiling. “Honora Tremont is my
first cousin. We used to be great friends until she married a rich man
and became so dreadfully fashionable. The Lord be praised, she has
always loved me; but she lives a great deal abroad, and spends her
winters, when she is here, in New York. They have a beautiful place
on the Hudson, Peele Manor, that has been in the family for nearly

three hundred years. Mr. Peele is an eminent lawyer. I don’t know
him very well. He doesn’t talk much; I suppose he has to talk so
much in Court. I’ve not seen the children for a year. I always thought
them pretty badly spoiled, particularly Beverly. May isn’t very bright.
But I always liked Hal—short for Harriet, after me—better than any
of them. She is about nineteen now. May is eighteen and Beverly
twenty-four.
“Then there is Honora, cousin Honora’s sister Mary’s child, and
the tallest woman I ever saw. Her parents died when she was a little
thing and left her without a dollar. Honora took her, and has treated
her like her own children. Sometimes I think she is very much under
her influence. I don’t know why, but I never liked her. She is
Beverly’s age. Oh!” she burst out, “just think! I have got to go to
Peele Manor for a week. I promised. I couldn’t help it. And oh, I do
dread it. They are all so different, and they don’t sympathise with
my work. Much as I love them I’m always glad to get away. Wasn’t it
kind and good of her to bring me two dresses from Paris?”
Patience shrewdly interpreted the prompting of Mrs. Peele’s
generosity, but made no comment.
Miss Tremont drew a great sigh: “My temperance work—my poor
—what will they do without me? Maria Twist gets so mad when I
don’t read the Bible to her twice a week. Patience, you will have to
stay in Temperance Hall. I shouldn’t like to think of you here alone. I
do wish Honora had asked you too—”
“I wouldn’t go for worlds. When do you think your dresses will
come? I do so want to see a real Paris dress.”
“She said they’d come to-morrow. Oh, to think of wearing stiff
tight things. Well, if they are uncomfortable or too stylish I just
won’t wear them, that’s all.”
“You just will, auntie dear. You’ll not look any less fine than those
people, or I’ll not go near Hog Heights.”
Miss Tremont kissed her, grateful for the fondness displayed.
“Well, well, we’ll see,” she said.
But the next day, when the two handsome black gowns lay on
the bed of the spare room, she shook her head with flashing eyes.

“I won’t wear those things,” she cried. “Why, they were made for
a society woman, not for an humble follower of the Lord. I should be
miserable in them.”
Patience, who had been hovering over the gowns,—one of silk
grenadine trimmed with long loops of black and white ribbon, the
other of satin with a soft knot of white ribbon on the shoulder and
another at the back of the high collar,—came forward and firmly
divested Miss Tremont of her alpaca. She lifted the heavy satin gown
with reverent hands and slipped it over Miss Tremont’s head, then
hooked it with deft fingers.
“There!” she exclaimed. “You look like a swell at last. Just what
you ought to look like.”
Miss Tremont glanced at the mirror with a brief spasm of youthful
vanity. The rich fashionable gown became her long slender figure,
her unconscious pride of carriage, far better than did her old alpaca
and merino frocks. But she shook her head immediately, her eyes
flashing under a quick frown.
“The idea of perching a white bow like a butterfly on my shoulder
and another at the back of my neck, as if I had a scar. It’s an insult
to the white ribbon. And this collar would choke me. I can’t breathe.
Take it off! Take it off!”
“Not until I have admired you some more. You look just grand. If
the collar is too high, I’ll send for Mrs. Best, and we’ll cut it off and
sew some soft black stuff in the neck—although I just hate to.
Auntie dear, don’t you think you could stand it?”
Miss Tremont shook her head with decision. “I couldn’t. It hurts
my old throat. And how could I ever bend my head to get at my
soup? And these bows make me feel actually cross. If the dress can
be made comfortable I’ll wear it, for I’ve no right to disgrace Honora,
nor would I hurt her feelings by scorning her gowns; but I’ll not
stand any such mockery as these flaunting white things.”
Patience exchanged the satin for the grenadine gown. This met
with more tolerance at first, as the throat was finished with soft
folds, and the white ribbon was less demonstrative.
“It floats so,” said Patience, ecstatically. “Oh, auntie, you are a
beauty.”

“I a beauty with my ugly scowling old face? But this thing is like a
ball dress, Patience—this thin stuff! I prefer the satin.”
“You will wear this on the hot evenings. All thin things are not
made for the ball-room. You needn’t look at yourself like that. I only
wish I’d ever be half as pretty. Auntie, why didn’t you ever marry?”
Miss Tremont’s face worked after all the years. Memories could
not die in so uniform a nature.
“My youth was very sad,” she said, turning away abruptly. “I only
talk about it with the dear Lord.” And Patience asked no more
questions.

VI
The dressmaker was sent for, and the satin gown divested of its
collar. Miss Tremont ruthlessly clipped off the beautiful French bows
and sewed a tiny one of narrow white ribbon in a conspicuous place
on the left chest. The grenadine was decorated in like manner.
Patience wailed, and then laughed as she thought of Mrs. Gardiner
Peele. She wished she might be there to see that lady’s face.
Miss Tremont changed her mind four times as to the possibility of
leaving Mariaville for a week of sinful idleness, before she was finally
assisted into the train by Patience’s firm hand. Even then she
abruptly left her seat and started for the door. But the train was
moving. Patience saw her resume her seat with an impatient twitch
of her shoulders.
“Poor auntie,” she thought, as she walked up the street; “but on
the whole I think I pity Mrs. Peele more.”
Her bag had been sent to Temperance Hall, and she went directly
there, and to her own room. As the day was very warm, she
exchanged her frock for a print wrapper, then extended herself on
the bed with “’93.” It was her duty to assuage the wrath of Maria
Twist, but she made up her mind that for twenty-four hours she
would shirk every duty on her calendar.
But she had failed to make allowance for the net of circumstance.
She had not turned ten pages when she heard the sound of agitated
footsteps in the hall. A moment later Mrs. Blair opened the door
unceremoniously. Her usually placid face was much perturbed.
“Oh, Miss Patience,” she said, “I’m in such a way. Late last night
a poor man fell at the door, and I took him in as there was no
policeman around. I thought he was only ill, but it seems he was
drunk. He’s been awake now for two hours, and is awful bad—not
drunk, but suffering.”
“Why don’t you send for the doctor?” asked Patience, lazily.
“I have, but he’s gone to New York and won’t be back till night.
The man says he can doctor himself—that all he wants is whisky;

but of course I can’t give him that. Do come over and talk to him.
Miss Beale is over at White Plains, and I don’t know what to do.”
Patience rose reluctantly and followed the matron to the side of
the house reserved for men. As she went down the hall she heard
groans and sharp spasmodic cries. Mrs. Blair opened a door, and
Patience saw an elderly man lying in the bed. His grey hair and
beard were ragged, his eyes dim and bleared, his long, well-cut but
ignoble face was greenishly pale. He was very weak, and lay
clutching at the bed clothes with limp hairy hands. As he saw the
matron his eyes lit up with resentment.
“I didn’t come here to be murdered,” he ejaculated. “It’s the last
place I’d have come to if I’d known what I was doing. But I tell you
that if I don’t have a drink of whisky I’ll be a dead man in an hour.”
“I can’t give you that,” said Mrs. Blair, desperately. “And you
know you only think you need it, anyhow. We try to make men
overcome their terrible weakness; we don’t encourage them.”
“That’s all right, but you can’t reform a man when his inside is on
fire and feels as if it were dropping out—but my God! I can’t argue
with you, damn you. Give it to me.”
“I’m of the opinion that he ought to have it,” said Patience.
The man turned to her eagerly. “Bless you,” he said. “It’s not the
taste of it I’m craving, miss; it’s relief from this awful agony. If you
give it to me, I swear I’ll try never to touch a drop again after I get
over this spree. It’ll be bad enough to break off then, but it’s death
now.”
Mrs. Blair looked at him with pity, but shook her head.
“I’ve been here seven years,” she said to Patience, “and the
ladies have yet to find one fault with me. I don’t dare give it to him.
Besides, I don’t believe in it. How can what’s killing him cure him?
And it’s a sin. Even if the ladies excused me—which they wouldn’t—
I’d never forgive myself.”
“I’ll take the responsibility,” said Patience. “I believe that man will
die if he doesn’t have whisky.”
The man groaned and tossed his arms. “Oh, my God!” he cried.
Mrs. Blair shuddered. “Oh, I don’t know, miss. If you will take the
responsibility—I can’t give it to him—where could you get it?”

“At a drug store.”
“They won’t sell it to you—we’ve got a law passed, you know.”
“Then I’ll go to a saloon.”
“Oh, my! my!” cried Mrs. Blair, “you’d never do that?”
“The man is in agony. Can’t you see? I’m going this minute.”
The door opened, and Miss Beale entered. She looked warm and
tired, but came forward with active step, and stood beside the bed.
A spasm of disgust crossed her face. “What is the matter, my man?”
she asked. “I am sorry to see you here.”
“Give me whisky,” groaned the man.
Miss Beale turned away with twitching mouth.
“The man is dying. Nothing but whisky can save him,” said
Patience. “If you called a doctor he would tell you the same thing.”
“What?” said Miss Beale, coldly, “do you suppose that he can
have whisky in Temperance Hall? Is that what we are here for? You
must be crazy.”
“But you don’t want him to die on your hands, do you?”
exclaimed Patience, who was losing her temper.
“My God!” screeched the man, “I am in Hell.”
“My good man,” said Miss Beale, gently, “it is for us to save you
from Hell, not to send you there.”
“I’ll be there in ten minutes.” His voice died to an inarticulate
murmur; but he writhed, and doubled, and twisted, as men may
have done when fanatics tortured in the name of religion.
“Good heavens, Miss Beale,” cried Patience, excitedly, “you can’t
set yourself up in opposition to nature. That man must have whisky.
If he were younger and stronger it wouldn’t matter so much; but
can’t you see he hasn’t strength to resist the terrible strain? The
torture is killing him, eating out his life—”
“Oh, it is terrible!” exclaimed the matron. “Perhaps it is best—”
“Mrs. Blair!” Miss Beale turned upon her in consternation. Then
she bent over the man.
“You can’t have whisky,” she said gently; “not if I thought you
were really dying would I give it to you. If it is the Lord’s will that
you are to die here you must abide by it. I shall not permit you to
further imperil your soul. Nor could that which has not the blessing

of God on it be of benefit to you. Alcohol is a destroyer, both of soul
and of body—not a medicine.”
The man’s knees suddenly shot up to his chest; but he raised his
head and darted at her a glance of implacable hate.
“Damn you,” he stuttered. “Murderer—” Then he extended rigid
arms and clutched the bed clothes, his body twitching uncontrollably.
Miss Beale looked upon him with deep compassion. “Poor thing,”
she exclaimed, “is not this enough to warn all men from that fiend?”
She laid her hand on the man’s head, but he shook it off with an
oath.
“Whisky,” he cried. “O my God! Have these women—women!—no
pity?”
“I’m going for whisky—” said Patience.
Miss Beale stepped swiftly to the door, locked it, and slipped the
key into her pocket.
“You will buy no whisky,” she said sternly. “I will save you from
that sin.” Suddenly her face lit up. “I will pray,” she said solemnly, “I
will pray that this poor lost creature may recover, and lead a better
life—”
“I swear I’ll never touch another drop after I’m out of this if you’ll
give it to me now—”
“If it be the Lord’s will that you shall live you will not die,” said
Miss Beale. “I will pray, and in His mercy He may let you live to
repent.”
She fell upon her knees by the bed, and clasping her hands,
prayed aloud; while the man reared and plunged and groaned and
cursed, his voice and body momentarily weaker. Miss Beale’s prayers
were always very long and very fervid. She was not eloquent, but
her deep tear-voiced earnestness was most impressive; and never
more so than to-day, when she flung herself before the throne of
Grace with a lost soul in her hand. A light like a halo played upon her
spiritualised face, her voice became ineffably sweet. Gradually, in her
ecstatic communion with, her intimate nearness to her God, she
forgot the man on the bed, forgot the flesh which prisoned her
soaring soul, was conscious only of the divine light pouring through
her, the almost palpable touch of her lover’s hand.

Suddenly Patience exclaimed brutally: “The man is dead.”
Miss Beale arose with a start. She drew the sheet gently over the
distorted face. “It is the Lord’s will,” she said.
After Patience was in her own room and had relieved her feelings
by slamming the door, she sat for a long time staring at the pattern
of the carpet and pondering upon the problem of Miss Beale.
“Well,” she thought finally, “she’s happy, so I suppose it’s all right.
No wonder she’s satisfied with herself when she lives up to her
ideals as consistently as that. I think I’ll label all the different forms
of selfishness I come across. There seems to be a large variety, but
all put together don’t seem to be a patch to having fun with your
ideals. Miss Beale would be the most wretched woman in
Westchester county if she’d given that man whisky and saved his
life.”

Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade
Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.
Let us accompany you on the journey of exploring knowledge and
personal growth!
ebookultra.com

Learning CoreDNS Configuring DNS for Cloud Native Environments 1st Edition John Belamaric

More Related Content

Similar to Learning CoreDNS Configuring DNS for Cloud Native Environments 1st Edition John Belamaric (20)

Recently uploaded (20)

Learning CoreDNS Configuring DNS for Cloud Native Environments 1st Edition John Belamaric