--- title: "DNSSEC Custom Monitor" slug: "dnssec-custom-monitor" updated: 2023-01-06T21:03:12Z published: 2023-01-06T21:03:12Z --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.catchpoint.com/llms.txt > Use this file to discover all available pages before exploring further. # DNSSEC Custom Monitor ## **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: ![IMG1.png](https://cdn.document360.io/cb4af8f9-6751-4fd2-b39c-07aae832badb/Images/Documentation/360058268852-IMG1.png) 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”**. ![IMG2.png](https://cdn.document360.io/cb4af8f9-6751-4fd2-b39c-07aae832badb/Images/Documentation/360058288412-IMG2.png) 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. ![IMG3.png](https://cdn.document360.io/cb4af8f9-6751-4fd2-b39c-07aae832badb/Images/Documentation/360058288852-IMG3.png) ## **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**: ![IMG4.png](https://cdn.document360.io/cb4af8f9-6751-4fd2-b39c-07aae832badb/Images/Documentation/360058289352-IMG4.png) **DNSSEC verification failed**: ![IMG5.png](https://cdn.document360.io/cb4af8f9-6751-4fd2-b39c-07aae832badb/Images/Documentation/360058455491-IMG5.png) To create an Advanced Alert: 1. 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. 2. 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 3. Choose the **Alert Type** as **Content Match > Regular Expression** and define **Trigger**. The type of event determines which Trigger fields are displayed. 4. Select **equals** under trigger field and **FAILED** as the string to match. 5. 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.** **![IMG6.png](https://cdn.document360.io/cb4af8f9-6751-4fd2-b39c-07aae832badb/Images/Documentation/360058290232-IMG6.png)** [root.keys](https://cdn.document360.io/cb4af8f9-6751-4fd2-b39c-07aae832badb/Images/Documentation/root.keys) [dnssec.sh](https://cdn.document360.io/cb4af8f9-6751-4fd2-b39c-07aae832badb/Images/Documentation/dnssec.sh)