Hi,
When attempting to update an in-addr.arpa object today, I repeatedly get:
Unexpected error: please retry later
Did not happen yesterday. Is it just me or everyone?
Regards,
Hank
Dear colleagues,
RIPE Database release 1.121 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Wednesday 4th March.
Whois release 1.121 contains the following changes :
* Removed support for MD5 passwords in mntner and IRT object types
* NWI-21: Added "reg-nr:" attribute to the organisation object type
* Run GRS mirror imports after dump is updated, not all at midnight
* Fix RDAP publicIds array
* Return top-level IANA allocation or redirect RDAP domain queries
The full list of changes is visible in the source repository:
https://github.com/RIPE-NCC/whois/compare/6db089c3...94ed67c2
More information on the Release Candidate environment can be found on our website:
https://apps.db.ripe.net/docs/Release-Notes/
The data in the Release Candidate environment is a dummified copy of production from 16th February.
Please let us know if you find any issues with this release in the RC environment.
Regards
Ed Shryane
RIPE NCC
Dear colleagues,
On 4th March along with the Whois 1.121 release to production, we also plan to remove MD5 hashed passwords from all IRT objects. This has already been done for all MNTNER objects in January.
On 14th January, we informed 171 affected IRT maintainers that we will remove all passwords from IRT objects following the next Whois release, and also notified the DB-WG:
https://mailman.ripe.net/archives/list/db-wg@ripe.net/message/WQWBPPB2AMTVI…
We plan to email the remaining 135 affected IRT maintainers today to remind them of the plan and announce the specific date. We have asked the maintainers to switch to an alternative authentication method, including X.509, PGP or SSO.
MD5 hashed passwords in IRT objects are used to authenticate adding an mnt-irt: reference to IRT objects in inet(6)num objects. This has only been done a handful of times this year, so we expect the impact to be low.
Please let us know if you have any questions or comments on this plan.
Regards
Ed Shryane
RIPE NCC
Dear colleagues,
This message summarises recent discussion regarding ENUM (e164.arpa) and
clarifies the scope and next steps.
The RIPE NCC has operated the e164.arpa registry for many years under
instructions and coordination arrangements established with the ITU-T and
IAB. These arrangements, and the operational context for how the registry
is run, are described here:
https://www.ripe.net/manage-ips-and-asns/dns/enum/iab-instructions/
Recently, a request was raised in the RIPE Database Working Group to
support ENUM (e164.arpa) in RDAP for querying the RIPE Database. We noted
that RDAP support for ENUM is not currently implemented, but could be added
if there is clear interest. We also checked current query patterns and
found a few hundred ENUM-related queries per day in DNS and in Database; so
low usage, but not zero.
Following discussion on the Database WG mailing list, including replies in
support, we proposed implementing RDAP support for ENUM. While this is a
limited operational change, it was recognised that anything touching E.164
and e164.arpa can raise political questions that go beyond the purely
technical.
As e164.arpa is directly linked to the ITU E.164 numbering system, the
relevant points of contact are typically national administrations and the
entities they designate. This led us to consult ITU-T Study Group 2 to
clarify the status of ENUM and its usage and needs for ongoing support.
ITU-T will ask member states for their feedback and share this with us.
ITU-T provides an established and coordinated channel to reach those
administrations, and importantly confirm whether any delegating authorities
still rely on the service, so our technical decisions are informed by
real-world use and help us avoid unnecessary operational risk, confusion,
or compliance headaches (including in the context of regulatory frameworks
such as NIS2).
We are also reaching out to the IAB regarding these operations, which the
RIPE NCC performs under its instruction on behalf of the global DNS and
Internet community.
I am sharing this message with the DNS, Database, Cooperation and RIPE NCC
Services Working Group mailing lists to ensure all relevant working groups
are informed. If you wish to share thoughts in response, please reply to
the thread on the RIPE NCC Services WG mailing list.
Best regards,
Hisham Ibrahim
Chief Community Officer,
RIPE NCC
