[apnic-talk] [apnic-announce] Database Update - v2.2.1 - completed
[Note "reply-to:" field]
Dear Members,
The upgrade to release 2.2.1 of the RIPE Whois Database, scheduled for
today has been completed successfully. Should you encounter any problems
with this new version please notify apnic-dbm at apnic dot net.
Regards,
Paul Gampe.
--------------------------------------------------------------------------
Dear Members,
APNIC will be upgrading to release 2.2.1 of the RIPE Whois Database,
during the February 6th maintenance window between 8:00 - 12:00 UTC+10.
Included for your reference are the release notes describing the changes
that are introduced with this version.
We will be delaying the introduction of support for PGP authentication for
a few weeks while we explore alternative licensing scenarios. Another
announcement will be made when PGP authentication is to be made available.
Regards,
Paul Gampe.
RELEASE NOTES for RIPE Database 2.2.1
This is a bugfix release with a very little new functionality
added. There are some operational changes which should be
transparent to the end user but ease the database
maintenance.
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
Domain name queries
-------------------
The behaviour of domain name queries has been changed. When a
domain object cannot be found in the database, the search
string is stripped towards higher level domains (xxx.yyy.zzz
-> yyy.zzz) and the lookup is repeated until a domain object
is found or the search string becomes empty. If a domain
object with stripped domain name exists in the database and
it does not contain a referral attribute the server response
is "No entries found ..." and reflects the fact that the
domain name originally queried doesn't exist. This is
opposite to the behaviour of the previous software version
which in this situation returned the higher level domain
object if there was one.
Referral mechanism
------------------
When referral is made the originally queried domain name is
passed to the authoritative server instead of the domain name
of the object containing the actual referral.
If while doing an inverse query the referral mechanism is
activated and the referred server is of type RIPE, the -r
flag is passed to it and the -i flag is not passed. This
means that the authoritative server's domain object is
displayed instead of the local copy in an inverse query
response when applicable.
The new configuration variable REFERRALENDTXT contains text
to be displayed as an end of referred query reponse marker.
It is useful for inverse queries when the referred query
response can be intermixed with local server responses.
A limit for length of referred query response has been
implemented, configurable via REFERRALMAXLINES variable. The
goal was to prevent badly behaved remote servers from
flooding the local server with a huge amount of data. When a
referred query response gets truncated a warning message is
displayed. Message text is the value of the REFERRALTRUNCTXT
configuration variable.
MAINTENANCE RELATED CHANGES
Timeout for reading from remote server for referred queries
implemented.
Timing added to processing of overflow index files. If
processing of overflow file takes more than 5 second, its
time is logged to audit log.
Timing of queries implemented. Time info written to query
log.
Messages about lock contention and time spent waiting for a
lock added to audit log.
Mechanism for disabling integrity checks implemented. It is
needed in some pathological cases involving legacy data.
Warnings are still generated though.
Debugging printout facility added. It is activated with -b
flag and is now separate from verbose output (-V).
BUG FIXES
PGP error "This signature applies to another message" is now
catched properly.
There were performance problems related to file locking and
opening of multiple databases at the same time. These have
been fixed.
Syntax checks error messages clarified for admin-c, tech-c,
zone-c and author attributes.
Previously it was possible to create top level domain automatically
(hierarchical authorisation didn't work in this case). It is not possible
any more - requests for top level domain creation are refused now.
Previously domain creation was refused due to hierarchical authorisation
procedure when there was no higher level domain object found.
It is fixed now.
AUTO1 (actually AUTO\d*) is not treated as a valid nic handle
any more. It is a reserved word.
Previously when a delete request was sent with a missing source
attribute it caused dbupdate process to return with an error
code and a bounce sent to update originator. It is corrected
now.
Previously it was not possible to add a nic handle attribute to an
existing person object without a nic handle. Such an update
was interpreted as the creation of a new person object which
led to a situation when two essentially identical person
objects exist in the database. This behaviour has been fixed.
Now, it is possible to add a nic-handle attribute to an
existing person object.
Previously it was not possible to update the values of changed attribute
only. An attempt to do so resulted in NOOP error. This is corrected now
and changed attribute values are now taken into account when comparing
objects.
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-<id> where <id> 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-<id>".
- 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 name queries 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: <type> <host> <port>
where
<type> is one of RIPE, InterNIC or SIMPLE, indicating which
style of whois service is provided.
<host> is the DNS name of the whois service.
<port> 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, 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 another person object with the same name in the
database and warning is issued if 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 or 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.
* APNIC-ANNOUNCE: Announcements concerning APNIC *
* To unsubscribe, send "unsubscribe" to apnic-announce-request at apnic dot net *
* APNIC-TALK: General APNIC Discussion List *
* To unsubscribe: send "unsubscribe" to apnic-talk-request at apnic dot net *