DNS Monitoring

Application Version Details

Introduction

DNS (Domain Name System) is a service that translates human-readable web addresses (e.g., app.example.com) into computer-readable IP addresses
(e.g., 192.1.1.1) and stores them in a hierarchical address database.

The IP address enables the browser to locate the server with the requested content. The pairing of the hostname and the IP address is called a namespace. Monitoring your DNS records helps you insure that the DNS continues to route traffic properly to your websites, services, and electronic communications.

Components of DNS

The individual records of a DNS are called Resource Records (RR) and the individual parts of a DNS database are called zones. Within these zones are several server and record types. In order to successfully monitor DNS, it is important to be familiar with what each component does in the larger system.

How does DNS work

The process of using a hostname (e.g., app.example.com) to get an IP address (e.g., 192.1.1.1) is called resolving. Resolving a hostname requires four different DNS server types. So these four different DNS servers work together to get you to the content you need:

• DNS Recursor
• Root Name Server
• TLD Nameserver
• Authoritative Nameserver

Let us quickly look at these server types and what they do.

• DNS Recursor: The recursor server receives queries from client machines through applications like web browsers and checks for the resolving IP address in its cache. This server is also responsible for making any additional requests to satisfy the client’s DNS query. Recursor servers have no authority over record information.

• Root Name Server: The root server takes up the job when a DNS Recursor cannot find the relevant address in its cache. It exists at the top of the DNS hierarchy in a space known as the root zone. Queries reaching the root zone are redirected to the correct zone by responding to the recursor with the IP address of the Top-Level Domain (TLD) nameserver that should handle the query. The internet consists of 13 root zone servers.

• TLD Nameserver: The top-level domain server (TLD) handles the next step in the search for a specific IP address. It categorizes domain names and provides the recursor server with the relevant authoritative nameserver’s IP address that it should check.

• Authoritative Nameserver: The authoritative nameserver has information for specific hostnames, such as example.com. It resolves the hostname to its corresponding IP address and sends that address back to the recursor server, where it is then passed to the client’s browser. The browser then accesses the site using the IP address.

DNS Record Types

There are 40 different DNS record types, all of which include multiple fields that specify information about the domain. The following are some of the most commonly used DNS record types:

Address Mapping record (A Record): Also known as a DNS host record, stores a hostname and its corresponding IPv4 address.

IP Version 6 Address record (AAAA Record): Stores a hostname and its corresponding IPv6 address.

Canonical Name record (CNAME Record): It can be used to alias a hostname to another hostname. When a DNS client requests a record that contains a CNAME, which points to another hostname, the DNS resolution process is repeated with the new hostname.

Mail exchanger record (MX Record): It specifies an SMTP email server for the domain, used to route outgoing emails to an email server.

Name Server records (NS Record): It specifies that a DNS Zone, such as “example.com” is delegated to a specific Authoritative Name Server, and provides the address of the name server.

Reverse-lookup Pointer records (PTR Record): It allows a DNS resolver to provide an IP address and receive a hostname (reverse DNS lookup).

Certificate record (CERT Record): It stores encryption certificates—PKIX, SPKI, PGP, and so on.

Service Location (SRV Record): The service record gives the host and port for a service such as instant messaging.

Text Record (TXT Record): These records are plain text entries that you may use for notes. They are important for holding domain owners accountable for how they use domains. It is also one way to protect your domain from being used to send spam.

Start of Authority (SOA Record): Your SOA record has a serial number that the system updates each time a change happens anywhere on your DNS entry. Knowing a change has been made can help you prevent a possible attack. This record appears at the beginning of a DNS zone file, and indicates the Authoritative Name Server for the current DNS zone, contact details for the domain administrator, domain serial number, and information on how frequently DNS information for this zone should be refreshed.

Monitoring your DNS entries should be at the top of your priority list. To keep an eye on your DNS consider monitoring some of them like IP address(es), SOA Record, MX record and SRV record, NS record and root servers.

What does DNS response probe do:

A particular host or domain is resolved as expected without any delay. It queries your Domain Name Server (DNS) and monitors the response time from the server.

Prerequisites

• OpsRamp Classic Gateway 14.0.0 and above.
• OpsRamp Nextgen Gateway 14.0.0 and above.
  Note: OpsRamp recommends using the latest Gateway version for full coverage of recent bug fixes, enhancements, etc.

Application Migration

1. Check for the gateway version as a prerequisite step - classic gateway-12.0.1 and above.
   Notes:

   • You only have to follow these steps when you want to migrate from sdk 1.0 to sdk 2.0.
   • For the first time installation below steps are not required.

2. Disable all configurations associated with sdk 1.0 adaptor integration application.

3. Install and Add the configuration to that sdk 2.0 application.
   Note: refer to Configure and Install the DNS Integration & View the DNS Details sections of this document.

4. Once all discoveries are completed with the sdk 2.0 application, follow any one of the approaches.

   • Direct uninstallation of the sdk 1.0 adaptor application through the uninstall API with skipDeleteResources=true in the post request
     
     End-Point: https://{{host}}/api/v2/tenants/{tenantId}/integrations/installed/{installedIntgId}
     
     Request Body:

         {
         "uninstallReason": "Test",
         "skipDeleteResources": true
         }

     
     
     (OR)
     
     
   • Delete the configuration one by one through the Delete adaptor config API with the request parameter as skipDeleteResources=true
     
     End-Point: https://{{host}}/api/v2/tenants/{tenantId}/integrations/installed/config/{configId}?skipDeleteResources=true.
     
     
   • Finally, uninstall the adaptor application through API with skipDeleteResources=true in the post request.
     
     End-Point: https://{{host}}/api/v2/tenants/{tenantId}/integrations/installed/{installedIntgId}
     
     Request Body:

         {
         "uninstallReason": "Test",
         "skipDeleteResources": true
          }

Default Monitoring Configurations

DNS response probe has default Global Device Management Policies, Global Templates, Global Monitors and Global Metrics in OpsRamp. You can customize these default monitoring configurations as per your business use cases by cloning respective Global Templates and Global Device Management Policies. OpsRamp recommends doing this activity before installing the application to avoid noise alerts and data.

1. Default Global Device Management Policies

   OpsRamp has a Global Device Management Policy for dns-response-probe. You can find those Device Management Policies at Setup > Resources > Device Management Policies, search with suggested names in global scope. Each Device Management Policy follows below naming convention:

   {appName nativeType - version}

   Ex: dns-response-probe DNS Host - 1 (i.e., appName = dns-response-probe, nativeType = DNS Host, version = 1)

2. Default Global Templates

   OpsRamp has a Global template for dns-response-probe. You can find those templates at Setup > Monitoring > Templates, search with suggested names in global scope. Each template follows below naming convention:

   {appName nativeType 'Template' - version}

   Ex: dns-response-probe DNS Host Template - 1 (i.e., appName = dns-response-probe, nativeType = DNS Host, version = 1)

3. Default Global Monitors

   OpsRamp has a Global Monitors for each Native Type which has monitoring support. You can find those monitors at Setup > Monitoring > Monitors, search with suggested names in global scope. Each Monitors follows below naming convention:

   {monitorKey appName nativeType - version}

   Ex: DNS Host Monitor dns-response-probe DNS Host 1 (i.e., monitorKey = DNS Host Monitor, appName = dell-power-scale, nativeType = DNS Host, version = 1)

Configure and Install the DNS Integration

1. From All Clients, select a client.
2. Go to Setup > Integrations and Apps.
3. The INSTALLED INTEGRATIONS page, where all the installed applications are displayed.
   Note: If there are no installed applications, it will navigate to the ADD APP page.

4. Click + ADD on the INSTALLED INTEGRATIONS page. The AVAILABLE INTEGRATIONS AND APPS page displays all the available applications along with the newly created application with the version.
   Note: You can even search for the application using the search option available. Also you can use the All Categories option to search.

5. Click ADD in the DNS response probe application.
6. In the Configurations page, click + ADD. The Add Configuration page appears.
7. Enter the below mentioned BASIC INFORMATION:

Note: Select the Notification Alert checkbox to be notified in case of Critical/Recovery failure alert for Connectivity, Authentication Exceptions.

8. Select the below mentioned Custom Attribute:

Note: The custom attribute that you add here will be assigned to all the resources that are created by the integration. You can add a maximum of five custom attributes (key and value pair).

9. In the RESOURCE TYPE section, select:
   • ALL: All the existing and future resources will be discovered.
   • SELECT: You can select one or multiple resources to be discovered.
10. In the DISCOVERY SCHEDULE section, select Recurrence Pattern to add one of the following patterns:
    • Minutes
    • Hourly
    • Daily
    • Weekly
    • Monthly
11. Click ADD.
    

Now the configuration is saved and displayed on the configurations page after you save it. From the same page, you may Edit and Remove the created configuration.

12. Click NEXT.
13. Below are the optional steps you can perform on the Installation page.

• Under the ADVANCED SETTINGS, Select the Bypass Resource Reconciliation option, if you wish to bypass resource reconciliation when encountering the same resources discovered by multiple applications.

  Note: If two different applications provide identical discovery attributes, two separate resources will be generated with those respective attributes from the individual discoveries.

• Click +ADD to create a new collector by providing a name or use the pre-populated name.

14. Select an existing registered profile.

15. Click FINISH.

The integration is now installed and displayed on the INSTALLED INTEGRATION page. Use the search field to find the installed application.

Modify the Configuration

• See Modify an Installed Integration or Application article.

  Note: Select the DNS response probe application.

View the DNS Details

The DNS integration is displayed in the Infrastructure > Resources > Endpoint. You can navigate to the Attributes tab to view the discovery details, and Metrics tab to view the metric details for DNS integration.

Note: By default, we provide A record metrics. You may also add additional metrics, apart from A records, by cloning the global template and using it.

Resource Filter Input Keys

DNS response probe resources are filtered and discovered based on few resource attributes.

Supported Alert Custom Macros

Customize the alert subject and description with below macros then it will generate alerts based on customisation. Supported macros keys:

Supported Metrics

Risks, Limitations & Assumptions

• Application can handle Critical/Recovery failure alert notifications for below cases when user enables Notification Alerts in configuration:
  • Connectivity Exception
• Application will send a critical alert for the very first poll when it encounters the above issues, and the subsequent alert will be a recovery alert whenever the application does not come across the above issues in subsequent polls.
• Application cannot control monitoring pause/resume actions based on the above alerts
• Platform has support to enable/disable configuration. So, when a particular notification is generated then the customer can act using UI/Commands.
• Encrypted Host Name is used as a signature (MoId). Hence, if a user modifies an already provided Host Name, the old resource will get deleted and a new resource will be created with an edited Host Name/Domain Name.
• Instead of giving additional configurations for SDK 1.0, can define ipv4 and ipv6 lookup details directly in configuration itself.
• No support of showing activity log and applied time.
• The minimum supported version for the option to get the latest snapshot metric is Nextgen-14.0.0.
• Application is not compatible with Cluster Gateway.
• This application supports both Classic Gateway and NextGen Gateway.