| Option | Description |
|---|---|
| Always accept registrar changes to your tag | All requests for a registrar change to the tag are automatically accepted. |
| Only handshake if new customer, otherwise accept registrar changes to your tag | Requests for a registrar change on to an existing account on the tag (i.e. an account number is given as part of the tag change) are accepted automatically, all other requests result in a handshake. |
| Always handshake | All requests for a registrar change to the tag result in a handshake. |
| Always reject registrar changes to your tag | All requests for a registrar change to the tag are rejected. |
| Option | Description |
|---|---|
| Consolidate nameservers | Whenever a nameserver is referred to by name, our systems will look in the database to find an object that matches the name (and glue records if provided) and use this before creating a new object. The advantage of this setting is nameserver data replication will be avoided. It will be possible to modify a nameserver object and all domain names referring to it will be modified. |
| Don't consolidate nameservers | Whenever a nameserver is referred to by name, such as when creating a domain name or when there is a registrar change to the tag, a new nameserver object will be created in the database. Unless you refer to nameserver objects by identifier, new objects will always be created. This will result resulting in a one domain - one (or more) nameserver object system. |
| Option | Description |
|---|---|
| Maintain backwards compatibility | The Automaton will use the old field names in responses. |
| Use new field set | The Automaton will use the new field names in responses. |