What is an All Fail Record?
An All Fail record is the record that serves if all records with numbered priorities are in Status: Failure. (A record can be in failure either because of monitoring failing (when in Record State: Normal) or having been manually set to Force Fail in Record State.)
We recommend that all standalone pools (pools that are not solely subpools in some other SiteBacker or Traffic Controller pool) have All Fail records.
What are the consequences of not having an All Fail record?
If there is ever a point when no numbered priority records are serving, then any user that queries the authoritative server at that time will get NoError/No Answer SOA response, and it can be cached for as long the value of the parent domain's SOA record TTL or Minimum value (whichever is lower). (It can use the SiteBacker pool member TTL's because they are not serving. So their TTL is not visible.) So, for example, if you have a SOA TTL of 86400 and and a SOA Minimum of 43200, then even if the record is only down in for 5 minutes in the SiteBacker pool (and thus in authoritative DNS), recursive DNS (caching) servers may still show no answer for the hostname for up to 43,200 seconds. If you have an All Fail, then you avoid the possibility of negative caching and the prolonged outages that can accompany negative caching.
How do I add an All Fail record?
- From within a SiteBacker pool, click Add Record.
- Enter the IP address or hostname you wish users to go to under "Points To".
- Check "All Fail"
- Click "Save"
What should an all fail record be?
The most common configuration is to use the same Points To as the Priority 1 record. This is the most common setup. One reason to re-use Priority 1 is to protect against failure caused by a misconfigured probe or an issue specific to monitoring. If you have a special maintenance page that you would prefer users to go to, you can enter the IP address or hostname for that instead.
Does an All Fail count towards billing?
All Fail records do not count towards the number of SiteBacker or Traffic Controller records in the account.
Are there cases where one should not have an All Fail record?
Most SiteBacker and Traffic Controller pools are standalone pools that have "A" recors or CNAME's for pool members. However, SiteBacker and Traffic Controller can have subpools (other SiteBacker or Traffic Controller pools) as their pool members.
So for example you might have a pool with Max Active (or Max to LB) of 1 for a hostname which has US East subpool as priority 1 and a US West subpool as priority 2 and then an All Fail record of the first IP address from the US East pool. No customer directly goes to the US subpool's hostname; it just exists to give answers to the parent SiteBacker or Traffic Controller pool, which uses the hostname that customers connect to. US East has 3 IP addresses for numbered priority pool members and no All Fail. US West also has 3 IP addresses for numbered priority pool members and no All Fail.
That's a scenario where subpools do not need an All Fail because the parent pool has an All Fail. With this setup, when all IP addresses in the subpool fail, the parent pool sees the subpool as failed and will not serve from that subpool. With an All Fail in a subpool, the parent pool would never see the US East pool in failure and always at least be serving the All Fail record from that pool. That would block the ability to remove an entire subpool from service and have another subpool serve instead.
Whenever you have a SiteBacker or Traffic Controller pool that is a subpool of some other SiteBacker or Traffic Controller pool, then it makes sense to not have an All Fail record so that the parent pool can treat the subpool as failed.