Changelogs » Irrd

PyUp Safety actively tracks 334,184 Python packages for vulnerabilities and notifies you when to upgrade.











First beta of 4.2.0


IRRd now cleanly terminates startup, if the whois or HTTP workers are unable to start, e.g. due to a missing database. See f378a67bd7f1b3bdcd5715ede9ebe2494e3d3cb2 and 451 for details. Systemd example also updated in docs.


This is the first alpha release of IRRd 4.2:








  Note that upgrading to 4.1.3 or newer is strongly recommended for all 4.1.x users.
  (This release was re-published a second time on GitHub due to a tag change. This only affected published documentation and not the source code. 4.1.4 was actually released on June 18th.)


Upgrading strongly urged for all 4.1.x users. See







Fix 394 - Fix handling of last-modified in irrd_database_update (395)
  **CAUTION: if you are upgrading from a 4.1 version prior to rc3, also read the rc3 release notes**

  4.1.0rc3 contains a new database migration, so you must run irrd_database_upgrade before starting IRRd.
  **CAUTION: if you have been running any 4.1 pre-release, you may need to forcibly reload certain sources.**
  This is required for sources where both of the following apply:
  * You mirror over NRTM from another source.
  * The source had RPKI and/or the scopefilter enabled at some point in time since the last full reload, but do not currently have it enabled, either because you later disabled RPKI or the scopefilter, or set rpki_excluded or scopefilter_excluded for the source.
  **These sources must be reloaded after upgrading to 4.1.0rc3, using the irrd_mirror_force_reload command. Failure due to so can lead to mysterious mirroring failures and missing data, which may or may not result in logged errors.**
  This issue does not apply:
  * for upgrades from IRRd 4.0.x to 4.1.0rc3
  * if you have never enabled RPKI and/or the scopefilter
  * if RPKI and/or the scopefilter has been enabled in the past, and is still enabled for the same sources


Fixes 369 through 371


**This rc1 release has a new database migration, so you have to run irrd_database_upgrade even if you were running beta 4 already.**
  Unless any issues are found, this is planned to be the 4.1 release.
  * Convert whois handling to use long-running workers (and reduced max_connections default to 10 to reduce default memory use)
  * Add scope filter (4)
  * Add better handling of exports when serials are unknown (356)
  * Add !J command and modified !j command (339, 322)
  * Add last-modified attribute to authoritative objects (290)
  * Add support for custom logging configs (299)
  * Only log NRTM RPKI status for relevant objects when RPKI is enabled
  * Add support for database downgrades and docs in 4.1 release notes (333)
  * Consistently log query time in same number of decimals.
  * Read RPSL files iteratively, reducing IRRd memory usage. (342)
  * End RIPE-style whois responses with two empty lines. (335)
  * Ignore trailing slash in status page URL (336)
  * Add note about maxmemory Redis setting to docs. (323)

  - Fix 271 - Add synthethic NRTM. (325)
  - Ref 323 - Ensure correct error logging in preload updates
  - Enable SO_REUSEADDR on TCP sockets.
  - Fix 320 - Fix Python 2.6 compatibility (327)

  Ref 302 - Fix issue where SLURM prefixFilters could apply to prefixAssertions
  Ref 306 - Fix issue with binding to IPv6 addresses.
  Add note about roa_import timer being in seconds
  Fix 311 - Fix issue with multiline primary keys
  Fix 312 - Add support for NRTM over IPv6
  Dependency updates (313)
  * Update ordered-set from 3.1.1 to 4.0.1
  * Update redis from 3.4.1 to 3.5.0




IRRd 4.0.8 was released on November 12th, 2019.
  It adds two minor features[1]:
  * An `` EOF`` marker is added to the end of all exports.
  * Ordering in exports is now consistent between exports.


IRRd 4.0.7 was released on October 3rd, 2019.
  It fixes an issue where export permissions were not set correctly[1].
  In 4.0.7, the files saved to `sources.{name}.export_destination`
  always have their permissions set to 644.


IRRd 4.0.6 was released on September 5th, 2019.
  In 4.0.5, a performance issue was introduced while fixing
  an issue where some queries
  did not correctly filter for the selected sources[1].
  The performance issue is resolved in 4.0.6.


number change in 4.0.5, which could cause confusion
  on which version was running.
  In earlier versions of IRRd, queries that looked up
  the routes originating from a certain AS,
  did not correctly filter for the selected sources[1].
  Also, the `!s-lc` query did not always correctly display
  which sources were currently selected.


two bugs.


This version fixes an issue in the release notes of 4.0.4. Otherwise, it is identical.


one change relating to the behaviour of `changed:`
  attributes in RPSL objects.
  In earlier versions of IRRd, format of the `changed`
  attribute was entirely free. In IRRd 4.0.4, the format
  is expected to be ``<email> [YYYYMMDD]`` with an optional
  comment, as allowed with other RPSL attributes. The date
  is optional. Regardless of the date, if any, set in the
  attribute, it will be overwritten by today’s date[1],
  unless the override password was used. Pre-existing
  `changed` attributes are not affected.


one change relating to referential integrity validation
  between RPSL objects.
  In earlier versions of IRRd, the `members` attribute of
  an `as-set`, along with several others,
  were strongly validated[1]. This meant it was not possible
  to add or update an `as-set`, if some of the members were
  not valid objects in the same source. The same applied
  to fields like `member-of` in a `route-set`.
  In IRRd 4.0.3, all references from `members`, `mp-member`,
  `mbrs-by-ref` and `member-of` are weak references. Their
  syntax is validated, e.g. for `as-set` members, values must
  be a valid `as-set` name or a valid AS number. However, there
  is no validation on whether the objects actually exist.
  It is also possible to delete e.g. a `route-set`, even when
  the object is still listed in the `member-of` in a `route`
  object, or to reference a maintainer that does not exist
  in a `mbrs-by-ref`.