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.