RELEASE NOTES for RIPE Database 2.2 SUPPORTED SYSTEMS This release has been tested with perl 5.004_04 on bsdi3.1 and Solaris 2.6 systems. Please let us know if you have problems running it on other systems. NEW FEATURES PGP authentication support -------------------------- Support for authentication with PGP signatures has been added. The following modifications are related to this: - A new object "key-cert" has been introduced to allow supplying and storing of PGP public keys on the server. - A new attribute type "generated" has been added to support automatically generated fields of the "key-cert" object. Attributes of this type are ignored in the user input and replaced by the server. - A new possible value for the "auth" attribute of "mntner" object: PGPKEY- where is the PGP key ID to be used for authentication. This string is also the primary key of the "key-cert" object database. - Messages with PGP encoded parts are passed to PGP process for analysis in the first steps of dbupdate which handles incoming update messages. Results of this examination are used later if the object to be updated is protected with a maintainer with "auth: PGPKEY-". - A new script "pgpdata2ring" is installed in the tools directory. It can be used to convert existing key-cert object database to a simple file with all the ASCII-armored PGP keys in it. It can be used to re-create the server's PGP key ring from the key-cert database if the ring gets corrupted or when boot-strapping the system from existing key-cert database. - Three new configuration verbs have been added: PGPV the full name of PGP 5.0 pgpv binary PGPK the full name of PGP 5.0 pgpk binary PGPPATH the directory where the server's key rings are stored Please note that the software probably only works with PGP 5.0[i]. The implementation is not very clean because there is currently no clean way to communicate with the PGP process. Please don't even try with older versions. If you don't want to have PGP support enabled, just comment these lines out. - A new directory is created in the installation process: "$INSTALLDIR/.pgp". This is the same directory which is specified with PGPPATH in the configuration. Please also notice the following implementation details: - The server keeps two copies of the PGP keys. One copy is in the "key-cert" object database and the other is in PGP's key ring. Copies in the key ring are actually used for verifying signatures. - Mirrors of the database which are being updated with syncdb, blindly trust their masters -- they don't do any PGP authentication checks but they still update the local PGP key ring by starting PGP process every time when "key-cert" object is modified. - Multiple PGP-encoded or non-encoded parts can be supplied in a single update message; each part gets processed separately. So, you can supply several objects which are protected by different PGP keys in a single update message, but you cannot use any "magic" references like AUTO-1 nic-handles between these parts. - PGP encoded parts with an invalid signature are dropped in all cases, even if the object is not protected by PGP authentication. - PGP encoded parts can be supplied in cleartext and non-cleartext modes as long as ASCII armoring is used. - RPSL line continuation is not supported, so multiple lines in the "certif" attribute of "key-cert" object must be specified by prepending "certif:" to every line of the ASCII armored PGP key. For other details please see: draft-ietf-rps-dbsec-pgp-authent-00.txt or its successor in the usual internet-drafts repositories. Referral mechanism for domains ------------------------------ Referral mechanism has been implemented to provide redirection of domain namequeries to appropriate database server when RIPE database doesn't contain authoritative answer for given domain. Following change has been made to processing of query for domain objects: when domain object with name equal to query's search string is not found in the database domain name is stripped towards higher level domains (xxx.yyy.zzz -> yyy.zzz) and lookup is repeated until a domain object is found or search string becomes empty. Only when the top level domain zzz is not present in the database the "No entries found ..." answer is given. When a domain object is finally found the proper referral mechanism comes to work. If found domain object does _not_ contain referral it is displayed as a query result just as it was in the prevoius software version. When the referral is present a whois query is made to referred (aka authoritative) host and its answer is displayed preceded by a note that this data doesn't come from the RIPE database but from a authoritative server. Local object is not displayed in that case. When a query to a referred host fails an error message is given and the local object is not displayed. There is a simple mechanism to prevent referral loops. Locally present domain object containing referral can only be shown when specifically requested by using new -R option to whois client. Referral mechanism is implemented via new domain object's attribute "refer" which is single and optional: refer: where is one of RIPE, InterNIC or SIMPLE, indicating which style of whois service is provided. is the DNS name of the whois service. is the TCP port number (optional: 43 is the default). New configuration variables were added: REFERRALTXT - text printed as a header when displaying results of referred query from authoritative server REFERRALERRORTXT - error message printed when whois connection to remote server failed REFERRALLOOPERRORTXT - erro message printed when referral loop detected REFERRALTIMEOUTTXT - value of referral timeout in seconds Referential integrity checks ---------------------------- New checks are implemented when doing creation/modification of objects referencing other objects and when deleting objects being referenced by other objects. While creating or modifying object which has references to other objects in its admin-c, tech-c, zone-c, cross-nfy, mnt-by, cross-mnt, or origin attributes it is checked whether referenced objects exist in the database. Update is refused if reference to nonexisting object is found. While deleting person, role, maintainer or aut-num object reverse lookup is performed to find objects possibly referencing the object being deleted. If there are any objects found referencing object in question then delete operation is refused and error message is displayed stating the number and types of objects referencing object being deleted. Only RIPE database is checked for references now - other sources (RADB etc) are not searched. New syntax checks ----------------- admin-c, tech-c and zone-c attributes and author attributes must now have a valid nic handle as a value. Date in changed field is now automatically converted to long 8 digit format. Status attribute is now mandatory in inetnum objects. Valid values are: ASSIGNED PI ASSIGNED PA ALLOCATED PI ALLOCATED PA UNSPECIFIED Other checks ------------ While creating person object a check is performed whether there exist(s) another person object with the same name in the database and warning is issued when it does. It is also checked if contact data in both objects are identical - address, phone and fax fields are compared after compressing whitespace and uppercasing strings. Behaviour of this check is configurable via new configuration variable DUPLICATEPERSONCHECK. When it is not defined the whole check is not performed. When it is defined and not equal to "strict" then both name comparison and contact data comparison is done and only warnings are issued. When value of DUPLICATEPERSONCHECK is "strict" and there is a person object in the database with the same name _and_ contact data as the one being created then the creation operation is refused. Changed attribute behaviour changed back ---------------------------------------- Changed attribute is now shown by default in query result. For backward compatibility the -c flag is accepted and quietly ignored. There is no way to suppress output of changed lines now. Improved parsing of subject line keywords ----------------------------------------- The code for parsing subject line keywords has been fully rewritten. Keywords will trigger options ONLY if there arey are alone in subject line, i.e. no non-keyword words are found. Otherwise, *whole* subject line will be ignored and a warning message will be issued. The following keywords are recognized: NEW make sure the object does not exist HELP send help text HOWTO send help text ASSIGN (*) make sure the inetnum does not exist LONGACK (**) send long acknowledgment (*) ASSIGN is now obsolete. This functionality has been dropped, since a general NEW keyword exists. If ASSIGN is found in subject line, it will be ignored and a warning message will be issued. (**) LONGACK is now the default behaviour of the database, so the keyword is silently ignored. In addition, to prevent ambiguity when multiple keywords are specified, a list of allowed combinations of keywords has been defined. If the combination of recognized keywords is not one of: ASSIGN NEW LONGACK NEW HELP HOWTO *whole* subject line will be ignored and a warning message will be issued. BUG FIXES Y2K fixes --------- All the dates generated by the software are now in Y2K compliant YYYYMMDD format. This also includes the log files, so when upgrading the software please also update your log-rotating support scripts or whatever to reflect this change. Six digit dates supplied by the user in the "changed" and "withdrawn" attributes are always first converted to 8 digit format. Date comparison has been fixed to correctly compare two dates when one is in 6 digit format and another is in 8 digit format. This bug made it previously impossible to use 6 digit dates in the "changed" attribute any more if there was already one such attribute with date specified with 8 digits. Generally, all years specified with two digits are handled in the following way: nn >= 70 becomes 19nn nn < 70 becomes 20nn Portability fixes ----------------- Non-portable ioctl() call in the server setup has been replaced with more appropriate POSIX::setsid(). MISC Whois access list ----------------- The mechanism has been implemented to block whois queries from hosts known for their abusive, copyright violating behaviour. A note explaining why access has been blocked is displayed instead of a query result. It is implemented via a new configuration variable DENYWHOISACCESS which can have a regular expression as a value. It is matched against the IP address of the querying host. New newdb program ----------------- An upgraded newdb program is provided to facilitate creation of empty database and index files. Its usage is described in greater detail in the INSTALL file. New whois client ---------------- New whois client program understands the -R option used to suppress referral mechanism.