DNS Monitoring

DNS

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 10.0 and above.

• Ensure that “adapter integrations” add-on is enabled in client configuration.
  Once enabled you can see DNS Response Probe integration under Setup » Integrations » Adapter section

Install the integration

1. From All Clients, select a client.

2. Go to Setup > Integrations > Integrations.

3. From Available Integrations, select Adapter > DNS Response Probe. The Install DNS Response Probe Integration popup appears.
   Note: Ensure that Adapter addon is enabled at client and partner levels.

4. Enter the following information:
   a. Name: Name of the integration
   b. Upload Logo: Optional logo for the integration.
   c. GateWay Profiles: Select a gateway management profile to associate with the client.
   

5. Click Install. The Integration page displays the installed integration.

Configure the integration

1. In CONFIGURATION section, click + Add.

2. On Create Adapter Configuration, enter:

   • Name: Configuration name.
   • Host Name / Domain Name: Host Name or Domain Name.
   • DNS Server: Default DNS Server / Specific DNS Server to resolve your domain.
   • Port: Default is 53
   • Protocol: Default is UDP. Select accordingly based on your environment.
   • DNS Class Type: Select IN or CH.
   • Number of Retries: Default count is 3.
     Number of retries to establish a connection with the server, upon a failure.
   • TimeOut (sec): Default timeout value is 5.
   • Notification Alerts: Select TRUE or FALSE.
     Notes:
     • By default FALSE is selected.
     • If you select TRUE, application will handle Critical/Recovery failure alert notifications for Connectivity, Authentication Exceptions.
   • Additional Configuration: You can provide the IP address. The default json format string is provided for reverse lookup. If you do not wish to provide any reverse lookup, then provide an empty value in the data string.

3. In the Resource Types & Metrics section, select the metrics you want and configure for availability and alert conditions.

4. In the Discovery Schedule section, select Recurrence Pattern to add one of the following patterns:

   • Minutes
   • Hourly
   • Daily
   • Weekly
   • Monthly
     
     

5. In the Monitoring Schedule section, configure how frequently the monitoring action should trigger.

7. Click Save.

After saving the integration, the resource (resource type is Endpoint) is discovered and monitoring is enabled as specified in the configuration profile.

The configuration is saved and displayed on the page.

You can perform the actions manually, like Discovery, Monitoring or even Disable the configuration.

The discovered endpoints are displayed in the Infrastructure page under Endpoint, with Native Resource Type as DNS Host.

The Custom attributes are displayed based on the record types existing in your domain/host:

The graphs are displayed accordingly:

Note: Only the metrics that are existing in your domain/host are displayed.

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 applicaton 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 take action using UI/Commands.
• Encrypted Domain Name is used as a signature(MoId). Hence, if a user modifies an already provided Domain Name, the old resource will get deleted and a new resource will be created with an edited Domain Name.
• In additional configurations, the given input data should be a valid json data string.

• Component level threshold configuration is not possible.
• Resource level metric threshold customization and frequency setting are not possible.
• Usability issues in application configuration page while adding/editing.
• Optional configuration parameters cannot be defined.
• Application upgrade is a manual process without version change.