How to Create Devices and Targets

How it Works

DNS Server monitoring queries a specified DNS server in order to resolve a specific IP address.

Creating a Target

Host Name to Resolve

In this field, you can specify the URL you would like to resolve. The address should be formed exactly as you would use it in a browser such as www.example.com. Do not include “http://“.

DNS Server to Use

To query the particular DNS server, select the Custom radio button and enter the URL name, IPv4 or IPv6 address of the DNS server you wish to poll. By default, we use the a.root-servers.net root server. If you do not specify a custom DNS server, the letter.root-servers.net servers (where “letter” is a letter from A to M) will be polled in a random order.

Record Type

Select which NS record type to query.

NS Record Types Description

  • – IPv4 address record that maps a hostname to an IPv4 address.
  • AAAA – IPv6 address record that maps a hostname to an IPv6 address.
  • NS -name server record that delegates the authoritative name servers.
  • CNAME – canonical name record that is an alias to another name record.
  • SOA – start of authority record returns the most authoritative information regarding the domain, mail, and record timing information.
  • TXT – text record can be used for general information as well as Sender Policy Information or other machine-readable information.
  • MX  – mail exchange record defines the message transfer agents for the domain.
  • PTR – pointer record points to a canonical record for reverse DNS lookup.
  • SPF – Sender Policy Framework is a legacy record that is now generally handled in the TXT record.
  • SRV – specifies a port for specific services.
  • NAPTR – maps the Internet telephony address space to the Internet address space.

The record type only defines the content of the query, it does not automatically define what the expected response will look like. You must still explicitly define the expected response in the Expected Responses section based on your query. In addition, the Authority Resource Records and Additional Resource Records fields can also be used to validate the query response depending on the exact configuration.

 PTR reversed IP address

The PTR record type causes a reverse DNS lookup. If you want to query the PTR record type, Hostname to Resolve must contain a reversed IP address in the formats described below.

For IPv4:

If the IP address is 10.12.34.56

The expected response would be 56.34.12.10.in-addr.arpa

For IPv6:

A reverse DNS lookup uses the special domain “ip6.arpa.”:

5.4.3.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

where “5.4.3.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2” is a reversed IP address. 2001:0db8::1:2345 is the non-reversed original.

Recursion Desired 

Use this option to enable or disable the recursion desired (RD) flag in outgoing DNS queries:

  • NO – the DNS query will not send an RD flag. Use it if you would like to perform a single iteration to see if the selected DNS server resolves the target in one hop or not.
  • YES – Dotcom-Monitor will request that the DNS server performs recursion for the monitoring service (i.e., the remote server will scan a DNS tree for the monitoring service in search of a required result).

Most applications such as web browsers enable the RD flag by default so that they receive a successful DNS resolution even if the DNS server queried does not have a valid response. In this case the queried DNS server will contact a top-level DNS server and follow the resulting path until it has received an authoritative result.

Client applications (such as Internet browsers) typically use the RD flag.

Traversal Mode

Defines how a DNS responses with a required record type are interpreted:

  • Full Recursion – responses only from end-leaves of the DNS tree are verified for the expected response. NOTE that you will encounter more random failures from root servers timing out if you require a successful response from all root servers.  This does not necessarily indicate an outage, rather, it may indicate that one or more root servers are under a heavy load and did not respond in time.
  • Stop on the first positive answer – only the first found response with the specified record type is further analyzed. The first response with a required record type is considered the end of a DNS tree.
  • Single Query – the first received response from a single DNS query is verified for the expected response.

Protocol

By default, for DNS lookup we use UDP and automatically switch to TCP when a DNS packet size hits the UDP limit of 512 bytes. You can explicitly set what protocol must be used for DNS lookup by selecting the necessary one in the Protocol list.

Time Validation Threshold (in seconds)

Enter the number of seconds the task should wait for a response from the web page before ending the task and returning an error. If this is left blank the default timeout for a task is 120 seconds.

Ignore Timeouts From  (Servers Timeout Filter)

When querying multiple servers it is common to receive a timeout from one or more servers. This filter allows you to specify whether you want to ignore such timeouts or if you wish to receive alerts for these timeouts. Options include an alert on all timeouts, filtering out network and time-out errors from exact hosts, or a range of nodes based on a mask:

  • “*” – all network-related and timeout errors are included and will trigger alerts.
  • empty field – the engine ignores all network-related and timeout errors.

If a mask is added the engine ignores all network-related and timeout errors of the matching host or IP address.

Examples

IPv4: 192.168.* filters any address beginning with 192.168.

IPv6: 2001:501:* filters any address beginning with 2001:501:

url: len*a.ru filters any URL that begins with “len” and ends with “a.ru”

Multiple servers are divided by a semi-colon:
2001:501:* ; len*ra.ru

Expected Responses

Note that the Authority and Additional options are only applied when a custom DNS server is specified in the DNS Server field (not a ROOT server or an IP address).

Answer: If the returned string result includes the value entered in the expected answer field, the task returns a success. You can use logical expressions to define more complex results.

For example:

10.0.0.1 | 127.0.0.1 | 192.168.1.1

If any of the specified IP addresses occur in the returned string, then the query will be considered successful.

Authority: Parses the response to retrieve the value in the Authority section.

Additional: Shows additional resource records returned. If there are multiple DNS servers in the list this may return quite a few results.

Example of Complex Constructions

(answer[1].Name=tut.by | answer[2].Name=google.com) & !answer[1].Type=A & 'additional[2].Name=ns2.company.com' & key value | fftb

DNS Options

Determines which mode to utilize to resolve an NS address. For more details, see DNS Mode Option.

Error Filter

You can set a filter to ignore specific error types and codes. In the Error Filter section, you can filter out certain user-configurable errors. For example, DNS errors could be filtered out based on who is responsible for DNS server operations. You can create filters that will ignore specific errors that you know may occur and are not relevant to the goal of a specific device.

In addition, you can set up the system to ignore a range of error codes using a dash, or multiple error codes using semicolons as a separator.

For example, if on one particular device, you do not care about 404 errors, you can filter them out so that you do not receive alerts when they are detected.

Note that if an error matches the filter conditions, the error will not be reflected on the reports and can’t be tracked down.