A light hearted joke:
Welcome to Infrastructure series 9. BINDer of slaves. First of its length. Breaker of CAs. Mother of all WIKIS
Shout Outs
Thanks @oO.o for the direction you gave
Thanks @SgtAwesomesauce for being completely surprised I went through with it. #ChallengeAccepted
Thanks @Novasty for SElinux fixes not included here… LOL sorry guys
README FIRST: The importance of understanding
Doing and understanding are two entirely different actions. Full stop
Let that sink in…
…
Okay, now that you have thought about it, why am I priming you with this statement? I could say that in this post, we will be slaying a firestorm of dragons in a subzero hell, and that would be a reasonably accurate summation. However, those who have a robust foundational sense of why we are doing what we are about to embark on will work more effectively towards the goal and be more efficient in plans, tangential or not.
Mind Set Conditioning:
This post will not take a technician’s approach (though you could use it as such) in explaining and performing today’s procedures. I ask you to put yourself into an engineering mindset. The engineer’s way of designing a system is to break it all the way down to its tiniest piece parts. Understand how it fits together. Could you put it back together? Design the system around the understood master-concept. Everything has a label. Everything has a purpose; if it does not, design it out. When people say, engineers create magic ( a term I often hear). It is not magic. It just works because the caretaker or architect of the system took sufficient time to understand what they were doing. That is the “Why” of stepping through how it works.
So let us start from the absolute beginning
A history of the internet
The Internet began way back when as ARPAnet. The vision, the “why” of its creation, was that historically, voice and data communications were based on methods of circuit switching, like the traditional telephone network, wherein each telephone call is allocated a dedicated, end to end, electronic connection between the two communicating stations. The link is established by switching systems that connect multiple intermediate call legs between these systems for the call duration. The ARPAnet took a lot of its inspiration from this, and as such, its design is a lot like it, with the addition of automation. The actual need for ARPAnet came out of frustration of not having access to a minimal number of supercomputers in the world. There was a way around this; ARPAnet was the first concept of “distributed computing,” Thus, a need was born a solution. The network grew from a handful of hosts to tens of thousands of hosts. The original ARPAnet became the backbone of a confederation of local and regional networks based on TCP/IP, called the Internet.
Today, the Internet connects millions of hosts around the world. A significant proportion of the non-PC computers in the world are connected to the Internet, and some commercial backbones carry a volume of several terabits per second (aggregate), tens of millions of times the bandwidth of the original ARPAnet. 100s of millions of people use the network for communication and collaboration daily.
But how did you find your way?
History of DNS
ARPAnet was small, and therefore, all that was needed was a single file, hosts.txt, which contained a name-to-address mapping for every host connected to the ARPAnet. The familiar Unix host table, /etc/hosts, was compiled from HOSTS.TXT (primarily by deleting fields Unix didn’t use). Believe it or not, that hosts file dates before most of your birth years, including my birth year. Remember this. It is important later because DNS retains a UNIX structure.
There were many issues with this, as you can imagine, and as the network grew, you can imagine that the burden on the network information centers systems was becoming unbearable in terms of the network traffic and processor load involved in distributing the file. Worse yet, No two hosts in the host file could have the same name. While the NIC could assign addresses in a way that guaranteed uniqueness, it had no authority over hostnames themselves. Nothing was to prevent a user from adding a host with a conflicting name and breaking the whole scheme. Adding a host with the same name as a significant mail hub, for example, could disrupt mail service to much of the ARPAnet. This did happen numerous times. The many mess-ups cleanups all lead to a highly inconsistent file. So a solution was required, and that solution was a distributed database of name resolutions. There is the why. The how would be a quasi decentralized (it is still centralized in some manner today) autonomous system that eliminated the single host bottled neck. Thus, allowing people to write and modify stuff they had under their authority. The DNS or Domain Name System was born from this.
Introduction to DNS Structure
The Domain Name System is a distributed centralized database with a structure that permits localized control of the segments of the overall database. The data in each element is available across the entire network through a client/server scheme. Robustness and adequate performance are achieved through replication and caching. Stepping through and finding the records from each authority is achieved through recursion. It is a tree system with the root servers defining all the TLDs (as the root authority) that exist on the internet (prior ARPAnet) system. The tree structure of DNS is nearly identical to the UNIX file system. The root node is on top (similar to a root directory), and it spans down into its deepest folder-file piece parts.
Now look at DNS:
The internet DNS system is a tree with power shared. The root tells everyone what TLDs can exist, and the TLDs point down to the local servers the authority is derived from. As seen above, the records you eventually set control the tree within your authority zone. Every domain has a unique name, like every directory. Understanding this similarity helps to debug and helps pull it all together in the head visually. A domain’s name identifies its position in the database, much as a directory’s absolute pathname specifies its place in the filesystem. In DNS, the domain name is the sequence of labels from the base node to the root of the domain to the source of the whole tree with dots (.) separating the labels often denoted by canonical names if pointing at the same server.
The zoning authority autonomously manages each authority zone. The root authority points downwards in recursion. Every DNS server eventually queries the root in its search for where somebody’s address is. The delegation allows the localization of control of those pages. It’s like a manager breaking up the project into smaller tasks that each person can do.
Each delegation area is called a “zone.” Here are some drawings from Oreilly’s DNS and BIND 5th edition. They are reasonably good at illustrating the point of a zone, and it will help you understand what we are placing in the configuration later!
And so forth. If a subdomain is on another system in your network but has an entire set of DNS records itself, you can place another authority server down in its records and create an authority server that digs down in for the subdomain. This method is called subdomain delegation. You probably will not need it for a home lab.
I think this forms the basis of your understanding, and we could talk for days about implementations and the eventual creation of the BSD-based BIND. That would take far too long. Feel free to dive into it yourself, however.
Types of Name Servers
Hopefully, understanding the types of servers helps you know where the DNS journey takes place and where it finishes.
Root Server
There are 13 root servers in the world: (Date of table is 202111140452MST)
| HOSTNAME | IP ADDRESSES | OPERATOR |
|---|---|---|
| a.root-servers.net | 198.41.0.4, 2001:503:ba3e::2:30 | Verisign, Inc. |
| b.root-servers.net | 199.9.14.201, 2001:500:200::b | Information Sciences Institute |
| c.root-servers.net | 192.33.4.12, 2001:500:2::c | Cogent Communications |
| d.root-servers.net | 199.7.91.13, 2001:500:2d::d | University of Maryland |
| e.root-servers.net | 192.203.230.10, 2001:500:a8::e | NASA (Ames Research Center) |
| f.root-servers.net | 192.5.5.241, 2001:500:2f::f | Internet Systems Consortium, Inc. |
| g.root-servers.net | 192.112.36.4, 2001:500:12::d0d | US Department of Defense (NIC) |
| h.root-servers.net | 198.97.190.53, 2001:500:1::53 | US Army (Research Lab) |
| i.root-servers.net | 192.36.148.17, 2001:7fe::53 | Netnod |
| j.root-servers.net | 192.58.128.30, 2001:503:c27::2:30 | Verisign, Inc. |
| k.root-servers.net | 193.0.14.129, 2001:7fd::1 | RIPE NCC |
| l.root-servers.net | 199.7.83.42, 2001:500:9f::42 | ICANN |
| m.root-servers.net | 202.12.27.33, 2001:dc3::35 | WIDE Project |
There is another system called OpenNIC, and they have their root servers. A root server accepts a recursive resolver’s query, which includes a domain name, and the root nameserver responds by directing the recursive resolver to a TLD nameserver, based on the extension of that domain (.mil, .net, .org, etc.). The root nameservers are overseen by a nonprofit called the ICANN.
Top Level Domain Server
A TLD nameserver maintains information for all the domain names that share a standard domain extension, such as .com, .net, or whatever comes after the last dot in a URL to which there are two subtypes.
- Country code top-level domains: These include any domains specific to a country or state. Examples include .uk, .us, .ru, and .jp.
- Generic top-level domains: These are domains that are not country-specific, some of the best-known generic TLDs include .com, .org, .net, .edu, and .gov.
Authoritative Server
The authoritative nameserver contains information specific to its domain name, like duckduckgo.com. It can provide a recursive resolver with the IP address of that server found in the DNS AAAA record, or if the domain has a CNAME (CANONICAL NAME) record or alias (which is also a record type), it will provide the recursive resolver with an alias domain. At that point, the recursive resolver will have to perform a whole new DNS lookup to procure a record from an authoritative nameserver.
Recursive or Stub Resolver
A recursive resolver is your first stop in a DNS query. The recursive resolver acts as a broker between a client and a nameserver. After receiving a DNS query from a client, a recursive resolver will respond with cached data (highly likely) or send a request to a root nameserver. The root name server will respond with the TLD servers, and thus it will be followed by another request to a TLD nameserver. The TLD will tell you the next step down in the authority chain, where you will recurse through authoritative servers until that one last request to THE authoritative nameserver for where you are going. After receiving a response from the authoritative nameserver containing the requested IP address, the recursive resolver then responds to the client. So like Quad9 is for most people or Cloudflare.
What is Bind?
BIND, aka Berkeley Internet Name Domain System, is the implementation you will find to be standard and synonymous with most people’s DNS backbone. There are other systems; however, it is the one we will focus on today.
Bind can be each of the types of resolvers I have mentioned earlier. Strictly speaking, we keep roles separate. We want to avoid any authority server from being an “Open Resolver” as that is the job of a recursive resolver, and it limits our attach surface from an amplification attack.
Today we are setting up iterative but not recursive servers. I highly suggest unbound for recursion as it is much easier to configure for most folks. Authoritative-only DNS servers are often a suitable configuration for high performance because they do not have the overhead of resolving recursive queries from clients. They only care about the zones that they are designed to serve.
There is a reverse DNS process where we take addresses and map them to domain names; however, that requires wrapping up this enchilada, and I think I will save it for a post update. You may see this in the table of contents later.
What will I need?
You will need a Master Server and a Slave Server. I will achieve this by having two Linodes spun up in the Freemont data center. I don’t care how you achieve two separate systems; that is something I leave up to you. One will be for the “primary” DNS server where the zone files for our domain will originate, and one will be the “secondary” server which will receive the zone data through transfers and be available if the other server goes down. This avoids the problem of having a single point of failure for your DNS servers.
System Specs: (Both systems are identical)
❯ neofetch
__wgliliiligw_, eric@ns1
_williiiiiiliilililw, --------
_%iiiiiilililiiiiiiiiiii_ OS: Rocky Linux 8.4 (Green Obsidian) x86_64
.Qliiiililiiiiiiililililiilm. Host: KVM/QEMU (Standard PC (Q35 + ICH9, 2009) pc-q35-4.1)
_iiiiiliiiiiililiiiiiiiiiiliil, Kernel: 4.18.0-305.25.1.el8_4.x86_64
.lililiiilililiiiilililililiiiii, Uptime: 13 hours, 56 mins
_liiiiiiliiiiiiiliiiiiF{iiiiiilili, Packages: 783 (rpm)
jliililiiilililiiili@` ~ililiiiiiL Shell: zsh 5.5.1
iiiliiiiliiiiiiili>` ~liililii Resolution: 1024x768
liliiiliiilililii` -9liiiil Terminal: /dev/pts/0
iiiiiliiliiiiii~ "4lili CPU: AMD EPYC 7601 (2) @ 2.199GHz
4ililiiiiilil~| -w, )4lf GPU: Vendor 1234 Device 1111
-liiiiililiF' _liig, )' Memory: 302MiB / 1809MiB
)iiiliii@` _QIililig,
)iiii>` .Qliliiiililw
)<>~ .mliiiiiliiiiiil,
_gllilililiililii~
giliiiiiiiiiiiiT`
-^~$ililili@~~'
~ ❯
I leave the task of hardening and securing your server again to you. You know your needs and use case better than I do. I, however, recommend you figure out the best practices for your scenario and employ them as a minimum.
Additional Note: I AM WORKING WITH BIND v 9.16 ESV
Instructions for RHEL 8 can be found here: isc/bind Copr
sudo dnf update
sudo dnf install bind bind-utils
I will not provide support for DNSSEC related questions on earlier versions. For that, you will need to seek out the version documentation and other guides. I am sorry. There are too many ways to skin this cat.
Install Bind 9.16 on both servers
Hostname setup for Master/Slave
So my structure is simple:
| Function | DNS FQDN | IP Address |
|---|---|---|
| Master Name Server | ns1.< MY-TLD >.net | 23.239.20.9, 2600:3c01::f03c:92ff:fece:5fc0 |
| Slave Name Server | ns2.< MY-TLD >.net | 173.255.255.89, 2600:3c01::f03c:92ff:fe9e:3ef0 |
| Recursive Resolver | < MY-TLD >.net (DNS/DoT), dns.< MY-TLD >.net (DoH) | 192.53.120.164, 2600:3c04::f03c:92ff:fec6:2030 |
| Web Server | < MY-TLD >.net, *.< MY-TLD >.net | 192.53.120.164, 2600:3c04::f03c:92ff:fec6:2030 |
So lets setup the nameservers so they know where themselves and each other are at.
sudo nvim /etc/hosts
You want the file to look like or similar to
127.0.0.1 localhost
{Master IP} ns1.{FQDN} ns1
Now
sudo nvim /etc/hostname
and place ns1 as the host name.
Reload the hostname:
sudo hostname -F /etc/hostname
Now complete the same procedure on our secondary server, adapting it for NS2 values.
This will complete the host definitions setup.
Setting up the Master Authority Server
Let us begin with the master server, as it will have our zone file, and the slave relies on it. It is slave in every sense of the word.
We first want to edit our named.conf. For most, this will be in /etc. However for us COPR folks we will find it in /etc/opt/isc/scls/isc-bind/named.conf on RHEL 8
When editing this, find the OPTIONS part of the config and make it look similar. Paying attention to the lines I point out below is identical.
Options Section
options {
directory "/var/opt/isc/scls/isc-bind/named/data";
//listen-on { ANY; };
//listen-on-v6 { ANY; };
allow-transfer { none; }; <<----
allow-query { localhost; }; <<----
recursion no; <<----
auth-nxdomain no; # RFC-1035 Compliance <<----
dnssec-validation yes; <<----
};
As you can see, we do not want recursion. We want the use of DNSSEC validation, and we want RFC 1035 Compliance. We will set this on a per-zone basis. We do not want anybody to transfer all our zones, so we have that set to none.
In the next section, we will configure the local zone. The zone we will configure is the one we are the authority over.
Defining the Zone
My zone definition looks like this:
// < MY-TLD > Auth Zones
zone "< MY-TLD >.net" in {
type master;
file "/var/opt/isc/scls/isc-bind/named/< MY-TLD >.net";
allow-query { any; };
allow-transfer { 173.255.255.89; }; <<---- IP of SLAVE
dnssec-policy high;
inline-signing yes;
};
We want it to be the master for this. We will allow any query, and the only permitted transfer is to our Slave server. Until later, please ignore the DNSSEC Policy and Inline-signing values. These are related to DNSSEC, and I promise you I will walk you through setting up a policy and getting this setup with full DNSSEC resolution later.
Making the Zone File
Lets go ahead and make that zone file shall we?
sudo nvim /var/opt/isc/scls/isc-bind/named/< MY-TLD >.net
In this file, we want to begin with a default TTL value and an ORIGIN value that will contain our TLD and thus designates the beginning of the ZONE. Once complete, the VERY first thing you need to do is configure a Start of Authority or SOA.
Here is an excellent template to which you may OMIT the 600 TTL as we have defined the default TTL as 5 minutes. This is in BIND format.
You can grab the basic version in the /var/$PATH of your bind setup and copy it to your directory. Thus you can begin with a similar template to below.
sudo cp /var/named/named.empty /var/named/example.com
Now lets get to writing
Breaking down the SOA
example.com. 600 IN SOA ns1.example.com. admin.example.com. (
2014112007 ; serial
1800 ; refresh (30 minutes)
900 ; retry (15 minutes)
2419200 ; expire (4 weeks)
300 ; minimum (5 minutes)
)
Host Label
It defines the hostname of a record and whether the hostname will be appended to the label. Fully qualified hostnames terminated by a period will not append the origin.
TTL
The time-to-live in seconds. It specifies how long a resolver is supposed to cache the entry.
Record Class
Defines the class type. In this case IN
Record Type
The record format is defined using this field which in this case is SOA or Start Of Authority
Master Name
The host name for the primary DNS server for the zone.
Responsible Name
The email address of the person that is responsible for administering the domain’s zone file. The ‘@’ in the email address is replaced by a dot ‘.’. So administrator.example.com. You may use any variety your parent accepts. Namecheap accepts Hostmaster Admin and a few others.
Serial Number
Serial number for this zone is a timestamp that changes whenever something changes in the zone. If a secondary name server slaved to this master zone observes an increase in this number, the slave will assume that the zone has been updated and initiate a zone transfer. THIS IS IMPORTANT make sure your INCREMENT everytime there is a change.
Refresh Interval
The time in seconds that a secondary DNS server waits before querying the primary DNS server’s SOA record to check for changes.
Retry Interval
The number of seconds before a failed refresh should be retried.
Expire Interval
The time in seconds before a zone is considered no longer authoritative. If this time expires before a successful zone transfer, the secondary server will expire its zone file. The secondary will stop answering queries, as it considers its data too old to be reliable.
Negative Caching TTL
The negative result TTL. For example, if a DNS resolver does a DNS query on a subdomain and gets a negative result. The negative caching TTL tells the resolver how long to wait before retrying the query.
Establishing the common records
In the A and AAAA and NS Sections we will define the Nameservers of this zone and the A (IPv4 Address) records and AAAA (IPv6) Address records. If you need an explanation of any record type please use the table of contents to go to "Records Type Overview"
Canonical Names, CAAs and TXT
In the following sections we will be proactive and define our CAA, CNames and TXT records ahead of time so they are set before we move onto other record types. If you need an explanation of any record type please use the table of contents to go to "Records Type Overview"
If you are setting up MX records and need a DKIM record, it will be a TXT record placed in the TXT section. Please refer to the documentation on setting this up from whatever tutorial you used to setup your records for this. It should be self explanatory.
Your zone file should start to look more complete now:
I am intentionally making you seek out the information in record types so you learn what you need to write in
The next thing you are going to do is make sure that named owns the files its needs to reference. Ideally it should
sudo chown named /var/$PATH/named/example.com
sudo chown named /etc/$PATH/named.conf
Then run the following command to check if there are syntax errors in the main configuration file. A silent output indicates no errors are found.
sudo named-checkconf
Then check the syntax of zone files.
sudo named-checkzone example.com /var/$PATH/named/example.com
If there are syntax errors in the zone file, you need to fix it, or this zone won’t be loaded. The following message indicates there are no syntax errors.
zone example.com/IN: loaded serial $SERIAL
OK
Then enable and restart the named Service. which could be isc-bind-named if you are me
sudo systemctl restart named
Reason I am not covering Reverse Zones
If the organization that gave you your IP addresses did not provide you a network range and delegate responsibility for that range to you, then your reverse zone file will not be referenced and handled by the organization itself since this is my case. While I could write one, it would be useless to me to save maybe a mail server I am not running.
Setting up the Slave Authority Server
Given the file paths you had on the primary server. We are going to be editing the same named.conf. We will NOT have a zone file on the slave as it will read from its master.
First, edit the named.conf file.
sudo nvim $PATH/named.conf
The OPTIONS section will be identical
Add the following line at the end of this file. This will add a slave zone. Replace 12.34.56.78 with the IP address of the master DNS server.
// < MY-TLD > Auth Zones
zone "< MY-TLD >.net" {
type slave;
file "/var/opt/isc/scls/isc-bind/named/< MY-TLD >.net";
allow-query { any; };
masters { 23.239.20.9; }; <<---- Master Server IP
};
Now following the same procedure as the primary … Save and close the file. Then run the following command to check if syntax errors in the main configuration file.
sudo named-checkconf
If there are no errors are found, restart and enable BIND.
sudo systemctl restart named
The zone file on the slave DNS server is loaded from a zone transfer, which is used to synchronize DNS record changes from the master DNS server to the slave DNS server. To verify the transfer occurred look for the transfer completion and the proper serial number increment in the journal
sudo journalctl -eu named
If its there then all has gone well. If its not you need to step through the output of systemctl status and the logs to figure out what you did wrong. I cant possibly cover every error so happy hunting.
Glueing it all together
So now we need our provider to know where the heck our DNS authority servers are and delegate as such. Mine is namecheap. Namecheap is running the TLD DNS Server so it will want to point to our servers as an authority on our domain.
So remember our structure:
| Function | DNS FQDN | IP Address |
|---|---|---|
| Master Name Server | ns1.< MY-TLD >.net | 23.239.20.9, 2600:3c01::f03c:92ff:fece:5fc0 |
| Slave Name Server | ns2.< MY-TLD >.net | 173.255.255.89, 2600:3c01::f03c:92ff:fe9e:3ef0 |
| Recursive Resolver | < MY-TLD >.net (DNS/DoT), dns.< MY-TLD >.net (DoH) | 192.53.120.164, 2600:3c04::f03c:92ff:fec6:2030 |
| Web Server | < MY-TLD >.net, *.< MY-TLD >.net | 192.53.120.164, 2600:3c04::f03c:92ff:fec6:2030 |
Please do whatever your providers guide says. If you use Namecheap one can find their custom DNS settings here.
They trully provide a nice layout and easy to follow guide. They are a great service. I highly recommend them.
Once you have those NS records set like I do below
It should not take very long to start seeing your NS records. However depending on the domain registrar you use, your NS record might be propagated instantly, or it might take up to 24 hours to propagate. You can go to https://dnsmap.io to check if your new NS record is active. Hopefully its fairly quick and you can move on from this step. Give it AT LEAST 5-10 Minutes.
Restart Resilience
Adding a SystemD auto restart
If for any reason your Named process is killed, you need to run the following command to restart it.
sudo systemctl restart isc-bind-named
Instead of manually typing this command, we can make BIND9 automatically restart by editing the named.service systemd service unit. To override the default systemd service configuration, we create a separate directory with the NAME of the service file and a dot D at the end.
sudo mkdir -p /etc/systemd/system/isc-bind9-named.service.d/
Then create a file under this directory.
sudo nvim /etc/systemd/system/isc-bind9-named.service.d/restart.conf
Add the following service overrides
[Service]
Restart=always
RestartSec=5s
Save and reload systemd.
sudo systemctl daemon-reload
To check if this would work, kill BIND9 with:
sudo pkill isc-bind-named
Then check Named status. You will find Named automatically restarted.
systemctl status isc-bind-named
Do this on both servers
Caution that this will create a restart loop if you mess up the configs
Setting up DNSSEC (Here there be dragons)
So my expression after spending 4.5 hrs figuring out the automation (and also figuring out I needed version 9.16) had me just about:
So lets keep it simple. You are on 9.16 and the world is a beautiful place without dragons the author of this guide has lets just say…
… burned them all… When I have addressed my PTSD with SELinux contexts and generating keys manually (like I did the first time) I might be willing to discuss what happened in that 4.5 HRS.
Let’s begin with writing a DNSSEC Policy. We will define this as “high” and fill in all the values we want Bind 9 to follow when automating DNSSEC for us. I have chosen to do this after we fill out the zone section with the exclusion of TLSA and SSHFP
Writing the DNSSEC Policy:
dnssec-policy high {
dnskey-ttl 600;
keys {
ksk lifetime 365d algorithm ecdsap384sha384;
zsk lifetime 60d algorithm ecdsap384sha384;
};
max-zone-ttl 600;
parent-ds-ttl 600;
parent-propagation-delay 2h;
publish-safety 7d;
retire-safety 7d;
signatures-refresh 5d;
signatures-validity 15d;
signatures-validity-dnskey 15d;
zone-propagation-delay 2h;
};
This is loosely based on a template. If someone would like me to explain these, I can, but the important part is that you use a supported key algorithm (the one above is the most supported), and you define those values with a sane value.
Seeing as they explain it in their docs: RTFM
https://bind9.readthedocs.io/en/latest/dnssec-guide.html#creating-a-custom-dnssec-policy
Add these to the zone definition in named.conf
dnssec-policy high;
inline-signing yes;
Execute the following command to reload and sign the zone files per your policy you have just written
rndc reload && rndc sign $FQDN && systemctl restart named
It is that simple to get all the keys loaded. Once you have done this in the zone file’s directory or in its $PATH/data you will find the key files of the KSK and the ZSK. Key Signing Keys and Zone Signing Keys. You should find them in a similar format to below:
KSK:
KFQDN.com.+014+10376.private
KFQDN.com.+014+10376.key
KFQDN.com.+014+10376.state
ZSK
Kexample.com.+014+53378.private
Kexample.com.+014+53378.key
Kexample.com.+014+53378.state
You need to know the locations of the *.key files for the next step which is delegation signer records
You need to do the following everytime you edit the zone:
DONT forget to increment the serial number and to
rndc reload && rndc sign $FQDN && systemctl restart named
You will need to do this EVERYTIME!!!
Parent Zone hand off of Delegation Signer Records (Name Cheap)
So since im using name cheap they make this once again very easy. I run the following two commands to get the SHA256 hash of my key files. Dont worry that I am sharing this. You cant make the hash match a different key 
dnssec-dsfromkey $ZSK.key
dnssec-dsfromkey $KSK.key
Then place in the DNSSEC section of your provider. That is what mine looks like on namecheap. I am assuming this part is not too difficult to figure out/translate but feel free to ask if you get confused.
Once you save those you will have proper DNSSEC resolution
Which you can always verify at verisign labs.
Your DNSSEC Key validation is complete. Congrats. There are some more obscure records I talk about below but you can safely stop here if you dont need those. I do recommend having the records below however. I also provide a Records type overview of every record there is
Records Type Overview (Source WIKIPEDIA)
This is an ultra condensed version of the following wikipedia page
To find specific syntax references please use that page and your favorite search engine. All this aims to do is familiarize you with each field in the record. It is up to you to do the research you ened to in order to enter it properly!
A Record
An A record maps hostnames to an IPv4 address.
FORMAT:
Host Label
The host label defines the hostname of a record and whether the hostname will be appended to the label. Fully qualified hostnames terminated by a period will not append the origin.
TTL
The time-to-live in seconds. This is the amount of time the record is allowed to be cached by an outside DNS server.
Record Class
For all intents and purposes you will use IN (Internet) which default and generally what internet uses. There are technically 3.
Record Type
The record format is defined using this field.
Record Data
The data within a DNS answer.
AAAA Record
An A record maps hostnames to an IPv6 address.
FORMAT:
Host Label
The host label defines the hostname of a record and whether the hostname will be appended to the label. Fully qualified hostnames terminated by a period will not append the origin.
TTL
The time-to-live in seconds. This is the amount of time the record is allowed to be cached by an outside DNS server.
Record Class
For all intents and purposes you will use IN (Internet) which default and generally what internet uses. There are technically 3.
Record Type
The record format is defined using this field.
Record Data
The data within a DNS answer.
CAA Record
A CAA record lets you specify which certificate authorities (CAs) are allowed to issue certificates for a domain or subdomain. Creating a CAA record helps to prevent the wrong CAs from issuing certificates for your domains.
FORMAT:
Host Label
It defines the hostname of a record and whether the hostname will be appended to the label. Fully qualified hostnames terminated by a period will not append the origin.
TTL
The time-to-live in seconds. This is the amount of time the record is allowed to be cached by an outside DNS server.
*Record Class
For all intents and purposes you will use IN (Internet) which default and generally what internet uses. There are technically 3.
Record Type
The record format is defined using this field.
Flag
Flags have only two strictly defined states currently: 0 (non-critical and default) and 1 (critical). Issuer Critical flag tells the CA that it must completely understand the property tag to proceed and RFC 6844 leaves other possibilities open for user-defined flag use.
Tag
3 tags are currently defined in the RFC:
- issue: authorizes a single certificate authority to issue certificates for the domain in which the property is published.
- issuewild: authorizes a single certificate authority to issue wildcard certificates for the domain in which the property is published.
- iodef: specifies a URL to which an issuer may report certificate issue requests that are inconsistent with the issuer’s Certification Practices or Certificate Policy.
Value
The field contains strings associated with tags. For the issue and issuewild tags, the value is typically the domain name of the CA authorized by the record, for example, comodoca.com. For iodef tag, you’ll supply a URL where policy violations should be reported. At least this is my experience since namecheap uses comodo
CNAME Record
A Canonical Name record (CNAME record) maps an alias name to a true or canonical domain name. CNAME is often used to associate new subdomains with an existing domain’s DNS records.
FORMAT:
Host Label
It defines the hostname of a record and whether the hostname will be appended to the label. Fully qualified hostnames terminated by a period will not append the origin.
TTL
The time-to-live in seconds. This is the amount of time the record is allowed to be cached by an outside DNS server.
Record Class
For all intents and purposes you will use IN (Internet) which default and generally what internet uses. There are technically 3.
Record Type
The record format is defined using this field.
Canonical Name
Canonical name or true name. This parameter should be a Fully Qualified Domain Name (FQDN), never an IP address.
CNAME record restrictions
Alias vs. Canonical Name
In the example above, we pointed a name store.ltt.com to lttstore.com . store.ltt.com is the alias. The canonical (true) name is lttstore.com . Because CNAME stands for Canonical Name, the right-hand side is the actual “CNAME”.
A root domain cannot have a CNAME record
A root domain name like example.com cannot have a CNAME record. RFC 1912 and RFC 2181 set out that SOA and NS records are mandatory to be present at the root domain; CNAME records can only exist as single records and can not be combined with any other resource record (DNSSEC SIG, NXT, and KEY RR records excepted).
CNAME alias cannot have other resource records
An alias defined in a CNAME record must have no other resource records of other types (MX, A, etc.). (RFC 1034 section 3.6.2, RFC 1912 section 2.4)
The exception is when DNSSEC is being used, in which case there can be DNSSEC related records such as RRSIG, NSEC, etc. (RFC 2181 section 10.1)
DNSKEY Record
A DNSKEY-record holds a public key that resolvers can use to verify DNSSEC signatures in RRSIG-records.
FORMAT:
Host Label
It defines the hostname of a record and whether the hostname will be appended to the label. Fully qualified hostnames terminated by a period will not append the origin.
TTL
The time-to-live in seconds. It specifies how long a resolver is supposed to cache the value
Record Class
For all intents and purposes you will use IN (Internet) which default and generally what internet uses. There are technically 3.
Record Type
The record format is defined using this field.
Flags
“Zone Key” (set for all DNSSEC keys) and “Secure Entry Point” (set for KSK and simple keys).
Protocol
The Protocol field must have value 3, and the DNSKEY RR must be treated as invalid during signature verification if it is found to be some value other than 3.
Algorithm
The Algorithm field identifies the public key’s cryptographic algorithm and determines the format of the Public Key field.
Public Key
Public key data.
DS Record
A DS record holds a public key that resolvers can use to verify DNSSEC signatures in RRSIG-records.
FORMAT:
Host Label
It defines the hostname of a record and whether the hostname will be appended to the label. Fully qualified hostnames terminated by a period will not append the origin.
TTL
The time-to-live in seconds. It specifies how long a resolver is supposed to cache or remember the DNS query before the query expires and a new one needs to be done.
Record Class
For all intents and purposes you will use IN (Internet) which default and generally what internet uses. There are technically 3.
Record Type
The record format is defined using this field.
Key Tag
A short numeric value which can help quickly identify the referenced DNSKEY-record.
Algorithm
The algorithm of the referenced DNSKEY-record.
Digest Type
Cryptographic hash algorithm used to create the Digest value.
Digest
A cryptographic hash value of the referenced DNSKEY-record.
HINFO Record
A HINFO record defines the hardware type and Operating System (OS) in use at a host. This record can be used by applications such as SCP, SFTP or FTP, because each uses special procedures when communicating with computers of a known CPU and Operating System (OS).
FORMAT:
Host Label
It defines the hostname of a record and whether the hostname will be appended to the label. Fully qualified hostnames terminated by a period will not append the origin.
TTL
The time-to-live in seconds.
Record Class
For all intents and purposes you will use IN (Internet) which default and generally what internet uses. There are technically 3.
Record Type
The record format is defined using this field.
CPU
A description of basic system hardware. Identifiable name of the CPU of the host.
Operating System
Name of the Operating System (OS) of the host.
LOC Record
A LOC record contains geographic location information such as Latitude, Longitude, Altitude, host/subnet physical size and location accuracy for a domain name. It contains WGS84 Latitude, Longitude and Altitude.
FORMAT:
Host Label
It defines the hostname of a record and whether the hostname will be appended to the label. Fully qualified hostnames terminated by a period will not append the origin.
TTL
The time-to-live in seconds.
Record Class
For all intents and purposes you will use IN (Internet) which default and generally what internet uses. There are technically 3.
Record Type
The record format is defined using this field.
Latitude
Latitude of the geographical position.
Longitude
Longitude of the geographical position.
Altitude
Altitude of the geographical position.
Size
Diameter of the described location in centimeters. (SI Units)
Horizontal Precision
Horizontal precision of the data in centimeters. (SI Units)
Vertical Precision
Vertical precision of the data in centimeters. (SI Units)
YUP METRIC… WEEP AND SEETHE
MX Record
A Mail Exchange (MX) entry directs mail to an email server. Essentially, it specifies how email should be routed when sent to an address at your domain.
FORMAT:
Host Label
It defines the hostname of a record and whether the hostname will be appended to the label. Fully qualified hostnames terminated by a period will not append the origin.
TTL
The time-to-live in seconds.
Record Class
For all intents and purposes you will use IN (Internet) which default and generally what internet uses. There are technically 3.
Record Type
The record format is defined using this field.
Priority
An integer that represents the priority for an email server. If you have only one mails server, the priority can be set to any integer between 0 and 65535. The preference is used when you have more than one mail server for any single domain name.
Mail Server Host
The domain name of the email server. Specify the name (such as mail.< MY-TLD >.net) of an A or AAAA record. The domain name cannot point to a CNAME record.
NAPTR Record
NAPTR record is a type of DNS record that allows the mapping of servers and user addresses in the Session Initiation Protocol (SIP).
FORMAT:
Host Label
It defines the hostname of a record and whether the hostname will be appended to the label. Fully qualified hostnames terminated by a period will not append the origin.
TTL
The time-to-live in seconds.
Record Class
For all intents and purposes you will use IN (Internet) which default and generally what internet uses. There are technically 3.
Record Type
The record format is defined using this field.
Order
The Order field is a number (0 - 65535) specifying the order in which multiple NAPTR records must be processed (low to high) by the application.
Preference
The Preference field is equivalent to the Priority value in the DDDS algorithm. It is a number (0-65535) that specifies the order (low to high) in which NAPTR records with equal Order values should be processed.
Flags
The Flags field contains flags to control aspects of the rewriting and interpretation of the fields in the record. Flags are single characters from the set A-Z and 0-9. The use of this field is specified by the individual DDDS application. Some commonly used Flags are below:
- S (SRV) – the next lookup should be for SRV records.
- A (A, AAAA or A6) – the next lookup should be for either an A, AAAA, or A6 record.
- U (URI) – the next step is not a DNS lookup but that the output of the Regular Expression field is an URI that adheres to the ‘absoluteURI’ production found in the ABNF of RFC 2396.
- P (Protocol Specific) – the remainder of the application side algorithm shall be carried out in a Protocol-specific fashion.
Services The Services field specifies the service parameters applicable to this delegation path. The individual DDDS application specifies the possible values for this field.
Regular Expression The Regular Expression field contains a substitution expression that is applied to the original string held by the client in order to construct the next domain name to lookup. See the DDDS algorithm specification for the syntax of this field.
Replacement The Replacement field specifies the next domain name (fully qualified) to query for depending on the potential values found in the flags field. This field is used when the regular expression is empty (a simple replacement operation). The Regular Expression and Replacement fields are mutually exclusive (only one can contain a value).
NS Record
An NS record or name server record identify which name servers are authoritative for a zone.
FORMAT:
Host Label
It defines the hostname of a record and whether the hostname will be appended to the label. Fully qualified hostnames terminated by a period will not append the origin.
TTL
The time-to-live in seconds.
Record Class
For all intents and purposes you will use IN (Internet) which default and generally what internet uses. There are technically 3.
Record Type
The record format is defined using this field.
Name Server Host
The hostname of the name server. The hostname cannot point to a CNAME record.
PTR Record
PTR records (Pointer Records) are used for reverse DNS lookups. It is a mapping of an IP address to a hostname.
FORMAT:
Host Label
It defines the hostname of a record and whether the hostname will be appended to the label. Fully qualified hostnames terminated by a period will not append the origin.
TTL
The time-to-live in seconds.
Record Class
For all intents and purposes you will use IN (Internet) which default and generally what internet uses. There are technically 3.
Record Type
The record format is defined using this field.
Pointer Name
The server name associated with the IP address.
RP Record
RP record stands for Responsible Person. RP records include information about the mailbox name for the responsible person(s) for the domain. This mailbox name is then mapped to a TXT record within the same zone subsequently queried to retrieve additional information if available.
FORMAT:
Host Label
It defines the hostname of a record and whether the hostname will be appended to the label. Fully qualified hostnames terminated by a period will not append the origin.
TTL
The time-to-live in seconds.
Record Class
For all intents and purposes you will use IN (Internet) which default and generally what internet uses. There are technically 3.
Record Type
The record format is defined using this field.
Mailbox
Mail address of the responsible person, the @ should be replaced by a dot(.).
TXT Domain Name
Domain name of a TXT record with additional information.
SPF Record
An SPF record is a type of TXT record that specifies a list of authorized hostnames/IP addresses that mail can originate from for a given domain name and it prevents spammers from using your domain to send unauthorized emails.
FORMAT:
SEE TXT RECORD
SOA Record
SOA record stands for Start of Authority record and it determines how your zone propagates to the secondary nameservers. Every DNS zone must have a single SOA record and it is the first record in the zone.
FORMAT:
Host Label
It defines the hostname of a record and whether the hostname will be appended to the label. Fully qualified hostnames terminated by a period will not append the origin.
TTL
The time-to-live in seconds.
Record Class
For all intents and purposes you will use IN (Internet) which default and generally what internet uses. There are technically 3.
Record Type
The record format is defined using this field.
Master Name
The host name for the primary DNS server for the zone.
Responsible Name
The email address of the person that is responsible for administering the domain’s zone file. The ‘@’ in the email address is replaced by a dot ‘.’. So hostmaster.< MY-TLD >.net is hostmaster@< MY-TLD >.net
Serial Number
Serial number for this zone is a timestamp that changes whenever something changes in the zone. If a secondary name server slaved to this master zone observes an increase in this number, the slave will assume that the zone has been updated and initiate a zone transfer.
Refresh Interval
The time in seconds that a secondary DNS server waits before querying the primary DNS server’s SOA record to check for changes.
Retry Interval
The number of seconds before a failed refresh should be retried.
Expire Interval
The time in seconds before a zone is considered no longer authoritative. If this time expires before a successful zone transfer, the secondary server will expire its zone file. The secondary will stop answering queries, as it considers its data too old to be reliable.
Negative Caching TTL
The negative result TTL. For example, if a DNS resolver does a DNS query on a subdomain and gets a negative result. The negative caching TTL tells the resolver how long to wait before retrying the query.
SRV Record
An SRV record establishes connections between a service and a hostname. and it contains specific information that can be used to locate a specific resource at an address.
FORMAT:
Host Label
This field of an SRV record is composed of three parts separated by periods (.). These parts are Service , Proto , and Name in the format of _service._proto.name .
- Service is the symbolic name of the desired service, an underscore (_) is added to the service identifier to avoid confusion with DNS labels.
- Proto is the symbolic name of the desired protocol, with an underscore (_) added to prevent collisions with DNS labels that occur in nature.
- Name is the domain or subdomain this record refers to.
TTL
The time-to-live in seconds.
Record Class
For all intents and purposes you will use IN (Internet) which default and generally what internet uses. There are technically 3.
Record Type
The record format is defined using this field.
Priority
An integer that decides the priority of this target host. Much like the priority in MX record, the lower the number in the priority field, the more desirable the associated target.
Weight
This field specifies a relative weight for entries with the same priority. Larger weights are given a higher priority. This value is a number between 0 - 65535. If you have only a single SRV record, use 0 as the weight.
Port
TCP or UDP port where the specified service can be found. This is often as specified in Assigned Numbers but this is not a requirement, for instance, you are allowed to define a _http service with a port number of 81 rather than the default port 80.
Target Host
The domain name of the target host that will be providing this service. Does not have to be in the same zone (domain).
SSH Finger Print Record
The record associates fingerprints with the FQDN
FORMAT:
Host Label
< MY-TLD >.net specifies the hostname of the server to which the SSH key belongs to.
TTL
The time-to-live in seconds.
Record Class
For all intents and purposes you will use IN (Internet) which default and generally what internet uses. There are technically 3.
Record Type
The record format is defined using this field.
Algorithm
An integer value of 0-4.
0 - Reserved. It is a reserved value which is not used.
1 - RSA. RSA is one of the first public-key cryptosystems and is widely used for secure data transmission.
2 - DSA. The Digital Signature Algorithm (DSA) is a Federal Information Processing Standard for digital signatures, based on the mathematical concept of modular exponentiation and the discrete logarithm problem.
3 - ECDSA. The Elliptic Curve Digital Signature Algorithm (ECDSA) offers a variant of the Digital Signature Algorithm (DSA) which uses elliptic curve cryptography.
4 - Ed25519. Ed25519 is the EdDSA signature scheme using SHA-512 (SHA-2) and Curve25519.
Type
An integer value of 0-2.
0 - Reserved. It is a reserved value which is not used.
1 - SHA-1. This produces a 160-bit (20-byte) hash value known as a message digest and is typically rendered as a 40 digits long hexadecimal number.
2 - SHA-256. This is the 256 bit (32-byte) Secure Hash Algorithm 2 to generate the finger print type.
Fingerprint
The hexadecimal representation of the hash result of the SSH key as text.
TLSA Record
The TLSA record is used to associate a TLS server certificate or public key with the domain name where the record is found. Once TLSA records are added to DNS, any browser (or application) will be able to detect whether the TLS service is spoofed by a middle man or phishing crime, and if so, will be able to alert the user.
FORMAT:
Host Label
_443._tcp.< MY-TLD >.net specifies the port number the TLS server listens on (443), the protocol used (tcp) and the hostname of the TLS server (< MY-TLD >.net).
TTL
The time-to-live in seconds.
Record Class
For all intents and purposes you will use IN (Internet) which default and generally what internet uses. There are technically 3.
Record Type
The record format is defined using this field.
Certificate Usage
An integer value of 0-3.
- 0 - Certificate Authority Constraint. It limits which CA can be used to issue certificates for a given service on a host. The presented certificate must pass PKIX certification path validation, and a CA certificate that matches the TLSA record MUST be included as part of a valid certification path.
- 1 - Service Certificate Constraint. It limits which end entity certificate can be used by a given service on a host. The target certificate must pass PKIX certification path validation and must match the TLSA record.
- 2 - Trust Anchor Assertion. This certificate usage allows a domain name administrator to specify a new trust anchor. For example, if the domain issues its own certificates under its own CA that is not expected to be in the end users’ collection of trust anchors. The target certificate must pass PKIX certification path validation, with any certificate matching the TLSA record considered to be a trust anchor for this certification path validation.
- 3 - Domain Issued Certificate. The services use a self-signed certificate. The difference between certificate usage 1 and certificate usage 3 is that certificate usage 1 requires that the certificate pass PKIX validation, but PKIX validation is not tested for certificate usage 3.
Selector
An integer value of 0 or 1.
- 0 - Full certificate. It means to select the entire certificate for matching.
- 1 - Use Subject Public Key. It means to select just the public key for certificate matching.
Matching Type
An integer value of 0 to 2.
- 0 - No hash. Exact match on selected content
- 1 - SHA-256 hash of selected content
- 2 - SHA-512 hash of selected content.
Certificate Association Data
The actual data to be matched given the settings of the other fields. These bytes are either raw data (that is, the full certificate or its Subject Public Key, depending on the selector) for matching type 0, or the hash of the raw data for matching types 1 and 2.
TXT Record
A TXT record holds free-form text of any type. A fully qualified domain name may have many TXT records. Some of the common TXT records are Sender Policy Framework (SPF), DomainKeys Identified E-mail (DKIM).
FORMAT:
Host Label
It defines the hostname of a record and whether the hostname will be appended to the label. Fully qualified hostnames terminated by a period will not append the origin.
TTL
The time-to-live in seconds.
Record Class
For all intents and purposes you will use IN (Internet) which default and generally what internet uses. There are technically 3.
Record Type
The record format is defined using this field.
TXT Data
Free form text of any type. It may contain any printable ASCII symbols but the maximum length is 255 characters only. You may have more than 255 characters of data in a TXT record, but not more than 255 characters in a single string. To get around this limitation, per RFC 4408 a TXT record is allowed to contain multiple strings, which should be concatenated together by the reading application.
Special Types
SPF (Sender Policy Framework) record
A Sender Policy Framework (SPF) record tells the rest of the Internet which email servers are allowed to send emails for a domain. This helps reduce spam by letting the recipient’s mail servers check an email’s sending IP against the domain’s SPF record. If the two do not match, the recipient’s mail server has the option to reject the message or flag it as spam.
DKIM record
DKIM stands for Domain Keys Identified Email and it is a way of ‘signing’ emails to prove they are delivered by the organization that has the right to do so and prevents spammers from stealing the identity of legitimate entities.
DKIM uses a pair of public and private keys - the private key is known only to you and is stored on the sending mail server to create the signature. The public key is available to anyone and can be used to verify that the correct private key was used. What we are adding to the DKIM TXT record is the public key.
URI Record
A URI record is used to publish mappings from hostnames to URIs. Learn more about URI Record.
FORMAT:
Host Label
This field of an SRV record is composed of three parts separated by periods (.). These parts are Service , Proto , and Name in the format of _service._proto.name .
- Service is the symbolic name of the desired service, an underscore (_) is added to the service identifier to avoid confusion with DNS labels.
- Proto is the symbolic name of the desired protocol, with an underscore (_) added to prevent collisions with DNS labels that occur in nature.
- Name is the domain or subdomain this record refers to.
TTL
The time-to-live in seconds. The URI record has no special TTL requirements and thus often uses the default.
Record Class
For all intents and purposes you will use IN (Internet) which default and generally what internet uses. There are technically 3.
Record Type
The record format is defined using this field.
Priority
An integer that decides the priority of this target host. Much like the priority in MX record, the lower the number in the priority field, the more desirable the associated target.
Weight
This field specifies a relative weight for entries with the same priority. Larger weights are given a higher priority. This value is a number between 0 - 65535. If you have only a single URI record, use 0 as the weight.
Target URI
The URI of the target, enclosed in double-quote characters ("). Resolution of the URI is according to the definitions for the URI Scheme the URI consists of.
Setting up TLSA
Please see the full explanation of TLSA records in the records reference.
I am going to summarized the RFCs for you:
TLSA is one step in the process of beginning to implement DNS DANE. You see, a browser establishes a secure TLS connection to a known server with an “unkown” certificate which cannot be provided to the end user explicitly connecting to just the known server. We are relying to certificate authorities and guess what any CA is able to sign every certificate in the world, even if a certificate is NOT owned by the server itself, but by a malicious third party that wants to intercept the secure communication via a man-in-the-middle (MITM) attack. You can see how this kind of breaks the trust system and that CAs are inherently flawed. We should neuter them with DNSSEC and thats what TLSA is doing with the new DNS resource record “TLSA”, the hashed public key is publicized within the DNS server of the same authority/entity that owns the TLS server whom is also serving the page. Now the client can validate that the server TLS certificate is owned by the same organization which owns the DNSSEC server. This results in MITM attacks with spoofed certificates not being possible anymore. As for creating it. This is not too difficult. The Hashslinger suite lets us do that. Please find documentation to acquire it on your particular distribution. It will provide the TLSA command I am using to generate the record from my .cert file that is used on my webserver for HTTPS. Syntax may vary depending on packaging. You may also use an online tool if you rather do that.
tlsa --create --selector 0 --matching-type 2 --certificate < MY-TLD >.cert < MY-TLD >.net
The record will be spat out and you enter it as following per TLS port you use. I only have two currently so see my picture below. Dont worry this is not a sensitive value. Nobody else has your cert priv key combination “ideally” so they cannot steal this key and invalidate your responses or validate theirs.
DONT forget to increment the serial number and to
rndc reload && rndc sign $FQDN && systemctl restart named
You will need to do this EVERYTIME
Ignoring NVIM throwing a fit for literally no reason, this is what it should look like:
Done correctly you can verify the TLSA output via
dig _443._tcp.< MY-TLD >.net tlsa +dnssec +multi
If you see the outputs you entered after propagation. Congratulations you have successfully registered the entries
The other way to check is to use an online tool that spits out the following
Host: < MY-TLD >.net Port: 443
SNI: < MY-TLD >.net
DNS TLSA RRset:
qname: _443._tcp.< MY-TLD >.net.
3 0 2 a8e3347d52b143227bb18cf8667a5af07feca3d14f4efa0fbbdef7238ab35b2154370c7bdd7176fc05b4cdf3a22f08d34d2430d4f56d18a1a1320742f8a1c613
IP Addresses found:
2600:3c04::f03c:92ff:fec6:2030
192.53.120.164
## Checking < MY-TLD >.net 2600:3c04::f03c:92ff:fec6:2030 port 443
DANE TLSA 3 0 2 [a8e3347d..]: OK matched EE certificate
## Peer Certificate Chain:
0 CN=*.< MY-TLD >.net
CN=Sectigo ECC Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
1 CN=Sectigo ECC Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
CN=USERTrust ECC Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US
2 CN=USERTrust ECC Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US
CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB
## Verified Certificate Chain 0:
0 CN=*.< MY-TLD >.net
CN=Sectigo ECC Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
1 CN=Sectigo ECC Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
CN=USERTrust ECC Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US
2 CN=USERTrust ECC Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US
CN=USERTrust ECC Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US
## Verified Certificate Chain 1:
0 CN=*.< MY-TLD >.net
CN=Sectigo ECC Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
1 CN=Sectigo ECC Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
CN=USERTrust ECC Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US
2 CN=USERTrust ECC Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US
CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB
3 CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB
CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB
## TLS Connection Info:
TLS version: TLS1.3
CipherSuite: TLS_AES_256_GCM_SHA384
## End-Entity Certificate Info:
X509 version: 3
Serial#: df93881f10fa043914f850259d2864c1
Subject: CN=*.< MY-TLD >.net
Issuer: CN=Sectigo ECC Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
SAN dNSName: *.< MY-TLD >.net
SAN dNSName: < MY-TLD >.net
Signature Algorithm: ECDSA-SHA256
PublicKey Algorithm: ECDSA 765-Bits
Inception: 2021-10-08 00:00:00 +0000 UTC
Expiration: 2022-11-08 23:59:59 +0000 UTC
KU: DigitalSignature
EKU: ServerAuth ClientAuth
Is CA?: false
SKI: 980083eec7df12ab18571abe63197051affc825a
AKI: f6850a3b1186e1047d0eaa0b2cd2eecc647b7bae
OSCP Servers: [http://ocsp.sectigo.com]
CA Issuer URL: [http://crt.sectigo.com/SectigoECCDomainValidationSecureServerCA.crt]
CRL Distribution: []
Policy OIDs: [1.3.6.1.4.1.6449.1.2.2.7 2.23.140.1.2.1]
Result: DANE OK
## Checking < MY-TLD >.net 192.53.120.164 port 443
DANE TLSA 3 0 2 [a8e3347d..]: OK matched EE certificate
## Peer Certificate Chain:
0 CN=*.< MY-TLD >.net
CN=Sectigo ECC Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
1 CN=Sectigo ECC Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
CN=USERTrust ECC Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US
2 CN=USERTrust ECC Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US
CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB
## Verified Certificate Chain 0:
0 CN=*.< MY-TLD >.net
CN=Sectigo ECC Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
1 CN=Sectigo ECC Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
CN=USERTrust ECC Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US
2 CN=USERTrust ECC Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US
CN=USERTrust ECC Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US
## Verified Certificate Chain 1:
0 CN=*.< MY-TLD >.net
CN=Sectigo ECC Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
1 CN=Sectigo ECC Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
CN=USERTrust ECC Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US
2 CN=USERTrust ECC Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US
CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB
3 CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB
CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB
## TLS Connection Info:
TLS version: TLS1.3
CipherSuite: TLS_AES_256_GCM_SHA384
## End-Entity Certificate Info:
X509 version: 3
Serial#: df93881f10fa043914f850259d2864c1
Subject: CN=*.< MY-TLD >.net
Issuer: CN=Sectigo ECC Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
SAN dNSName: *.< MY-TLD >.net
SAN dNSName: < MY-TLD >.net
Signature Algorithm: ECDSA-SHA256
PublicKey Algorithm: ECDSA 765-Bits
Inception: 2021-10-08 00:00:00 +0000 UTC
Expiration: 2022-11-08 23:59:59 +0000 UTC
KU: DigitalSignature
EKU: ServerAuth ClientAuth
Is CA?: false
SKI: 980083eec7df12ab18571abe63197051affc825a
AKI: f6850a3b1186e1047d0eaa0b2cd2eecc647b7bae
OSCP Servers: [http://ocsp.sectigo.com]
CA Issuer URL: [http://crt.sectigo.com/SectigoECCDomainValidationSecureServerCA.crt]
CRL Distribution: []
Policy OIDs: [1.3.6.1.4.1.6449.1.2.2.7 2.23.140.1.2.1]
Result: DANE OK
[0] Authentication succeeded for all (2) peers.
Setting up SSH Fingerprint Records
These are ridiculously simple to generate.
ssh-keygen -r $FQDN
Then enter like below and you have defined all your finger prints for your server. Connecting from new machines via SSH will no longer say they cannot validate the hash. The DNSSEC records now validate it for you!
DONT forget to increment the serial number and to
rndc reload && rndc sign $FQDN && systemctl restart named
You will need to do this EVERYTIME
Ignoring NVIM throwing a fit for literally no reason, this is what it should look like:
Done correctly you can verify the TLSA output via
dig < MY-TLD >.net sshfp +dnssec +multi
If you see the outputs you entered after propagation. Congratulations you have successfully registered the entries
Did you slay the dragon?
If you made it here. You survived and likely have your own auth DNS servers. Congratulations and good luck going forward!
Links to Infrastructure Series and Other Resources
Blog: Phaselockedloopable- PLL’s continued exploration of networking, self-hosting and decoupling from big tech
Series 1: Native Dual Stack IP4+IP6
Infrastructure Series – Native Dual Stack IP4+IP6
Series 2: Wireguard Site to Site Tunnel
Infrastructure Series – Wireguard Site to Site Tunnel
Series 3: Recursive DNS and Adblocking DNS over TLS w/NGINX
Infrastructure Series – Recursive DNS and Adblocking DNS over TLS w/NGINX
Series 4: NGINX Reverse Proxy and Hardening SSL
Infrastructure Series – NGINX Reverse Proxy and Hardening SSL
Series 5: Taking DNS One Step Further - Full DNS Server infrastructure
Infrastructure Series – Taking DNS One Step Further - Full DNS Server infrastructure
Series 6: HTTP(S) Security Headers! You should use them!
Infrastructure Series – HTTP(S) Security Headers! You should use them! [NGINX]
Series 7: Use NGINX to inject CSS themes
Infrastructure Series – Use NGINX to inject CSS themes
ONE KEY TO RULE THEM ALL
Setting up a YubiKey Properly – One Key to rule them ALL!
Series 9: Infrastructure Series: BIND9 Authoritative DNS Guide “Please See Me Edition”
Infrastructure Series: BIND9 Authoritative DNS Guide “Please See Me Edition”
Buy me a crypto-beer
If you found this guide helpful you can donate Monero or Bitcoin to me at the following address in my User Card Profile
