Release notes for IRRd 4.4.0

IRRD 4.4.0 was released on September 28, 2023. Highlights of new features:

  • A new web interface offering internal authentication for improved flexibility, security and user-friendliness.

  • A new method for running standby instances, mainly for authoritative databases.

  • Protection of previously used mntner, person and role names, and an option to delete such objects with override.

  • Source aliases that can be used in queries.

  • Preloading of set members, improving performance for all queries that include as-set and route-set resolving.

Minimum Python version and PyPy

The minimum Python version for IRRd is now 3.8. Python 3.7 is end of life as of 27 June 2023 and therefore no longer supported.

IRRD no longer supports PyPy. While it offered some performance benefit, it kept causing numerous complex issues. If you were running on PyPy, switch your environment to CPython, the commonly used Python interpreter.

IRRD internal authentication

IRRD 4.4 contains a new web interface (on /ui/) that allows users to migrate their authoritative maintainers to an IRRD internal authentication method. This allows removal of hashes from RPSL mntner objects and much more granular access control.

The new web interface also offers more secure alternatives to email submissions and override access, independent of whether you choose to allow maintainer migrations.

You can allow maintainer migrations with the auth.irrd_internal_migration_enabled setting. By default, this is disabled. Even with migration disabled, users can use the object submission interface to submit in the same format as email, by including the password or override pseudo-attributes.

For full details and benefits, see the web interface and internal authentication documentation

This new feature adds one new required setting: server.http.url, which must be the external URL on which users will reach the IRRD instance, used for WebAuthn second factor authentication. This must match the URL as seen from the browser’s perspective, and changing it will invalidate all WebAuthn tokens.

New recommendations on availability and replication

Historically, operators have used different methods for synchronising an active instance of IRRD with a standby, or doing migrations. Some of these had issues around serial synchronisation, object suppression, or update frequency.

There is now one recommended method for synchronisation between IRRD 4 instances, and new documentation on availability with PostgreSQL replication including specific required PostgreSQL settings.

The database_readonly setting was removed, in favour of a new readonly_standby setting. These settings are similar but have some differences, and this is an intentional breaking change as you will need specific PostgreSQL configuration for this to work correctly.

If you use any kind of availability/standby setup, you should review this documentation and switch to the new recommended setup.

Note that, although most of the work is done by PostgreSQL, IRRD 4.4 does have new internal handling to support this replication method. This means you can not apply these instructions in IRRD prior to 4.4.

The sources.{name}.export_destination_unfiltered and sources.{name}.nrtm_access_list_unfiltered settings are deprecated and will be removed in IRRD 4.5.

Protected names

There is new special handling of names of mntner, person and role objects, as these often contain personal data and/or have authentication consequences. See the protected names documentation for details. This only affects authoritative databases.

Source aliases

Operators can now configure source aliases. A source alias can be used in queries, and translates to a specific set of regular sources configured in the same IRRD instance. These are configured under the source_aliases setting. Returned objects are not modified - the alias relates only to the query. The database status under the !J whois and the databaseStatus GraphQL queries is extended with alias information.

Preloading of set members

Members of as-set and route-set are now preloaded by IRRD. This improves performance for the !a and !i whois queries, and the asSetPrefixes and recursiveSetMembers GraphQL queries. This can make set member resolving about 2-10x faster.

Memory use for whois and HTTP workers has increased by about 30-40 MB per worker due to this change.

This also fixes an issue where set members included through mbrs-by-ref / member-of did not have the correct source filter applied. This meant that members could be included in a set, even through the aut-num, route or route6 object were from a different IRR source.

Other changes

  • The !e whois command was added to exclude sets from recursive resolving. This was already possible in GraphQL queries.

  • The -q whois flag was added to query available serial ranges in a RIPE format.

  • The override password in auth.override_password can now also be set with a bcrypt hash. Salted MD5 is also still supported, but discouraged and may be removed in the future.

  • The sources.{name}.nrtm_response_header setting was added, to add an additional response header comment to all NRTM responses, configured per source.

  • A compatibility.asdot_queries setting was added, which allows the use of the (long deprecated) asdot format in origin queries.

  • The deployment documentation now also suggests pipx for installing IRRD, which can be easier than managing the virtualenv manually.

Upgrading to IRRd 4.4.0 from 4.3.x

As with any other major IRRd release, depending on the availability needs of your setup, it is recommended to first test the upgrade and operation on a testing/acceptance setup with similar data size.

The recommended steps to upgrade are:

  • If you are running any standby servers, read the new availability with PostgreSQL replication carefully. Standby servers using NRTM are no longer supported.

  • Make sure your Python (minimum 3.8) version is recent enough. If you were using PyPy, switch to CPython.

  • Update your settings file with server.http.url.

  • Stop the IRRd process.

  • Upgrade the IRRd package from within the virtualenv with pip install irrd==4.4.0

  • Run the database migrations, using the irrd_database_upgrade command. The migrations create only new tables, and should be fairly quick.

  • Restart IRRd.

  • If you run an authoritative database, consider enabling internal authentication migration with auth.irrd_internal_migration_enabled

It should be safe to keep cron and e-mail triggered tasks active during the upgrade, but during installation, tasks may fail. To prevent this, disable these during the upgrade.

Downgrading from 4.4 to 4.3.x

If you are running IRRd 4.4, and would like to downgrade back to 4.3.x, the database schema needs to be modified. You can either restore an older copy of your database, start with a fresh database, or use the database migrations.

If you want to use the database migrations, run this command before downgrading your local package installation to 4.3.x:

irrd_database_downgrade --version fd4473bc1a10

Note that any internal authentication data will be lost by this database downgrade.

If you would like to re-upgrade to 4.4 later on, you will need to run the database migrations again, as listed in the upgrade steps.