Introduction
DNSSEC uses a system of public keys and digital signatures to ensure that you're communicating with the website or internet location you intended to visit. When a visitor enters a domain name in a browser, the resolver verifies the digital signature. If the digital signatures in the data match those that are stored in the master DNS servers, then the data is allowed to access the client computer making the request.
DNSSEC adds new records to DNS alongside existing records. These new record types, such as RRSIG and DNSKEY, can be retrieved in the same way as common records such as A, CNAME, and MX. These new records are used to digitally "sign" a domain, using a method known as public-key cryptography.
Advantages of DNSSEC:
DNSSEC is aimed at strengthening trust in the internet by helping to protect users from redirection to fraudulent websites and unintended addresses. It can help prevent malicious activities like cache poisoning, pharming, and man-in-the-middle attacks. DNSSEC authenticates the resolution of IP addresses with a cryptographic signature, to make sure that answers provided by the DNS server are valid and authentic. If DNSSEC is properly enabled for your domain name, you visitors can be assured that they are connecting to your actual website and not a fraudulent copy.
Prerequisites
- Dig: command-line tool for querying the Domain Name System (DNS)
Installation & Configuration
Install dig on CentoS 7
Use the yum command:
$ sudo yum install bind-utils
Implementation
Root keys
First copy the attached file root.keys to the sandbox directory.
Dig needs to be given a trust anchor. This refers to one or more keys that are trusted by definition and do not need to be verified further. The role of these keys is similar to the root SSL certificates installed in the browser; when something is signed with them, the verification ends successfully.
The perfect keys to use (and, in an ideal world where DNSSEC is fully deployed, the only needed) are the root keys, i.e. the keys found in the "." zone. To download them manually with Dig instead of copying the root keys from this article, follow these steps:
Navigate to sandbox directory:
$ cd /opt/3genlabs/hawk/syntheticnode/service/shellmonitor/sandbox
Download the keys:
$ dig . DNSKEY | grep -Ev '^($|;)' > root.keys
DNSKEY record 256 is the public key referred to as Zone-signing-key, and is used to verify the DNS record signatures for A, MX, CNAME, SRV, etc. The DNS response includes two records: 
DNSKEY record 257 is called the Key-Signing Key, which verifies the signatures of the DNSKEY, CDS, and CDNSKEY records.
Note: If you are using non-standard DNSSEC and have a trusted key that is different from the route, that key will need to be stored in the root.keys
Place the custom script
Navigate to /opt/3genlabs/hawk/syntheticnode/service/shellmonitor/sandbox to set up custom script.
Copy the attached file dnssec.sh to the sandbox directory. Run the following commands to change file permission and owner.
$ chmod 500 dnssec.sh
$ chown serveruser dnssec.sh
** Create the Custom Test **
To configure the script in the Catchpoint Portal, navigate to the Test page, and create a Custom Test. This will open the Test Properties page where we need to fill in script details.
The script file name should be the same as the file placed in the sandbox folder. This file would be the first point of execution when the run is triggered. In our example, it would be “dnssec.sh”.
We need to add custom fields to this script. One for passing the host and record_type can be A, AAAA, MX, and so on.
Results
Based on the output that gets printed in the console, you can set up alerts in case the DNSSEC verification fails. Below are the screenshots of the results:
DNSSEC verification successful: 
DNSSEC verification failed:
To create an Advanced Alert:
- If no alerts have been created, click on the Switch to Advanced Alerts button to display the Advanced Alerts table. If an alert already exists, click the Add button in the bottom right of the table. This adds a new row to the table.
- To edit an existing event, locate the row for the alert you want to edit, and click on the Edit button in the far-right column. This displays the event settings
- Choose the Alert Type as Content Match > Regular Expression and define Trigger. The type of event determines which Trigger fields are displayed.
- Select equals under trigger field and FAILED as the string to match.
- Also, ensure you check Enforce test failure when triggered on a node.
To store your changes, click Test.
The above configuration marks the test runs have failed when the DNSSEC verification fails.
