Dear colleagues,
After we removed inactive MD5 passwords from maintainers, most of these
objects have no auth attributes.
This is why tomorrow we plan to add the remark "Use Forgot Maintainer
Password to recover access to this object, see
https://apps.db.ripe.net/db-web-ui/fmp" to maintainers with no
authentication attributes (approximately 9k).
Please let us know if anyone does not agree with this update.
Best Regards
Miguel
RIPE NCC
Dear colleagues,
We are pleased to inform that starting this week, RIPE NCC members can use OAuth 2.0 to authenticate applications that interact with the RIPE Database.
Please refer to this article for further information :
https://labs.ripe.net/author/adonis_stergiopoulos/oauth-20-available-for-th…
Please let us know if you have any questions regarding this.
Regards
Mahesh Aggarwal
RIPE NCC
Dear colleagues,
At RIPE90 I presented a proposal to deprecate the RIPE-NONAUTH database:
https://ripe90.ripe.net/wp-content/uploads/presentations/120-RIPE90-DB-WG-O… (slide 20)
The objects in the RIPE-NONAUTH database are not authoritative, and were created anonymously with a well-known password as out-of-region data in the RIPE IRR database. We don’t know who created this data or whether it is still valid. There are very few (< 100) updates per year, which suggests the data is not being maintained. The RIPE-NONAUTH database has only reduced in size by about 10% since it was created in 2018. The existing cleanup jobs and maintainers are not deleting much data.
Ruediger Volk pointed out that ARIN had only very recently introduced their NONAUTH database, so it was a very short-term temporary source, and that does not predict anything about the longstanding data that has been split out into RIPE-NONAUTH. He suggested that the RIPE NCC analyse whether something that’s supposed to go away is still being used, or else there is a pretty big danger that someone is actually depending on it.
I now present some analysis of the RIPE-NONAUTH database for review. Perhaps we should not retire the RIPE-NONAUTH database completely as we don't know how it is being used, but we could take action to further reduce its size. Your feedback is appreciated.
Should RIPE-NONAUTH Objects Be Returned By Default?
---------------------------------------------------
The RIPE-NONAUTH database is included by default in Whois queries.
This means that any matching object in the RIPE-NONAUTH database is automatically returned in the Whois query response. That includes as-set, aut-num, route and route6 object types. For example, when querying for "AS2561", the matching aut-num object in the RIPE-NONAUTH database is returned.
Additionally, *related* matching objects in the RIPE-NONAUTH database will also be returned by default. For example, when querying for the IPv4 prefix "200.30.0.0/18", the related route object "200.30.0.0/18AS5511" in the RIPE-NONAUTH database is returned.
We found that RIPE-NONAUTH objects are returned only in a small number of cases (about 0.006% of all queries), but there is a risk that clients will inadvertently trust non-authoritative data if the "source:" attribute is not checked. As a workaround, clients can use the "-s RIPE" flag to only query the RIPE database.
Should objects in the RIPE-NONAUTH database continue to be returned by default?
Near Realtime Mirroring (NRTM)
------------------------------
Approximately 20% of NRTM requests query for updates to the NONAUTH database.
Should we continue to support mirroring the NONAUTH database, considering the non-authoritative nature of the data and low rate of updates?
Should RIPE-NONAUTH objects with an exact match in another RIR database be deleted?
-----------------------------------------------------------------------------------
Approximately 31,930 out of 45,754 route(6) objects in the RIPE-NONAUTH database have a matching route(6) object (i.e. matching origin ASN and exactly matching or less-specific prefix) in another RIR’s IRR database.
Approximately 13 out of 67 as-set objects in the RIPE-NONAUTH database have an exactly matching as-set in another RIR’s database.
Approximately 1,840 out of 2,073 aut-num objects in the RIPE-NONAUTH database have an exactly matching aut-num object in another RIR’s database.
Should we delete RIPE-NONAUTH objects which duplicate identically named objects in an authoritative RIR’s database?
Should unrouted RIPE-NONAUTH route(6) objects be deleted?
---------------------------------------------------------
Approximately 33,912 out of 44,647 RIPE-NONAUTH route(6) objects appear in the global routing table (as of 12th July).
Should we remove any NONAUTH route(6) objects which are not announced? Do they serve any useful purpose?
Regards
Ed Shryane
RIPE NCC
Hi Ed and DB-WG,
I just noticed that the RIPE DB RDAP interface returns a 500 error
when querying for ENUM domains[1] (except for specifically the top
level e164.arpa domain, which results in a 400 error).
This seems to be due to an assumption that all domains in the RIPE DB
are reverse DNS domains for IP addresses, which is not the case as
ENUM domains are also in there.
Is this an intentional decision or was this just an oversight?
If it was just an oversight, consider this a bug report. :)
If it was an intentional decision then I would be interested in
hearing what the reasoning was.
[1]: Example: https://rdap.db.ripe.net/domain/6.4.e164.arpa
-Cynthia
Dear colleagues,
RIPE Database release 1.118.1 has been released to the PRODUCTION environment.
Unfortunately a regression was found in the 1.118 release that was causing some route(6) object queries and updates via the REST API to fail:
https://github.com/RIPE-NCC/whois/pull/1843
We have now deployed a fix for this regression, with no other changes from the 1.118 release.
We did not wait for the usual 2 week testing period in the RC environment because this was an unintentional change and was impacting some of our users.
The exact changes are available in the source repository:
https://github.com/RIPE-NCC/whois/compare/505c5f7a...whois_1118_1_release?e…
The release notes are on the website:
https://docs.db.ripe.net/Release-Notes#ripe-database-release-1-118-1
We apologise for the inconvenience and thanks to the users for reporting this issue.
Regards
Ed Shryane
RIPE NCC
