Domain guardian

Note

This feature is part of the Pro plan. See plans.

A domain is rarely lost to an attack. It is lost because a renewal did not happen, a transfer lock stood open, or an auth code was issued and nobody noticed. Those four things are exactly what the domain guardian watches.

It comes in two parts: an overview across all domains and a protection tab per domain, where the rules are set.

The overview

Security → Domain guardian, direct address: dash.regfish.com/my/guardian

At the top are three cards: Domains guarded, noting that the drift watch checks daily for lock, renewal and auth-code changes, Domain at risk with the number of open auth codes underneath, and No guard rules active as long as no rule is set. Changes also arrive by mail.

Below that, Domains at risk lists the cases with date, state of the auto renewal and auth code status. A domain is at risk when it does not renew automatically or carries an issued auth code. A domain with auto renewal does not expire: its date in the Expiry / renewal column is the renewal date and shows in green. The guardian events underneath are the log: what happened when, for example that an auth code was issued.

The protection tab of a domain

Domains → your domain → Protection, direct address: dash.regfish.com/my/domains/<tld>/<sld>/guard

The three status cards show the current state:

• Expires or Renews on with the date and the days remaining. Green while auto renewal is on; without it the date takes its colour from how close the expiry is.
• Transfer lock. While it reads open, transfers are possible.
• AuthInfo. An issued auth code has a validity and is shown here with its deadline. As long as it is valid, the domain can be moved away with it.

Also here: certificate watch for exactly this domain, meaning the monitoring of the certificate transparency logs. It is covered in full under certificate watch.

Protection rules

Protection rules tie critical actions to a fresh confirmation with the second factor. Five points matter:

1. The approval lasts 5 minutes. After that the dash asks again.
2. API and DynDNS access is blocked for protected actions, not merely delayed. A script meant to run a protected action therefore fails until you exempt it explicitly below.
3. It does not work without account 2FA. The 2FA confirmation is the protection mechanism, so it has to be active for the account first. Until then the page shows the notice and a link to enable it instead of the rules.
4. The starting state is default (everything off). Protection only exists once you select actions.
5. Loosening four-eyes takes four eyes. Switching a rule from four-eyes to 2FA or off, or adding an exemption for an API key or DynDNS while doing so, requires the approval of a second person from the team, just like the protected action itself. Only when the account has no second login does your own 2FA confirmation suffice.

If you use the API in automation, plan for this: protection rules and API keys work against each other unless the action in question is exempted. That is deliberate, because a stolen key should not be able to move a domain.

The guardian log

Below the rules sits the log for this domain. Besides the action it names the person who triggered it and the source, so whether it came from the dash or through the API, and for an API access the key that was used. After an unexpected event this is the first place to look: it answers whether a change came from your own script.

A four-eyes approval leaves two lines: the decision, with the approving team member in front and the requester in the detail, and the execution by the requester, which in turn names who approved it. Who allowed whom to run a protected action can therefore always be traced from both sides.

The same log exists account-wide in the main menu under Security → Guardian log, next to the domain guardian and the certificate watch (dash.regfish.com/my/guard-log): every domain in one list, newest first, filterable by domain and outcome, with older entries loading on demand. Entries about the account itself, such as changed guard rules, appear there as “Account”. For a team this is the place that answers who triggered, confirmed or approved what and where.