Monitoring
Monitoring allows DNS records to be hidden if the underlying server goes offline. Records are automatically restored once the server is back online.
While many (but not all) network clients will automatically retry multiple hosts, this often takes several seconds. Hiding the IPs helps to avoid these delays and to ensure visitors are directed to online servers.
Start by configuring one or more monitoring definitions at Routing -> Monitors -> Add Monitor.
Name: a name for this monitor
URI: URI indicating monitoring type, IP, etc (examples below)
Hostname: The usual hostname for the monitored server/service. Required for HTTP & HTTPS servers; optional for others.
; Configured monitors:
Name: Website .11
URI : https://192.0.2.11/
Hostname: www.your-domain.com
Name: Website .22
URI : https://192.0.2.22/
Hostname: www.your-domain.com
Note that URI must always contain the IP address (IPv4 or IPv6), not a hostname. If you have multiple servers/IPs for the same service, create separate monitors for each of them. This is so DNScaster can correctly assess the online status for each server/IP individually.
If you have multiple services on a single server (or set of servers), you only need to monitor each server once. Multiple host records can point to the same monitor.
Next, assign your monitors to host records.
; Configured hosts:
www.your-domain.com A 192.0.2.11 Monitor=Website .11
www.your-domain.com A 192.0.2.22 Monitor=Website .22
As long as both servers are online, clients will receive both A records. If either server goes offline, that record will be hidden but the other record will remain.
Hint: To establish a primary + backup/secondary relationship instead of serving all records, see Secondary records.
In order to avoid false outages due to a monitoring failure, if both servers go offline, all records will be returned.
HTTP
Basic auth, port, and path are all allowed.
By default, the target URI must return HTTP status 200-399 to be considered online. 400-599 will be considered offline. To also consider 3xx redirects as offline, set Treat 3xx Redirects to offline.
URIs:
http://192.0.2.1/
http://192.0.2.1:81/
http://192.0.2.1/health/check
http://user:password@192.0.2.1/
http://[2001:db8::2:1]/
Hint: It may be necessary to escape non-URL-safe characters in usernames, passwords, etc.
HTTPS
HTTPS targets are just like HTTP, but with https://. Self-signed certificates are valid because we’re only assessing if the server is online.
Ping
URIs:
ping://192.0.2.1
ping://[2001:db8::1]
TCP
TCP monitors just verify that the port is able to receive connections. Port is required.
URIs:
tcp://192.0.2.1:55555
tcp://[2001:db8::1]:44444
Monitoring intervals
Monitoring checks are executed about once a minute.
Comparison to monitoring at other providers
Some providers monitor your servers from every nameserver or each region. This can cause substantial load against your servers. It can also cause each nameserver to have a different opinion on whether your servers are online or offline. Typically there is no visibility to the online status apart from the returned (or not returned) DNS records themselves.
In contrast, DNScaster maintains a single view of the online status and only requires a limited number of healthchecks to each server. If a server goes offline, that status is propagated to all nameservers. Likewise, when online again, all nameservers will be notified in parallel. The DNScaster management portal also reports the current state of each active monitor.
Comparison to uptime monitoring services
DNScaster’s monitoring is solely for temporarily hiding DNS records pointing to offline servers. It is not a full featured monitoring service.