We have improved our options for synthetic network testing by supporting different protocols for basic network tests (Ping tests). In addition to ICMP, we have expanded the options to test TCP and UDP connectivity between Synthetics private agents or between agents and any target.

As a part of this feature, we have added the ability to start the TCP or UDP listener on our Synthetics private agents which acts as an “echo service”:

• Specify one or more TCP ports to listen and respond to TCP connections
• Specify one UDP port to listen and respond to UDP packets as an echo service

Please note that UDP protocol is susceptible to spoofing attacks, therefore running this service is recommended only within private networks and with the appropriate access control to the open UDP ports by using network access lists or firewall rules.

Additionally, the network connectivity test configuration is extended with the following testing methods/protocols:

• TCP: Based on the TCP Syn packet sent to a configurable port and expecting the TCP Syn+Ack packet response from the target IP.
• UDP-ICMP: Based on the UDP packet sent to a configurable port and expecting ICMP Port unreachable received from the target IP.
• UDP-ECHO: Based on the UDP packet sent to a configurable port and expecting the UDP packet response from the target IP.

Our customers have requested a feature to mute the alarms and notifications for Synthetic tests during their maintenance windows or other activities on their network. Alert Suppression is now available under the Alerting and Notifications section inside the Test Settings.

Users can specify the start and end time of their silence/maintenance window and will not be alerted during the selected period.

The DNS Server monitor tests are improved with the additional Health check Allowed DNS Results. This field allows the user to configure the list of expected values, which depend on the selected DNS Record Type:

• If the DNS Record Type is “A” or “AAAA”, this field allows the user to configure the list of IP addresses that are considered “healthy” for the resolved IP address of the testing DNS query. If the DNS Server monitor test query resolves to multiple IP addresses, they should all be part of the configured list. If the resolved IP addresses are not in the allowed list, the test Health will be set to Critical.
• If the DNS Record Type is “CNAME*”,* the field allows the user to specify a comma-separated list of canonical name records that are considered "healthy”.
• If the DNS Record Type is “NS”, the field allows the user to specify a comma-separated list of server names that are considered "healthy”.

The following screenshot shows the Allowed DNS Results field in the DNS Server monitor configuration.

The Kentik Synthetics HTTP/API and Web Page Load tests now support checking of the HTTP Response Headers to determine the Health condition of the test.

The user can configure one or more expected Response Headers:

• If the Value is omitted, then any value will be considered valid
• Value can be specified as a regular expression
• Value can be specified as a comma-separated list of possible valid values

If the configured headers exist in the response, but are not equal to the expected values, or do not exist in the Response at all, the test health will be set to Critical.

The screenshot below demonstrates the example configuration of this feature.

DNS was designed in the 1980s when the Internet was much smaller, and security was not a primary consideration in its design. As a result, when a recursive resolver sends a query to an authoritative name server, the resolver has no way to verify the authenticity of the response. DNSSEC was designed to address this issue.

DNSSEC adds two important features to the DNS protocol:

• Data origin authentication allows a resolver to cryptographically verify that the data it received actually came from the zone where it believes the data originated.
• Data integrity protection allows the resolver to know that the data hasn't been modified in transit since it was originally signed by the zone owner with the zone's private key.

Up until today, the DNS Server Monitor Test only allowed a user to monitor the DNS resolution for a given hostname from specified Name Servers. Users can be alerted if the resolution time crosses a particular threshold or if an unexpected DNS response code is received, or a non-allowed IP is answered.
However, these tests previously did not validate the DNSSEC trust chain of the received record.
Enter DNSSEC Validation.

How can you configure DNSSEC validation?

When enabled for a given domain, the test will recursively check the validity of each signing entity in the chain from the authoritative name server up to the root server. The result will be either a positive or a negative response. The DNSSEC record is either fully verified or it isn’t.

When the option is active, the test results will show the DNSSEC validation status for each one of the Agents involved in the test.

Validity of DNSSEC is based on querying DS and DNSKEY for any of the successive parts of the domain name: for a DNS test target of subdomain.domain.tld, each of tld., domain.tld., subdomain.domain.tld. and . (root) will be tested.

Traces for the DNSSEC validation for each agent will be available by clicking on their respective status icon on the previous screengrab.

DNSSEC validation impact on subtest health

Health options remain the same as the DNS Server Monitor test. DNSSEC validation will have a boolean result. If validation is successful it’s a healthy result, if not, it's critical. 

If enough agents have a critical results (see screenshot above) to meet the sub-test threshold condition, an alert will be triggered.

IMPORTANT NOTE: App Agents vs Network Agents

Be advised that setting DNSSEC validation is available to all agents except Private Network Agents. As a reminder, our new Private App Agents not only include all of the capabilities of the legacy Network Agents, but also include the capabilities required for advanced Web tests such as Page Load Tests and Transaction Tests.

If you currently run our legacy Network Agents, please consider replacing them with our new App Agents to gain access to all of the feature we will add in the future. Kentik's entire fleet of Network Agents has already been migrated, and support for the Network Agents will be phased out in 2023 (more to come on this soon)

As of now, users can set their own DSCP values in any Synthetic Monitoring Network test.

What's new?

While Network Tests initially defaulted to Diffserv codepoint "0: Best Effort" for every Network test, they can now be set to any value, allowing our users to more realistically test the behavior of their own network and test along all classes of services they implement.

To see it in action, edit or create any IP Hostname Network test: in the Advanced Options, both Ping and Traceroute aspects of it can be set to different DSCPs.

IMPORTANT NOTE: App Agents vs Network Agents

Be advised that setting DSCP values for the aforementioned tests is available to all agents except Private Network Agents. As a reminder, our new Private App Agents not only include all of the capabilities of the legacy Network Agents, but also include the capabilities required for advanced Web tests such as Page Load Tests and Transaction Tests.

If you currently run our legacy Network Agents, please consider replacing them with our new App Agents to gain access to all of the feature we will add in the future. Kentik's entire fleet of Network Agents has already been migrated, and support for the Network Agents will be phased out in 2023 (more to come on this soon)

BGP Monitor tests in Kentik Synthetic Monitoring came out including tests for the following elements:

• Reachability: % of BGP Vantage Point threshold to determine whether prefixes are visible “enough” through the public internet
• Allowed Origin: whether detected originators are part of an allowed-list (manually specified, or via RPKI) - this is commonly referred to as “Origin Hijack Monitoring”

The health of a BGP Monitor test was then the worse of these two tests, across all prefixes registered in the test, with the specificity that “Allowed Origin” could only be healthy or critical.

The “Allowed ASNs” test has now been renamed “Origin Hijack detection” to match what the industry is calling it.

Additionally, we have added “Upstream Leak Detection” - here’s the practical use for it:

In a normal situation, you only want your Upstream IP Transit Providers to announce your prefixes to the rest of the world: under no circumstance do you usually want your peers to announce your prefixes to the rest of the world as if they were your transit provider. They should keep these routes to themselves, and only use them to go from their network to yours (announcing them to their peers will break that partition).

Enters #4 step of the updated BGP Monitor test where you can now enter the ASNs of your “official” Upstream Transit Providers and we will inspect the 1st hop in the AS Path of all announcements of these prefixes (and of their more specific children).

Remember that with all BGP Announcements collected from the BGP Vantage Points, come an AS_PATH that gives the following information:

<vantage_point_ASN> …. various ASNs … <UPSTREAM_ASN> <Origin_ASN(yours)>

If the <UPSTREAM_ASN> is not part of your allowed list of Transit Providers for any of the prefixes (and their more specifics), the entire BGP Monitor test will be flagged as critical for “Upstream Leak”.

For further reference, the diagram below details Origin Hijack vs Upstream Leak

The Incident Log has been enhanced with some powerful new features.

The log now supports a time series stacked bar chart displaying the volume of alerts by alert severity. This enables users to quickly identify alerting trends over time.

The log also supports many new filtering options that allow the log and the stacked bar chart to be filtered by alert severity, alert status, test name, test type, label and agent (private/global).

When one or more filters are selected an indicator displays the total number of filters currently enabled along with the time range selection.

The selection is also persistent, so navigating away from this page will not cause the selection to be lost.

Finally, we will be collapsing the Performance Dashboard menu item into the Synthetics title itself. 

Clicking on "Synthetics >" will bring you to the (soon to be) newly named "Synthetics Dashboard"

Ensuring that DNS is healthy and working as expected is fundamental to the performance and availability of any network service.

Kentik's DNS Server Monitor and DNS Server Grid tests already allow users to monitor and alert on the DNS Resolution Time - an important metric to track to ensure that no delays are introduced at this step of the interaction.

We've now enhanced these tests with the ability to monitor and alert on the IP mappings returned by the DNS servers being queried. By specifying an allowed list of IP addresses we can alert when an unexpected mapping is returned.

The Allowed DNS Results field under Advanced Options allows users to specify the expected IP results. If the test returns an IP that isn't in this allowed list the test health will be marked as Critical and an alert is triggered based on the alert activation settings.

Websites and web applications rely on SSL certificates to demonstrate their authenticity to end users connecting to them. 

Whether the web application is one the customer owns themselves or one that they consume as a service from a service provider if the server certificate attached to the application expires or is invalid, users will not be able to connect to them securely. It is therefore important to monitor the health of these certificates and alert when one is about to expire or is no longer valid.

With the TLS Certificate Expiry Check feature we have introduced a new column in the Results page of HTTP(S) and Page Load tests displaying the server certificate’s expiry status and we've expanded test Health options to alert when the certificate is about to expire.

When the target website's certificate is valid we will display the expiry date of the server certificate as seen below.

When the certificate is invalid (or expired) we will display an error message indicating the cause of the failure.

Health options now includes the option to alert the user when the certificate is nearing expiry to prevent site outages due to invalid certs.

If the website's certificate is within the specified threshold the Certificate Expiry column values will be colored accordingly.

To disable all certificate checks, enable the "Ignore TLS Errors" switch under Advanced Options > General Options. This will remove the "Certificate Expiry" column in the test results page.