From b611cd5e600d94ff52438aa2c48d47c0735d7f4a Mon Sep 17 00:00:00 2001 From: Sasha Romijn Date: Mon, 25 Mar 2024 10:52:40 +0100 Subject: [PATCH] Extend 4.5 draft release notes, other doc upd --- docs/releases/4.5.0.rst | 45 ++++++++++++++++++++++++++++++++++++-- docs/spelling_wordlist.txt | 1 + docs/users/mirroring.rst | 4 ++-- 3 files changed, 46 insertions(+), 4 deletions(-) diff --git a/docs/releases/4.5.0.rst b/docs/releases/4.5.0.rst index cfda9e6..9676f7f 100644 --- a/docs/releases/4.5.0.rst +++ b/docs/releases/4.5.0.rst @@ -1,7 +1,23 @@ ================================== -DRAFT Release notes for IRRd 4.5.0 +DRAFT Release notes for IRRD 4.5.0 ================================== +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 :doc:`mirroring documentation `. + +.. _NRTMv4: https://datatracker.ietf.org/doc/draft-ietf-grow-nrtm-v4/ + New irt and organisation object classes --------------------------------------- The `irt` and `organisation` object classes were added. This means that @@ -9,11 +25,36 @@ 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. +``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 :doc:`Prometheus-compatible metrics page ` +was added to the HTTP server in IRRD, on ``/metrics/``. +This page is only accessible to IPs :doc:`configured ` +in the access list set in the ``server.http.status_access_list`` setting. + Other changes ------------- * The ``sources.{name}.object_class_filter`` setting can now also be used to restrict permitted changes to authoritative objects. +* 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. +* Deleted 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 ``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`` + is 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. diff --git a/docs/spelling_wordlist.txt b/docs/spelling_wordlist.txt index 4499ff0..77e6ecc 100644 --- a/docs/spelling_wordlist.txt +++ b/docs/spelling_wordlist.txt @@ -40,6 +40,7 @@ logfile loglevel logrotate Miroslav +misconfiguration mnt mntner mntners diff --git a/docs/users/mirroring.rst b/docs/users/mirroring.rst index dfedef8..ded3524 100644 --- a/docs/users/mirroring.rst +++ b/docs/users/mirroring.rst @@ -79,7 +79,7 @@ though does not store the key in the configuration for you. You need to use a separate base URL and local path for each IRR source. -When running the NRTMv4 client process, IRRD will: +When running the NRTMv4 server process, IRRD will: * Check that all previous Snapshot and Delta files are still present. If a file is missing, the ongoing session is corrupt and will be reset. @@ -102,7 +102,7 @@ You need to serve the files written to ``nrtm4_server_local_path`` on be done using the same nginx instance used for other parts of IRRD, or through an entirely different web server or CDN, depending on your scalability needs. So in a way, the actual "serving" part of an -NRTMv4 server is not performed by IRRD, as it's just HTTPS. +NRTMv4 server is not performed by IRRD, as it's just static files over HTTPS. NRTMv4 has support for in-band key rotation. Use the following process: