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
On 28/02/2025 10:20, Hank Nussbacher wrote:
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
I should note that even though I get the error messages of: Update of domain failed, please see below for more details Unexpected error: please retry later the update did go through and was updated! Weird. -Hank
Good morning Hank,
On 28 Feb 2025, at 09:23, Hank Nussbacher <hank@interall.co.il> wrote:
On 28/02/2025 10:20, Hank Nussbacher wrote:
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?
If this happened around 04:41 - 05:01 UTC it may have been related to this incident with one of our loadbalancers : https://manage.statuspage.io/pages/wbqx0dgqy4n6/incidents#incidents
Regards,
Hank
I should note that even though I get the error messages of:
Update of domain failed, please see below for more details
Unexpected error: please retry later
the update did go through and was updated! Weird.
I will investigate how this happened. Regards Ed Shryane RIPE NCC
Hi Hank, Colleagues,
On 28 Feb 2025, at 09:23, Hank Nussbacher <hank@interall.co.il> wrote:
... I should note that even though I get the error messages of:
Update of domain failed, please see below for more details
Unexpected error: please retry later
I investigated further. The "Unexpected error: please retry later" message is generated by the DB web application, not by Whois. The DB web application calls Whois to perform the update with a 1 minute request timeout. I found that twice when you updated a domain object around 08:15 UTC, Whois took just over a minute each time to respond. For domain object updates, Whois calls the Zonemaster DNS check service (https://zonemaster.ripe.net/), which can take some time. I propose that we fix this by making the request timeout longer in the DB web application (say 5 minutes).
the update did go through and was updated! Weird.
The Whois update request still succeeded because the DB application gives up after a minute, but the Whois update will continue even if the client HTTP request is interrupted (closed). Thanks Hank for reporting this issue. Regards Ed Shryane RIPE NCC
When one logs in to the RIPE portal, one can easily see a tab for 3 different resources (My Resources tab): IPv4, IPv6 and ASN But how does one see all the inverse domains that are "owned" by that LIR? I guess I am not seeing it. Thanks, Hank
On 11 Mar 2026, at 07:04, Hank Nussbacher <hank@interall.co.il> wrote:
When one logs in to the RIPE portal, one can easily see a tab for 3 different resources (My Resources tab): IPv4, IPv6 and ASN But how does one see all the inverse domains that are "owned" by that LIR?
With 'inverse domains', do you mean the in-addr.arpa & ip6.arpa reverse delegations per prefix? You will have to go to: My Resources -> IPv4 / IPv6 Tab there per prefix below it "allocated PA" or similar, then the name of the prefix and a green "tag" with IRR or "rDNS" indicating that rDNS is set for it. Click on the prefix, and at the bottom you will have "Domain" and the delegated in-addr.arpa or ip6.arpa domain along with Manage to do something with it, though effectively updating the whois/RPSL object (and supports DNSSEC :) ). I do not think there is currently a "list of all domain objects related to LIR" view in the webui. If you know the typical owner of the objects, one could do a whois inverse search: whois -h whois.ripe.net -- -r -i admin-c,tech-c YOUR1-RIPE -T domain whois -h whois.ripe.net -- -r -i mnt-by YOUR-MNT -T domain You could also search through: https://ftp.ripe.net/ripe/dbase/split/ripe.db.domain.gz Or for automated way use the API: https://www.ripe.net/publications/documentation/developer-documentation/lir-... this will only show you the objects for that LIR account, which might be the most accurate if you have a lot of objects. Depending on what you are looking for, maybe old/outdated domain objects, I would take the list of prefixes (eg quickly from bgp.tools below), reverse them and match them with domains in the above gzip file, that would be the quickest route. I wonder if, especially on an older/long-standing LIR if one can find prefixes with domain objects that are not directly connected using the LIR portal API though, time can cause differences after all :) Btw, the amazing BGP Tools has a view for at least the IPv4/IPv6/ASN resources: https://bgp.tools/rir-owner/tld.lirname Though that does not cover reverses. Regards, Jeroen
Hola all, Hanks message did make me think about something: Why do RPSL objects not have a LIR identifier so that one can easily whois an object and see to which LIR it belongs to; as then a reverse search could be done on the LIR ID. We do have the 'org' and related 'organisation' objects but these do not directly map to a LIR. Thus have a 'lir-id' in the 'organisation' object would be very helpful too. Thus maybe, the better version is to always have an organisation object bound to each object and then a LIR linked to that? Thus something like: domain: 8.b.d.0.1.0.0.2.ip6.arpa descr: Example Reverse with LIR-ID nl.example admin-c: EXAMPLE1-RIPE tech-c: EXAMPLE1-RIPE zone-c: EXAMPLE1-RIPE nserver: ns1.example.net nserver: ns2.example.net ds-rdata: 44553 13 2 57a47aeb9e448adaef8b7d178e7b4bdc648b6663626a7f5f4fc4caef2e8bdb4f mnt-by: EXAMPLE1-MNT lir-id: nl.example created: 2021-07-04T22:41:34Z last-modified: 2024-07-05T09:47:38Z source: RIPE Note the 'lir-id' line added. And yes, for some historical/old data it might be tricky to add this, but for most objects it would be know what LIR an object belongs to. This would also make it clear which LIR is responsible for that object, especially useful in cases of connectivity issues or abuse; yes, abuse-c should exist; but that only helps if somebody answers..... at least now one can group objects to the same LIR easily, though of course mapping to ASN helps, an ASN can be under a different LIR. I would not be surprised that something like this was discussed when the 'organisation' object was introduced, but could not easily find something in $searchengine. Regards, Jeroen
Dear Jeroen,
On 11 Mar 2026, at 09:44, Jeroen Massar via db-wg <db-wg@ripe.net> wrote:
Hola all,
Hanks message did make me think about something:
Why do RPSL objects not have a LIR identifier so that one can easily whois an object and see to which LIR it belongs to; as then a reverse search could be done on the LIR ID.
The Reg ID is intended as an internal identifier between the RIPE NCC and the LIR, not for a RIPE Database user to identify an LIR organisation. An LIR can find both their own Reg ID and Org ID on the Account Details page in the LIR Portal.
We do have the 'org' and related 'organisation' objects but these do not directly map to a LIR.
The unique identifier of any organisation in the RIPE database is the organisation: attribute in the organisation object type, and the org-type: identifies the organisation as an LIR (or OTHER). A reverse search can be done on org: references to that organisation object. Also, we will also shortly introduce the Registration Number ("reg-nr:") attribute to uniquely identify an organisation (see NWI-21).
Thus have a 'lir-id' in the 'organisation' object would be very helpful too. Thus maybe, the better version is to always have an organisation object bound to each object and then a LIR linked to that?
Thus something like:
domain: 8.b.d.0.1.0.0.2.ip6.arpa descr: Example Reverse with LIR-ID nl.example admin-c: EXAMPLE1-RIPE tech-c: EXAMPLE1-RIPE zone-c: EXAMPLE1-RIPE nserver: ns1.example.net nserver: ns2.example.net ds-rdata: 44553 13 2 57a47aeb9e448adaef8b7d178e7b4bdc648b6663626a7f5f4fc4caef2e8bdb4f mnt-by: EXAMPLE1-MNT lir-id: nl.example created: 2021-07-04T22:41:34Z last-modified: 2024-07-05T09:47:38Z source: RIPE
Note the 'lir-id' line added.
And yes, for some historical/old data it might be tricky to add this, but for most objects it would be know what LIR an object belongs to.
This would also make it clear which LIR is responsible for that object, especially useful in cases of connectivity issues or abuse; yes, abuse-c should exist; but that only helps if somebody answers..... at least now one can group objects to the same LIR easily, though of course mapping to ASN helps, an ASN can be under a different LIR.
I would not be surprised that something like this was discussed when the 'organisation' object was introduced, but could not easily find something in $searchengine.
I also didn't find any discussion to publish the Reg ID in the RIPE database in the archive: https://mailman.ripe.net/archives/list/db-wg@ripe.net/ Does the working group see value in adding the Reg ID as an additional identifier of LIR organisations to the RIPE database? Regards Ed Shryane RIPE NCC
On 13 Mar 2026, at 13:04, Edward Shryane <eshryane@ripe.net> wrote:
Dear Jeroen,
On 11 Mar 2026, at 09:44, Jeroen Massar via db-wg <db-wg@ripe.net> wrote:
Hola all,
Hanks message did make me think about something:
Why do RPSL objects not have a LIR identifier so that one can easily whois an object and see to which LIR it belongs to; as then a reverse search could be done on the LIR ID.
The Reg ID is intended as an internal identifier between the RIPE NCC and the LIR, not for a RIPE Database user to identify an LIR organisation.
An LIR can find both their own Reg ID and Org ID on the Account Details page in the LIR Portal.
They are also listed on the website: https://www.ripe.net/membership/member-support/list-of-members/nl/surf/ => nl.surf https://www.ripe.net/membership/member-support/list-of-members/ch/massar/ => ch.massar https://www.ripe.net/membership/member-support/list-of-members/nl/ripencc-cs... => nl.ripencc-cs https://www.ripe.net/membership/member-support/list-of-members/nl/ripencc-op... => nl.ripencc-ops https://www.ripe.net/membership/member-support/list-of-members/nl/ripencc-ts... => nl.ripencc-ts https://www.ripe.net/membership/member-support/list-of-members/nl/coloclue/ => nl.coloclue etc. Thus these are publically exposed. And for instance bgp.tools gives a handy overview: https://bgp.tools/rir-owner/ch.massar https://bgp.tools/rir-owner/nl.coloclue if there are objects related to it. (No clue what Benjojo's magic there is, but it is handy ;) )
We do have the 'org' and related 'organisation' objects but these do not directly map to a LIR.
The unique identifier of any organisation in the RIPE database is the organisation: attribute in the organisation object type, and the org-type: identifies the organisation as an LIR (or OTHER).
But the "organisation" object does not map directly to LIR. Thus maybe the correct place is just in the organisation object. Though, it depends on the purpose of why we would add it; knowing which LIR an object exists for would be a good thing, and I do not think all objects have an org reference either, though inetnum/inet6num & amt-num likely yes, thus adding it to organisation would help a lot already to normalize that.
A reverse search can be done on org: references to that organisation object.
Also, we will also shortly introduce the Registration Number ("reg-nr:") attribute to uniquely identify an organisation (see NWI-21).
But that maps to company, not to the LIR ID. [..]
I would not be surprised that something like this was discussed when the 'organisation' object was introduced, but could not easily find something in $searchengine.
I also didn't find any discussion to publish the Reg ID in the RIPE database in the archive: https://mailman.ripe.net/archives/list/db-wg@ripe.net/
https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/77NQDFTMHLIOLEH... as per link from https://www.ripe.net/about-us/news/ripe-ncc-member-update-november-2025/
Does the working group see value in adding the Reg ID as an additional identifier of LIR organisations to the RIPE database?
Personally I would say yes, it would definitely help in research into what belongs to what and finding patterns there and possibly finding a better contact for a problem; similar reasoning to the reg-nr. But, it will be a bit of an effort possibly for the RIPE NCC team adding the feature and validating that the information is correct. Thus a discussion, which is why I asked it in a separate thread, would be a good thing indeed ;) Regards, Jeroen
Hi, I'm a bit puzzled on the purpose of adding this. A few notes inline: On 13 Mar 2026, at 14:11, Jeroen Massar via db-wg <db-wg@ripe.net> wrote:
etc. Thus these are publically exposed. And for instance bgp.tools gives a handy overview: https://bgp.tools/rir-owner/ch.massar https://bgp.tools/rir-owner/nl.coloclue
if there are objects related to it. (No clue what Benjojo's magic there is, but it is handy ;) )
I imagine this might be https://ftp.ripe.net/ripe/stats/membership/alloclist.txt Not sure about the ASNs.
We do have the 'org' and related 'organisation' objects but these do not directly map to a LIR.
The unique identifier of any organisation in the RIPE database is the organisation: attribute in the organisation object type, and the org-type: identifies the organisation as an LIR (or OTHER).
But the "organisation" object does not map directly to LIR.
It does when the 'org-type' is 'LIR', right? Every LIR is represented in the database by one such object, I thought. Though you are then not required to refer that org from every object you have in the RIPE db.
Thus maybe the correct place is just in the organisation object.
That makes more sense to me, since a regid is just an identifier of certain organisations, which already have an LIR-type organisation object.
Though, it depends on the purpose of why we would add it; knowing which LIR an object exists for would be a good thing, and I do not think all objects have an org reference either, though inetnum/inet6num & amt-num likely yes, thus adding it to organisation would help a lot already to normalize that.
This is the main confusion I have: what does "which LIR an object exists for" mean? Sure, I can see the relation in case of an ALLOCATED-BY-RIR inet6num. But what about my mntner? My person object? An ASSIGNED PI inet6num? For the latter, I suppose you could link the sponsoring LIR, but their relation is quite distant. It sounds like you're trying to attach all objects in the RIPE db to a specific LIR, but I think that does not make sense for all objects, and I'm also not sure what the purpose is. Sasha
The rest of the magic most likely comes from the delegated-extended files. Radu On 13.03.2026 15:51, Sasha Romijn via db-wg wrote:
Hi,
I'm a bit puzzled on the purpose of adding this. A few notes inline:
On 13 Mar 2026, at 14:11, Jeroen Massar via db-wg <db-wg@ripe.net> wrote:
etc. Thus these are publically exposed. And for instance bgp.tools gives a handy overview: https://bgp.tools/rir-owner/ch.massar https://bgp.tools/rir-owner/nl.coloclue
if there are objects related to it. (No clue what Benjojo's magic there is, but it is handy ;) )
I imagine this might be https://ftp.ripe.net/ripe/stats/membership/alloclist.txt Not sure about the ASNs.
participants (5)
-
Edward Shryane -
Hank Nussbacher -
Jeroen Massar -
Radu Anghel -
Sasha Romijn