Release notes for IRRD 4.5.0

IRRD 4.5.0 was released on January 30, 2026. Highlights of new features:

  • NRTMv4, a new IRR mirroring protocol with much improved reliability, security, and error detection over NRTMv3. NRTMv4 is now the recommended mirroring method for all uses.

  • Support for “dummification” of RPSL objects. This allows removal of certain attributes before they are exported or served through NRTM.

  • An endpoint for Prometheus metrics.

  • A new “RPSL updated” timestamp on sources that allows clearer monitoring.

  • Support for additional object classes.

NRTMv4

IRRD 4.5 adds support for NRTMv4, a new IRR mirroring protocol based on JSON-ish files over HTTPS. It is now the recommended method of mirroring to/from other databases. It is more reliable, secure, detects errors, has less opportunities for misconfiguration, and recovers automatically from loss of synchronisation.

A single IRRD instance can mix NRTMv3, NRTMv4 and authoritative databases, so gradual upgrades are possible. There are several new settings to enable NRTMv4. You will also need to be aware of key management. For all details, see the mirroring documentation.

IRRD 4.5.0 implements draft-ietf-grow-nrtm-v4-08 specifically. Future releases may use newer versions of this draft.

New irt and organisation object classes

The irt and organisation object classes were added. This means that in authoritative databases, users can now create these objects, and IRRD will include these objects when mirroring other sources. By default, support for these classes is enabled. To restore the old behaviour, you can use the sources.{name}.object_class_filter setting, which now also applies to authoritative databases. You can query the templates using the -t whois query or see all supported classes in the GraphQL schema.

New Prometheus metrics

A Prometheus-compatible metrics page was added to the HTTP server in IRRD, on /metrics/. This page is only accessible to IPs configured in the access list set in the server.http.status_access_list setting.

RPSL object text dummification for exports and NRTM

IRRD can now dummify RPSL object text in exports and NRTM, to remove sensitive or personal information. This is controlled by the new sources.{name}.nrtm_dummified_object_classes and sources.{name}.nrtm_dummified_attributes settings.

Dummification applies to exports, NRTMv3 responses, and NRTMv4. It does not apply to interactive query responses like whois or GraphQL. By default, dummification is disabled.

New “RPSL data updated” status timestamp

Various status overviews of IRRD would show a “last update” per source. While there are uses for this, many users checked this to ensure mirroring from a remote source was still active. However, that is not what this indicates: this timestamp updates for any internal change to database status, including any exports.

To cover the common use, a new timestamp was added for the last time the RPSL data for a source changed. This updates when objects are added, modified or deleted through any method, including a change in visibility due to object suppression status. Do note that some IRR registries have a low frequency of object changes, which will be visible in this timestamp.

Minimum Python version and PyPy

The minimum Python version for IRRd is now 3.10. Python 3.9 is end of life as of 31 October 2025 and therefore no longer supported.

Other changes

  • The RPSL update submission page, on /rpsl/update/, now also accepts inline PGP signed messages for mntner authentication.

  • The sources.{name}.object_class_filter setting can now also be used to restrict permitted changes to authoritative objects.

  • When a user submits an update to an authoritative object, which is identical to the current version, these changes are no longer saved. This means they do not create a journal entry. They are included in reports and notifications to the submitter and maintainers, with an info message. The last-modified field is ignored when determining if the object has changed, except when sources.{name}.authoritative_retain_last_modified is set for the source. Processing of other updates, such as those received from mirrors, is not affected.

  • Deletions submitted authoritative objects no longer have to meet all strict validation requirements. This makes it easier to delete objects created under a legacy IRRD that do not meet current validation requirements. Authentication requirements have not been changed.

  • The setting sources.{name}.authoritative_retain_last_modified was added to skip updating last-modified in authoritative databases, and retain the original value (if any) instead.

  • Authoritative creation or updating of route(6) objects for 0.0.0.0/0, 0.0.0.0/32, ::/0 and ::/128 is no longer allowed. Related, a bug was fixed where route(6) objects with prefix length zero could be incorrectly indexed and displayed in !g/!6/!a queries.

  • The sources.{name}.nrtm_query_serial_days_limit setting was added to limit the age of the oldest serial that can be requested over NRTMv3.

  • The irrd_update_database command now starts counting serials from the serial provided to a previous irrd_load_database.

  • The combination of readonly_standby and sources.{name}.export_destination has become explicitly invalid in the configuration.

  • The sources.{name}.authoritative_non_strict_mode_dangerous setting was added, to force an authoritative database into non-strict mode. As it’s name notes, this disables many checks and all referential integrity and is therefore strongly discouraged. However, some unusual setups for specific IRRD users benefit from this.

  • The sources.{name}.nrtm3_client_timeout setting was added, to handle situations where mirrors may be slow, busy, or sending many serial updates at once. The default for this is 15 seconds, updated from 5 in previous versions.

  • Most non-printable characters are now stripped from all RPSL attribute values.

  • The order in which authoritative sources are listed in the select field in the maintainer migration form now follows the order of the configuration file. Previously, this was alphabetically ordered.

  • The timeout for HTTP and FTP downloads for mirroring and RPKI is now configurable in the optional download_timeout setting.

  • A bug was fixed where the answer size in the A response was wrong when the response contained Unicode.

Upgrading to IRRd 4.5.0 from 4.4.x

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

The recommended steps to upgrade are:

  • Read the release notes above, particularly for any settings you may want to change.

  • Make sure your Python (minimum 3.10) version is recent enough.

  • Stop the IRRd process.

  • Upgrade the IRRd package. If using pipx, run pip install irrd==4.5.0. If using a manual virtualenv, from within the virtualenv, run: pip install irrd==4.5.0

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

  • Restart IRRd.

  • If you run an authoritative database, you are recommended to enable the NRTMv4 server. If you mirror from others, NRTMv4 is now recommended over NRTMv3 where available. See the mirroring documentation for details.

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.5 to 4.4.x

If you are running IRRd 4.5, and would like to downgrade back to 4.4.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.4.x:

irrd_database_downgrade --version 2353e60e63f8

Note that any NRTMv4 status will be lost.

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