New Relic Synthetics DNS resolver selection: limits of built-in DNS timing and certificate checks

Answer to the three core questions

1. Can I pick a custom DNS resolver for Ping or API checks?

• New Relic Synthetics runs each monitor in a lightweight Linux container that uses the host’s system resolver (the resolver configured in the container’s /etc/resolv.conf).
• There is no public API or UI setting that allows a Ping or API monitor to override this resolver with a custom server such as 8.8.8.8 or an internal split‑DNS IP.
• Consequently, the built‑in DNS timing metric always reflects the time taken by the container’s default resolver, not any resolver you might specify in your monitor code.

2. If I perform my own DNS lookup in a scripted monitor, does the built‑in DNS time still show the container’s resolver?

• Yes. The dns.time metric that Synthetics exposes is collected before the monitor’s script runs and is based solely on the container’s lookup.
• Any lookup you perform with dns.resolve() or a third‑party library is outside the scope of that metric; you would need to capture and report your own timing if you care about the custom resolver’s performance.

3. Does a connection failure skip the SSL certificate check, and how can I guarantee expiry alerts?

• If the monitor cannot establish a TLS handshake (e.g., the target port is closed or the host is unreachable), New Relic’s built‑in SSL validation step is bypassed. In that case, the monitor run will not trigger an expiry alert because the certificate was never retrieved.
• To ensure alerts fire even when the built‑in check is skipped, perform the TLS handshake yourself in the script, validate the certificate chain and expiry, and expose a custom metric (e.g., certExpiryDays) that New Relic can use for alerting.

Recommended approach for your scenario

1. Create a Node.js or JavaScript monitor (or any language supported by Synthetics that allows low‑level networking).
2. In the script, perform a DNS lookup against the resolver you care about:

   const dns = require('dns').promises;
   const start = Date.now();
   const addresses = await dns.resolve4('your-service.com', { server: '8.8.8.8' });
   const dnsTime = Date.now() - start;
   

3. Initiate a TLS connection to the resolved IP, collecting the certificate chain and expiry date:

   const tls = require('tls');
   const socket = tls.connect({ host: addresses[0], port: 443, rejectUnauthorized: true });
   socket.on('secureConnect', () => {
     const cert = socket.getPeerCertificate(true);
     const expiry = new Date(cert.valid_to).getTime();
     const now = Date.now();
     const daysLeft = Math.floor((expiry - now) / (24 * 60 * 60 * 1000));
     // Report custom metrics
     newrelic.recordCustomEvent('CertCheck', { daysLeft, dnsTime });
     socket.end();
   });
   socket.on('error', err => {
     // Handle connection errors; still report a metric so alerts can fire
     newrelic.recordCustomEvent('CertCheck', { daysLeft: -1, dnsTime, error: err.message });
   });
   

4. In New Relic, create an alert policy that watches the daysLeft custom attribute. This will fire even if the built‑in SSL check was skipped.
5. Optionally, expose the DNS timing metric you captured so you can monitor resolver performance in the same alert policy or in dashboards.

What you’ll need to confirm

• Verify that the container’s resolver is indeed the system resolver by inspecting /etc/resolv.conf from a test run.
• Confirm that the built‑in DNS metric does not change when you perform a custom lookup in the script.
• Test a scenario where the TLS handshake fails (e.g., point to a closed port) and ensure the custom daysLeft metric still appears.

Missing diagnostic detail

To fine‑tune the custom DNS lookup you’ll need the IP address of the internal split‑DNS server you want to target. Please provide that value or confirm the resolver you intend to use.