Return to Level1Techs.com

Infrastructure Series: BIND9 Authoritative DNS Guide "Please See Me Edition"

Table Of Contents

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 fairly accurate summation. However those who have a strong foundational sense of why we are doing what we are about to embark on will not only work more effectively towards the goal but be more efficient in future goals, tangential or not.

Mind Set Conditioning:
This post will not take a technicians approach (though it could be used as such) in explaining and performing the procedures we will today. I ask you to put yourself into an engineer mindset. The engineer way of designing a system is break it all the way down to its tiniest piece parts. Understand how it fits together. Put it back together. Design the system around the understood master concept. Everything has a label. Everything has a purpose. If it does not its designed out. When people say engineers create magic ( a term I often hear). Its not magic. It just works because the caretaker or architect of the system took sufficient time to understand what he or she was doing. That is the “Why” of stepping through how it works.

So lets start from the real 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 connection is established by switching systems that connected multiple intermediate call legs between these systems for the duration of the call. 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 real need for ARPAnet came out of frustration of not having access to a very limited number of supercomputers in the world. There was a way around this, ARPAnet really was the first concept of “distributed computing” and thus with 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. In fact, 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 just how did you find your way?

History of DNS

Believe it or not that hosts file dates before most of your birth years including mind. ARPAnet was small and therefore all that was originally needed was a single file. hosts.txt, 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 (mostly by deleting fields Unix didn’t use). Remember this. It is important later because DNS retains a UNIX structure.

There were a lot of issues with this as you can imagine and as the network grew you can imagine that the the burden on the network information centers systems, in terms of the network traffic and processor load involved in distributing the file, was becoming unbearable. 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. There was nothing 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 major mail hub, for example, could disrupt mail service to much of the ARPAnet. This can and did happen, numerous times. The many messups, cleanups etc all lead to a highly inconsistent file. So a solution was needed a distributed database of name resolutions. There is the why. The how would be a quasi decentralized (its still centralized in some manner today) autonomous system that eliminated the single host bottled neck. Thus allowing people to write and make their modifications to 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 segment 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 can 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 all the way down into its deepest folder-file piece parts.

image

Now look at DNS

Understanding this similarity helps debugging and helps pull it all together in one heads visually. The internet DNS system is a tree with power shared. The root tells everyones what TLDs can exist and the TLDs point down to the local servers where authority and power is derived from. The records you eventually set control the tree within your authority zone, as seen above. Every domain has a unique name, like every directory. A domain’s domain 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 root of the whole tree with dots (.) separating the labels often denoted by canonical names if pointing at the same server.

Each authority zone is autonomously managed by the zone authority. The root authority points downwards in recursion. Every DNS server eventually queries the root in its search for where somebody’s address is at. The delegation allows the localization of control of those pages. Its kind of 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 fairly good at illustrating the point of a zone and it will help you understand what we are placing in the configuration later!



And so on and so forth. If a subdomain as 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 is called subdomain delegation. You probably will not need it for a home lab.

I think this forms the basis of your understanding and while 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 understand 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

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. There is another system called OpenNIC and they have their own root servers.

Top Level Domain Server
A TLD nameserver maintains information for all the domain names that share a common 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 that are 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 the domain name it serves like duckduckgo.com and 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 which 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 either respond with cached data (highly likely), or send a request to a root nameserver. The root name server will respond with the locations of 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 youa re going. After receiving a response from the authoritative nameserver containing the requested IP address, the recursive resolver then sends a response 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 that you will find to be standard and synonymous with most peoples DNS backbone. There are other systems however it is the one we will focus on today.

Bind has the ability to 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. For recursion I highly suggest unbound as it is much easier to configure for most folks. Authoritative-only DNS servers are often a good 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 am going to achieve this by having two Linodes spun up in the freemont datacenter. For all intents and purposes I really dont 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 in the event that 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) 
[email protected]`  ~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 
 )[email protected]`       _QIililig,
  )iiii>`       .Qliliiiililw                                 
   )<>~       .mliiiiiliiiiiil,                               
            _gllilililiililii~
           giliiiiiiiiiiiiT`
          -^[email protected]~~'

~ ❯    

I leave the task of hardening and securing your server once again to you. You know your needs and use case better than I. 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 simply 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.utangard.net 23.239.20.9, 2600:3c01::f03c:92ff:fece:5fc0
Slave Name Server ns2.utangard.net 173.255.255.89, 2600:3c01::f03c:92ff:fe9e:3ef0
Recursive Resolver utangard.net (DNS/DoT), dns.utangard.net (DoH) 192.53.120.164, 2600:3c04::f03c:92ff:fec6:2030
Web Server utangard.net, *.utangard.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 since 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 being 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 do not want anybody to transfer all our zones so we have that set to none. We will set this on a per zone basis.

The next section we will configure the local zone. The zone we will configure as the one we are the authority over.

Defining the Zone

My zone definition looks like this:

// Utangard Auth Zones
zone "utangard.net" in {
      type master;
      file "/var/opt/isc/scls/isc-bind/named/utangard.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 transfer allowed is to our Slave server. Please ignore the DNSSEC Policy and Inline-signing values until later. 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/utangard.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 a good 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 give you a network range and delegate responsibility for that range to you, then your reverse zone file will not be referenced and will be handled by the organization itself. Since this is my case. While I could write one it would be useless to me save maybe a mail server to which 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.

// Utangard Auth Zones
zone "utangard.net" {
      type slave;
      file "/var/opt/isc/scls/isc-bind/named/utangard.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 there are 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 slave DNS server are loaded from a zone transfer, which is used to synchronize DNS record changes from master DNS server to slave DNS server. To verify the transfer occured look for the transfer completing 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.utangard.net 23.239.20.9, 2600:3c01::f03c:92ff:fece:5fc0
Slave Name Server ns2.utangard.net 173.255.255.89, 2600:3c01::f03c:92ff:fe9e:3ef0
Recursive Resolver utangard.net (DNS/DoT), dns.utangard.net (DoH) 192.53.120.164, 2600:3c04::f03c:92ff:fec6:2030
Web Server utangard.net, *.utangard.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.

Lets being with writing a DNSSEC Policy. We are going to 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 :wink:

 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.utangard.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.utangard.net is [email protected]

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
utangard.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.utangard.net specifies the port number the TLS server listens on (443), the protocol used (tcp) and the hostname of the TLS server (utangard.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:
https://datatracker.ietf.org/doc/html/rfc6698
https://datatracker.ietf.org/doc/html/rfc7218
https://datatracker.ietf.org/doc/html/rfc7671
https://datatracker.ietf.org/doc/html/rfc7672

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 utangard.cert utangard.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.utangard.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

https://www.huque.com/bin/danecheck

Host: utangard.net Port: 443
SNI: utangard.net
DNS TLSA RRset:
  qname: _443._tcp.utangard.net.
  3 0 2 a8e3347d52b143227bb18cf8667a5af07feca3d14f4efa0fbbdef7238ab35b2154370c7bdd7176fc05b4cdf3a22f08d34d2430d4f56d18a1a1320742f8a1c613
IP Addresses found:
  2600:3c04::f03c:92ff:fec6:2030
  192.53.120.164

## Checking utangard.net 2600:3c04::f03c:92ff:fec6:2030 port 443
DANE TLSA 3 0 2 [a8e3347d..]: OK matched EE certificate
## Peer Certificate Chain:
   0 CN=*.utangard.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=*.utangard.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=*.utangard.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=*.utangard.net
   Issuer:  CN=Sectigo ECC Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
   SAN dNSName: *.utangard.net
   SAN dNSName: utangard.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 utangard.net 192.53.120.164 port 443
DANE TLSA 3 0 2 [a8e3347d..]: OK matched EE certificate
## Peer Certificate Chain:
   0 CN=*.utangard.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=*.utangard.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=*.utangard.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=*.utangard.net
   Issuer:  CN=Sectigo ECC Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
   SAN dNSName: *.utangard.net
   SAN dNSName: utangard.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 utangard.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!

Any services discovered in this guide are pursuant to the following Policy: https://services.utangard.net/privacyLegal.html

Links to Infrastructure Series and Other Resources

Blog: Phaselockedloopable- PLL’s continued exploration of networking, self-hosting and decoupling from big tech

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

5 Likes

Reserved

And here I thought I was the one writing insanely big tutorials.

I decided to give you a reason to take insanely big to levels that cant fit in the forum :wink:

I will keep this guide in mind when doing my own infrastructure.

But I try my best to keep the verbosity down, so that more people will be interested in reading it. I don’t like writing “scientific papers,” I prefer letters for the layman. I managed it a little in my s6 user guide, but that needs more work.

I am now at 3 guides that I haven’t managed to finish definitively, what am I even doing?

1 Like

You know I’m gonna be frank and I’ll say this in the lounge too

There are no words

No levels of zoltan

No biky verbosity indexes

To describe how long and how in depth

This wiki is by necessity

It has truly gone where no wiki… Has ever… Gone… Before

Also I have zero issues with the length of your posts. Its a fun joke

1 Like

Yeah, well, try reading the OpenNebula documentation.

I’m good lol

1 Like

Up to you obv, but I’ve found that using collapsible sections can make long how-to’s easier to navigate.

Old example:

Not sure if that breaks the table of contents though… does that generate automatically or did you do something?

2 Likes

It breaks it so you need duplicate headings

I wish that wasn’t the case. Really should figure out how to get a mix of both world

1 Like

I think you can use dnssec-signzone for this? Or is that redundant to what rndc does?

https://linux.die.net/man/8/dnssec-signzone


Nvm, I think that’s just if you’re doing it manually.

I think you are missing auto-dnssec maintain; in your zone though?

Ahh I should have mentioned there are two ways of maintaining that.

A DNSSEC policy where you define the time periods or fully automatic. I preferred to sign my domains with the 384 key and high sha hashes vs let bind decide for me.

Either way its automatic the issue is I dont very much like waiting on a DNS change so thats why I advise people how to do it quickly

Though it has a 1% chance of making the journal out of sync. In which case delete the .jnl files and restart bind LOL

If you do a policy btw check conf will tell you it cannot auto maintain

1 Like

Looking at this, it appears the key rollovers are still not fully automatic

https://dnsinstitute.com/documentation/dnssec-guide/ch04s06.html#maintenance-tasks-zsk-rollover

ZSK Rollover

Assuming you are rolling your ZSK every year on January 1st, below is the timeline of what should happen:

  1. December 1st, a month before rollover date:
  • Change timer on current ZSK
  • Generate new ZSK
  • Publish new DNSKEY
  1. January 1st, day of rollover:
  • New ZSK used to replace RRSIGs for the bulk of the zone
  1. February 1st, a month after rollover date:
  • Remove old DNSKEY from zone
  • DNSKEY signatures made with KSK are changed

This may look like a lot of work, but with inline-signing and auto-dnssec , most of these are automated. The only things that need to be done manually are just the first two items:

  • Change timer on current ZSK
  • Generate new ZSK

For an example of how to execute a ZSK rollover, please see the section called “ZSK Rollover Recipe”.

KSK Rollover

KSK rollover is very similar to ZSK, with the addition of interacting with the parent zone. In fact, as you can see below, the timeline looks nearly identical to the ZSK rollover, with the addition of interaction with parent zone:

  1. December 1st, a month before rollover date:
  • Change timer on current KSK
  • Generate new KSK and DS records
  • Upload new DS records to parent zone
  1. January 1st, day of rollover:
  • Use new KSK to sign all DNSKEY RRset, this generates new RRSIGs
  • Add new RRSIGs to the zone
  • Remove old RRSIGs from zone
  1. February 1st, a month after rollover date:
  • Remove old KSK DNSKEY from zone
  • Remove old DS records from parent zone

Unfortunately, as of this writing, KSK rollover involves a lot of manual steps. As described above, the only automated tasks are the ones that occur on the day of the rollover (January 1st), everything else needs to be done manually. To see an example of how to perform a KSK rollover, please see the section called “KSK Rollover Recipe”.

This makes my head hurt…

1 Like

So what’s stopping me from deleting the signed zone. All the keys … Incrementing the serial and reloading bind causing it to use the dnssec policy to regenerate everything?

Its jank but I bet that would work as it has to regenerate the signatures too

A lot of the complexity is because during the TTL, the new and old keys should both be valid:

  1. Pre-publication : Publish the new ZSK into zone data before it is actually used. Wait at least one TTL so the world’s recursive servers know about both keys, then stop using the old key and generate new RRSIG using the new key. Wait at least another TTL, so the cached old key data is expunged from world’s recursive servers, before removing the old key.The benefit of the Pre-publication approach is it does not dramatically increase the zone size, but the duration of the rollover is longer. If insufficient time has passed after the new ZSK is published, some resolvers may only have the old ZSK cached when the new RRSIG records are published, and validation may fail. This is the method that was described in the section called “ZSK Rollover” and the section called “ZSK Rollover Recipe”
  2. Double Signature : Publish the new ZSK and new RRSIG, essentially double the size of the zone. Wait at least one TTL before removing the old ZSK and old RRSIG.The benefit of the Double Signature approach is that it is easier to understand and execute, but suffers from increased zone size (essentially double) during a rollover event.

Hmm my TTLs are set very low. yeah Ill have to look intot his then. It makes my head hurt too

1 Like

Also, it looks like the automated bind stuff doesn’t generate the new keys? Just handles the zone signing?

hmm it did for me. I wonder if they havent updated the docs. This is gonna be a pain every november LOL

1 Like

wait this was written 3 years ago hold on a sec let me grab something

how does that affect this method of signing?

https://bind9.readthedocs.io/en/v9_16_22/dnssec-guide.html#creating-a-custom-dnssec-policy