<Error ErrorId="SIG_INVALID" Hint="INVALID_REQUEST_ERROR" Severity="err"> <Description><![CDATA[Signature is invalid]]></Description> </Error>
SIG_INVALID errors are generated when SRS is unable to validate the GPG signature you sent with your transaction.
This issue can be caused by a number of situations including:
<Error ErrorId="LOCK_ERROR" Hint="UNKNOWN_ERROR_HINT" Severity="err"> <Description><![CDATA[An error occured when attempting to gain a lock on the domain.]]></Description> </Error>
This is normally the result of duplicate or multiple transactions for the same domain being sent with different action ids in very quick succession (i.e. within the same second).
The lock error is the result of the second transaction at our front-end failing to gain a lock on the records which are already being processed by the first transaction.
<Error ErrorId="INSECURE_UPDATE" Hint="INVALID_REQUEST_ERROR" Severity="err"> <Description><![CDATA[Transaction requires a secure communication channel]]></Description> </Error>
This error is generated when you request non-public data via HTTP instead of HTTPS. Non-public data (data that cannot be retrieved using the public WHOIS system) must use an encrypted HTTP connection (HTTPS) for data security. Only the Whois request may be issued over an unencrypted HTTP connection.
If you don't supply the field it does not update the field (as you would expect). For blanking out (clear a field) you need to send empty fields if using XML, or NULL if using the SRSClient.
For example to blank out the fax, the XML input should be:
We recommended to use the GnuPG tool to generate a key (http://www.gnupg.org/).
Make sure all the following commands are executed as the user that will be running the command line client, or any of the SRS::Client modules.
To generate a key, type:
Follow the instructions the the gpg application gives you:
You can create a passphrase if you prefer one. If the key is generated with a passphrase the passphrase needs to be provided as environment variable (see below for more details)
Once the key is generated, you can export it by typing:
gpg --export --armour <username>
Username is either the 'Real Name', 'Email Address' or both, that you entered for the key (type: 'gpg --list-keys' to view usernames for your keys). This is also the name you need to pass to the command line client, or the SRS::Client modules. (However, the most recently added secret key is your default secret key, and will be used if you don't specify a username).
The export command will print the armoured key to STOUT. If it's more convenient, you can redirect this to a file:
gpg --export --armour <username> > pub.key
If you are using the RIK command line clients (SendXML or SRSClient) or you want to verify the signatures sent with responses by the registry, then you must import the registy's public key to your keyring. To do this, type:
gpg --import reg.key
The registry's public key is included in a file (reg.key) in the top level directory of the Technical RIK.
You will have to specify the path to the key file if you're executing 'gpg' in a directory other than the one containing the key file.
The minimum PGP Key size we allow is 1024 bits and NZRS recommend that a key of at least 2048 bits is used.
If you have more than one key in your GPG keyring it may be necesary to specify which GPG identity should be used. Depending on how you are using the RIK there are a number of different ways this can be done:
In all cases you should specify the real-name of the GPG id, not the fingerprint
If you use a key with a passphrase:
The passphrase needs to be specified in an environment variable SRS_RIK_PASSPHRASE. Or a environment variable SRS_RIK_PASSPHRASE_FILE points to a file containing the passphrase.
We have supported multiple GPG keys in SRS since February 2008.
We have had at least one example where registrars have encountered poor performance from the SRS RIK clients as the result of low entropy on machines with low activity.
It is up to the registrars to decide how to handle it. Either use a hardware random number generator or evaluate a software entropy daemon such as haveged <http://www.issihosts.com/haveged/> to determine if it meets your security requirements.