Hi, so on my self-hosted MTA I got an email [unsure about good intentions, thus checking origin] from 82.156.114.62 Whois directed to ripe, ripe said it's iana, iana said it's ripe [ BGP said ..... 4134 23724 45090 ] and ..... there's a route object in APNIC: route: 82.156.0.0/15 origin: AS45090 descr: Tencent Cloud Computing (Beijing) Co., Ltd 309 West Zone, 3F. 49 Zhichun Road. Haidian District. mnt-by: MAINT-TENCENT-CN last-modified: 2020-02-24T07:34:42Z source: APNIC and also "inetnum: 82.156.0.0 - 82.157.255.255" (in APNIC) So, I tend to believe that I'm on the wrong list here, because my question turns out to be: can I trust whois.iana.org ? It seems to tell me something different from what APNIC is saying. PS: a prefix containing IP in question is not seen in https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovered... am i right to be confused by the iana answer? who should get 'encouraged' to change something? Thanks, Frank [frank@fisi ~]$ whoisiana 82.156.114.62 [Querying whois.iana.org] [whois.iana.org] % IANA WHOIS server % for more information on IANA, visit http://www.iana.org % This query returned 1 object refer: whois.ripe.net inetnum: 82.0.0.0 - 82.255.255.255 organisation: RIPE NCC status: ALLOCATED whois: whois.ripe.net changed: 2002-11 source: IANA [frank@fisi ~]$ whois 82.156.114.62 [Querying whois.ripe.net] [whois.ripe.net] % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '82.156.0.0 - 82.157.255.255' % No abuse contact registered for 82.156.0.0 - 82.157.255.255 inetnum: 82.156.0.0 - 82.157.255.255 netname: NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK descr: IPv4 address block not managed by the RIPE NCC remarks: ------------------------------------------------------ remarks: remarks: For registration information, remarks: you can consult the following sources: remarks: remarks: IANA remarks: http://www.iana.org/assignments/ipv4-address-space remarks: http://www.iana.org/assignments/iana-ipv4-special-registry remarks: http://www.iana.org/assignments/ipv4-recovered-address-space remarks: remarks: AFRINIC (Africa) remarks: http://www.afrinic.net/ whois.afrinic.net remarks: remarks: APNIC (Asia Pacific) remarks: http://www.apnic.net/ whois.apnic.net remarks: remarks: ARIN (Northern America) remarks: http://www.arin.net/ whois.arin.net remarks: remarks: LACNIC (Latin America and the Carribean) remarks: http://www.lacnic.net/ whois.lacnic.net remarks: remarks: ------------------------------------------------------ country: EU # Country is really world wide admin-c: IANA1-RIPE tech-c: IANA1-RIPE status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT created: 2019-01-07T10:49:20Z last-modified: 2019-01-07T10:49:20Z source: RIPE role: Internet Assigned Numbers Authority address: see http://www.iana.org. admin-c: IANA1-RIPE tech-c: IANA1-RIPE nic-hdl: IANA1-RIPE remarks: For more information on IANA services remarks: go to IANA web site at http://www.iana.org. mnt-by: RIPE-NCC-MNT created: 1970-01-01T00:00:00Z last-modified: 2001-09-22T09:31:27Z source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.101 (ANGUS) [frank@fisi ~]$
Hello Frank, Le mardi 14 septembre 2021 à 21:09 +0300, Frank Habicht via db-wg a écrit :
(...)
there's a route object in APNIC: route: 82.156.0.0/15 origin: AS45090 descr: Tencent Cloud Computing (Beijing) Co., Ltd 309 West Zone, 3F. 49 Zhichun Road. Haidian District. mnt-by: MAINT-TENCENT-CN last-modified: 2020-02-24T07:34:42Z source: APNIC
and also "inetnum: 82.156.0.0 - 82.157.255.255" (in APNIC)
So, I tend to believe that I'm on the wrong list here, because my question turns out to be: can I trust whois.iana.org ?
It seems that 82.156.0.0/15 has been transferred from RIPE NCC to APNIC in 2018.
From RIPE transfer statistics JSON (*), we can find the following entry:
{"original_block":"82.156.0.0/15","transferred_blocks":"82.156.0.0/15", "to_rir":"APNIC","from_organisation":"Euronet Communications B.V.","date":"16/04/2018","transferType":"POLICY"} (*) https://www-static.ripe.net/dynamic/table-of-transfers/inter-rir/outgoing-ip... Seems that this is legit ! -- Clément Cavadore
In message <841e5d78-c466-c95b-a9cc-9f1ce2187533@geier.ne.tz>, Frank Habicht <geier@geier.ne.tz> wrote:
So, I tend to believe that I'm on the wrong list here, because my question turns out to be: can I trust whois.iana.org ?
The answer is: yes and no. Data returned by the whois.iana.org WHOIS server is good and correct for some things only. In particular, it provides good and useful data when queried for information about top-level domains such as BIZ, or ZA, or FR or whatever. The information it returns when queried about number resources is however rather hopelessly inaccurate, and only occasionally correct, owing largely to the very substantial number of inter-RIR transfers that have taken place over time.
am i right to be confused by the iana answer?
Yes.
who should get 'encouraged' to change something?
Well, good luck with that. I asked the IANA folks some long time ago now to fix the issue. They apparently have no interest in doing so. For my part, I have built my own set of WHOIS-like tools that nowadays avoid querying the whois.iana.org WHOIS server altogether and which instead steer queries about number resources to one of of the five RIR WHOIS servers based on the content of the daily-updated RIR "stats" files. Regards, rfg
On 14/09/2021 22:56, Ronald F. Guilmette via db-wg wrote:
In message <841e5d78-c466-c95b-a9cc-9f1ce2187533@geier.ne.tz>, Frank Habicht <geier@geier.ne.tz> wrote:
So, I tend to believe that I'm on the wrong list here, because my question turns out to be: can I trust whois.iana.org ?
The answer is: yes and no.
Data returned by the whois.iana.org WHOIS server is good and correct for some things only. In particular, it provides good and useful data when queried for information about top-level domains such as BIZ, or ZA, or FR or whatever. The information it returns when queried about number resources is however rather hopelessly inaccurate, and only occasionally correct, owing largely to the very substantial number of inter-RIR transfers that have taken place over time.
am i right to be confused by the iana answer?
Yes.
who should get 'encouraged' to change something?
Well, good luck with that. I asked the IANA folks some long time ago now to fix the issue. They apparently have no interest in doing so.
To whom did you submit a complaint? The place to lodge a complaint in regards to IANA functions is with the CSC: https://www.icann.org/csc "The CSC ensures the satisfactory performance of the Internet Assigned Numbers Authority (IANA) naming function. The CSC is responsible for monitoring Public Technical Identifier’s (PTI) performance of the IANA naming function against the service level expectations in the IANA Naming Function Contract." https://pti.icann.org/ Regards, Hank
On Tue, Sep 14, 2021 at 9:42 PM Hank Nussbacher via db-wg <db-wg@ripe.net> wrote: [...]
Well, good luck with that. I asked the IANA folks some long time ago now to fix the issue. They apparently have no interest in doing so.
To whom did you submit a complaint?
The place to lodge a complaint in regards to IANA functions is with the CSC: https://www.icann.org/csc
"The CSC ensures the satisfactory performance of the Internet Assigned Numbers Authority (IANA) naming function.
The CSC focuses on naming and not numbering issues. That said, rather than making a complaint, it might be more helpful to decide what the desired future state is and then ask the RIRs to work on that with the IANA team. In general, they'll make changes to the way they deliver services to the numbering community when the NRO makes a request.
Hi, On Wed, Sep 15, 2021 at 08:49:27AM -0700, Leo Vegoda via db-wg wrote:
The CSC focuses on naming and not numbering issues. That said, rather than making a complaint, it might be more helpful to decide what the desired future state is and then ask the RIRs to work on that with the IANA team. In general, they'll make changes to the way they deliver services to the numbering community when the NRO makes a request.
My take on this is: referrals MUST NOT loop. That is, if IANA points me to the RIPE NCC, and the network got moved *elsewhere*, the RIPE NCC should have a referral to "elsewhere", and not point "back to IANA". Ideally, IANA should point to the final RIR right away. (I see the "use RDAP, not whois" comment as sort of confusing - if the data source is good, the query method should not matter, and if the data source is bad, it definitely won't matter. If RDAP gives a proper referral and whois gives a bad one, the server needs to be fixed - but that's not a *protocol* issue) Gert Doering -- LIR contact and whois user -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi I would say forget IANA, forget RDAP and if you don't know which region a resource may be in use the RIPE GRS service. The mirrors are updated daily so you will get an accurate answer for the resource wherever it is today. cheers denis co-chair DB-WG On Wed, 15 Sept 2021 at 19:09, Gert Doering via db-wg <db-wg@ripe.net> wrote:
Hi,
On Wed, Sep 15, 2021 at 08:49:27AM -0700, Leo Vegoda via db-wg wrote:
The CSC focuses on naming and not numbering issues. That said, rather than making a complaint, it might be more helpful to decide what the desired future state is and then ask the RIRs to work on that with the IANA team. In general, they'll make changes to the way they deliver services to the numbering community when the NRO makes a request.
My take on this is: referrals MUST NOT loop.
That is, if IANA points me to the RIPE NCC, and the network got moved *elsewhere*, the RIPE NCC should have a referral to "elsewhere", and not point "back to IANA".
Ideally, IANA should point to the final RIR right away.
(I see the "use RDAP, not whois" comment as sort of confusing - if the data source is good, the query method should not matter, and if the data source is bad, it definitely won't matter. If RDAP gives a proper referral and whois gives a bad one, the server needs to be fixed - but that's not a *protocol* issue)
Gert Doering -- LIR contact and whois user -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Wed, Sep 15, 2021 at 10:09 AM Gert Doering <gert@space.net> wrote:
On Wed, Sep 15, 2021 at 08:49:27AM -0700, Leo Vegoda via db-wg wrote:
The CSC focuses on naming and not numbering issues. That said, rather than making a complaint, it might be more helpful to decide what the desired future state is and then ask the RIRs to work on that with the IANA team. In general, they'll make changes to the way they deliver services to the numbering community when the NRO makes a request.
My take on this is: referrals MUST NOT loop.
+1
That is, if IANA points me to the RIPE NCC, and the network got moved *elsewhere*, the RIPE NCC should have a referral to "elsewhere", and not point "back to IANA".
Ideally, IANA should point to the final RIR right away.
+1
Hi guys What you are suggesting here is quite a significant change to the way the RIPE Database (and maybe IANA) works. The block 82.156/16 is not (or no longer) in the RIPE Database. There are place holder objects in the RIPE Database for non RIPE address space. All these place holder objects contain the same generic information. They state this is not RIPE address space and include links to all the other whois databases. So strictly speaking it does not refer 'back' to IANA and therefore it is not a loop. The person making the query will find the object in one of the listed whois databases. If you want the RIPE Database to provide a referral service then you are asking for the RIPE Database to become a global whois service rather than using the RIPE GRS. If this block was transferred from RIPE to APNIC then it is easy to update the placeholder at that moment to make a referral to APNIC. But what if the object is transferred again to another region? The RIPE Database would have to track all transfers, otherwise the referral may become stale information. The RIPE NCC effectively already provides this referral service with RIPE GRS. It solves this problem 100% for all RIR administered address space. Why do we need the NRO to start discussions with IANA on how to fix a problem that already has a fully implemented and working solution? cheers denis co-chair DB-WG On Thu, 16 Sept 2021 at 00:59, Leo Vegoda via db-wg <db-wg@ripe.net> wrote:
On Wed, Sep 15, 2021 at 10:09 AM Gert Doering <gert@space.net> wrote:
On Wed, Sep 15, 2021 at 08:49:27AM -0700, Leo Vegoda via db-wg wrote:
The CSC focuses on naming and not numbering issues. That said, rather than making a complaint, it might be more helpful to decide what the desired future state is and then ask the RIRs to work on that with the IANA team. In general, they'll make changes to the way they deliver services to the numbering community when the NRO makes a request.
My take on this is: referrals MUST NOT loop.
+1
That is, if IANA points me to the RIPE NCC, and the network got moved *elsewhere*, the RIPE NCC should have a referral to "elsewhere", and not point "back to IANA".
Ideally, IANA should point to the final RIR right away.
+1
In message <CAKvLzuELQ8-GjkTnVc7Gk=_jGmdfvuSurH_XmkV71skA6iPADQ@mail.gmail.com> denis walker <ripedenis@gmail.com> wrote:
If this block was transferred from RIPE to APNIC then it is easy to update the placeholder at that moment to make a referral to APNIC. But what if the object is transferred again to another region? The RIPE Database would have to track all transfers, otherwise the referral may become stale information.
You make it sound like this "tracking" is somehow difficult. But I'm effectively doing it every day, day in and day out, based on the daily RIR "stats" files, and it's not actually that hard.
The RIPE NCC effectively already provides this referral service with RIPE GRS. It solves this problem 100% for all RIR administered address space.
The code that I've cooked up does it for 100% of... address space. Period.
Why do we need the NRO to start discussions with IANA on how to fix a problem that already has a fully implemented and working solution?
We don't. At least I don't. I already have what I need. As regards to RIPE's "working solution" all I can say is that it's nothing personal, but personally I don't much feel like relying on any given RIR for data & updates relating to the holdings of other RIRs, especially when the needed data about the holdings of other RIRs can be fetched from those other RIRs themselves directly. There's also some other potentially issues with relying on RIPE for this data, to wit: *) Is RIPE guaranteeing that it will support its interface to this data forever? If not, how long is the commitment? (I am thinking about various OS "Long Term Support" distributions that provide some guarantees that the stuff will still be usable in, say, 5 years from now.) *) Is RIPE guaranteeing that it will -freeze- its interface to this data forever and not make any API changes? *) It seems to me that it is a given that whatever RIPE is distributing / publishing must, by definition, not be as fresh and up-to-the-minute as what the individual RIRs are themselves publishing in their respective daily "stats" files. (If I'm wrong about this, then please do enlighten me.) Regarding that last point, I think that it would be Swell if all of the five RIRs would start updating their respective "daily" stats files in near real-time, i.e. whenever a change is made to any of them. Perhaps RIPE NCC would like to volunteer to be the test case for this. It would also be Swell if these files were provided via rsync, so that local mirrored copies could be usefully updated more than once a day. (Rsync seems especially well suited for this, as the files mostly don't change from day to day, and mostly would not change even from hour to hour or minute to minute, even if they were being updated by the RIRs in near real time.) Again, maybe RIPE NCC might like to lead the way on this. Regards, rfg
Hi, On Thu, Sep 16, 2021 at 02:59:04AM +0200, denis walker wrote:
The RIPE NCC effectively already provides this referral service with RIPE GRS. It solves this problem 100% for all RIR administered address space. Why do we need the NRO to start discussions with IANA on how to fix a problem that already has a fully implemented and working solution?
The NCC is not the root of the address distribution tree. IANA is. So pointing people from all over the world to the RIPE NCC "because IANA can't get their part right" is conceptually the wrong approach. In practice, it might provide a fast and convenient approach today, but why can't IANA just do that? Mirror the RIR stats files, point people asking *at the root of the tree* to the right branch. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 16/09/2021 09:06, Gert Doering via db-wg wrote:
On Thu, Sep 16, 2021 at 02:59:04AM +0200, denis walker wrote:
The RIPE NCC effectively already provides this referral service with RIPE GRS. It solves this problem 100% for all RIR administered address space. Why do we need the NRO to start discussions with IANA on how to fix a problem that already has a fully implemented and working solution?
The NCC is not the root of the address distribution tree. IANA is.
So pointing people from all over the world to the RIPE NCC "because IANA can't get their part right" is conceptually the wrong approach.
In practice, it might provide a fast and convenient approach today, but why can't IANA just do that? Mirror the RIR stats files, point people asking *at the root of the tree* to the right branch.
Gert Doering -- NetMaster
thanks Gert for putting it much better than I did/could. Frank (OP)
Hi, On Thu, 2021-09-16 at 08:06 +0200, Gert Doering via db-wg wrote:
The NCC is not the root of the address distribution tree. IANA is.
I'm sure there are DNS people around that can explain to IANA what a lame delegation is… Cheers 🙂 Sander
< i will regret this >
I'm sure there are DNS people around that can explain to IANA what a lame delegation is…
folk: i think it is safe to assume the iana is technically competent. the problems lies above layer seven, and particularly in the seemingly eternal ego and power struggle between the c suite of two registries (not the ncc) and the iana. the ops community, which is supposed to be served, is the collateral damage. randy --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header butchery
In message <m2r1doo4w6.wl-randy@psg.com>, Randy Bush <randy@psg.com> wrote:
< i will regret this >
I'm sure there are DNS people around that can explain to IANA what a lame delegation is$B!D(B
folk: i think it is safe to assume the iana is technically competent. the problems lies above layer seven, and particularly in the seemingly eternal ego and power struggle between the c suite of two registries (not the ncc) and the iana. the ops community, which is supposed to be served, is the collateral damage.
Well, the good news is that this is a case where software can (and does) trump bureaucratic intransigence. I've created my tool, which allows me to get the full unredacted WHOIS records for any IPv4 address (IPv6 coming soon) with one command. Other folks with similar needs (e.g. the people who programmed bgp.he.net) have likewise found or made their own home-brew solutions. I'd like to offer the following corollary to the well-known (John) Gilmore's Law: "Bureaucratic unhelpfulness is like censorship, and software may often be employed to work around it." Regards, rfg
In message <YUIo36HUclTPm/2b@Space.Net>, Gert Doering <gert@space.net> wrote:
Ideally, IANA should point to the final RIR right away.
That would certainly be more helpful than the present state of affairs, within which the IANA WHOIS server is not merely failing to give out correct referrals, but is actually giving out demonstratably incorrect referrals. Functionally and operationally, the portion of the IANA WHOIS service that provides referrals for IP addresses is, at present, worse than useless due to the innumerable incorrect referrals it provides. If IANA does not wish to correct that, then they should at least configure the thing so that it will stop providing *any* responses at all when queried about IP addresses. That way, naive users will not be lulled into the false believe that it provides correct referrals in response to such queries, only to find out later on that it often does not. Regards, rfg
In message <cd74b6a0-eaed-444f-cb47-abd4b1cbeb5c@interall.co.il>, Hank Nussbacher <hank@interall.co.il> wrote:
who should get 'encouraged' to change something?
Well, good luck with that. I asked the IANA folks some long time ago now to fix the issue. They apparently have no interest in doing so.
To whom did you submit a complaint?
hostmaster@iana.org And to be clear, it wasn't a "complaint". I pointed out to them that the output of their WHOIS server often redirects people to the wrong RIR WHOIS server. I felt that I was attempting to be helpful, not adversarial. (Why is is that every time someone reports a spam to an ISP, this is termed by some folks to be some kind of a "spam complaint". We few who still do this sort of thing in the year 2021 are in fact trying to help ISPs to know which of their customers are undesirable troublemakers. And believe it or not, some ISPs are actually appropriately grateful for that.)
The place to lodge a complaint in regards to IANA functions is with the CSC: https://www.icann.org/csc
By all means. Please feel free to do that Hank. I have already made the decision not to wait for the year or two it might take for some functionally useful change to percolate up through the various relevant departments, organs, and discussion lists. I've got actual work that I actually want to get accomplished this week, not nine months from now after a lengthy series of committee reviews. So I've already gone ahead and developed a software work-around for what is, I think, a rather self-evident lack of interest on IANA's part in the notion of correcting the clearly incorrect outputs delivered by IANA's WHOIS server. Regards, rfg
Hi Ronald On Thu, 16 Sept 2021 at 03:16, Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
I have already made the decision not to wait for the year or two it might take for some functionally useful change to percolate up through the various relevant departments, organs, and discussion lists. I've got actual work that I actually want to get accomplished this week, not nine months from now after a lengthy series of committee reviews. So I've already gone ahead and developed a software work-around for what is, I think, a rather self-evident lack of interest on IANA's part in the notion of correcting the clearly incorrect outputs delivered by IANA's WHOIS server.
Why are you trying to reinvent the wheel? Why don't you use the RIPE GRS service? It will tell you exactly where any RIR administered address space is as of yesterday. The mirrored RIR databases are updated daily by the RIPE NCC. It is probably more accurate and more reliable than any home built work around. cheers denis co-chair DB-WG
Regards, rfg
In message <CAKvLzuH7dhj6ti_RW_hqo61BOsXT_7iiihkVs9D_O0M-uPb9uQ@mail.gmail.com> denis walker <ripedenis@gmail.com> wrote:
Why are you trying to reinvent the wheel?
I'm not "trying". My code is already done and tested and working.
Why don't you use the RIPE GRS service?
If it's so swell and accurate, then why haven't you sold it or given it to IANA and why haven't you convinced them to use it as a replacement for their evidentally broken port 43 WHOIS server? Look denis, I understand that you are proud of your baby, and I'm sure rightfully so, but there are multiple answers to your question "Why doesn't RFG use my beautiful baby?" First and foremost, I had a problem to solve and I set forth to solve it, which I did. At the time, I was totally unaware of this RIPE GRS service that you're on about. (Not that I necessarily would have used it even if I had known about it. I'm not too sure I would have. See below.) If I didn't know about it, then whose fault is that? Sure. If it makes you feel superior you can just be smug and say that RFG is an ignorant idiot and that's why he didn't know about it. But I could then retort and say that you have done a less than adequate job of publicising the RIPE GRS Service. Who is right and who is going to win this pissing match? Arguably we're both right. So let's just pretend that we already had this pointless pissing match, that neither us us won, and that everyone else on this list was bored to tears by the whole thing and begged us all to take it off list. So let's just move on shall we? More to the point, and regardless of whether I should have found out about your poorly publicised RIPE GRS Service or not, or whether you should have done more to publicise it, there are other reasons why I might not have elected to use the RIPE GRS Service even if I had known about it: *) I abhor becoming dependant upon other people's code and/or upon other people's willingness to fix bugs and/or upon other people's lack of enthusiasm for writing documentation. When I google for "RIPE GRS service" the first thing that comes up is this: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/glossary/g... Swell. A page describing something in sort of vague terms and which provides exactly -zero- links for the benefit of people who want to learn more about this wonderful thing. Is this a joke of some kind? If so, then I confess that I don't get it. The third google hit is a link to something on github. Uh oh! Red flag right there. So in order to use your magic fu, I need to download, compile (and perhaps port to FreeBSD) your code before I can use your magical solution. OH! AND WAIT! I guess that I also have to install Java[tm], which I trust about as far as I can throw it. Marvelous. Because I just didn't already have enough to do today, and I never seem to have quite enough security bugs on my main server/workstation, so I definitely want to drop whatever else I was doing and install Java. Did I mention that I don't even speak Java, and that thus, extending your code or integrating it with my own is pretty much a non-starter for me? *) The first order things that I want from, and that I am getting from the daily RIR "stats" files is/are *not* full WHOIS infornmation. I know where to get THAT information when & if I need it, i.e. direct from the various RIR WHOIS servers. What I want from, and what I am almost effortlessly getting from the daily stats files is: *) Lists of all IPv4/IPv6/ASN space blocks that have been assigned to, or transferred to each respective RIR. *) Lists of all IPv4/IPv6/ASN space blocks that have been assigned by each respective RIR to its resource members. This is *not* WHOIS information per se. And for what I was trying to accomplish I didn't need full WHOIS information. I only needed what I have identified just above, which is vastly simpler. Now, let's look at what your de luxe RIPE GRS service provides: https://labs.ripe.net/author/denis/the-ripe-global-resource-service/ "The primary goal of this service is to provide information on global Internet resources from all the RIRs and some routing registries (listed below). This involves inetnum and inet6num objects, representing IPv4 and IPv6 address space, and aut-num objects, representing Autonomous System Numbers (ASN). Other operational objects like route and route6 and additional supporting objects, such as person and role , are also included for some sources." So basically, you're demanding to know why I'm not using your pride and joy, and you're astonished that I'm not using something that provides a glorious wealth of information that I simply do not need and that I would have to expend extra labor to filter out in order to get just that minimal information that I *do* actually need. Is that about the size of it? If I have failed to clarify why I might not have elected to use your marvelous and exceedingly lovely GRS thing then I don't know what else to say. The RIPE GRS Service provides vast amounts of information, most of which is totally irrelevant to my actual and minimalist needs. But let's set that annoying little fact aside for a moment. Please tell me how I can quickly and efficient extract from the RIPE GRS Service a complete list of all IP blocks that have been allocated *directly* from any & all RIRs, worldwide, to any of their resource members. Once you have done that, then please explain how obtaining such lists from the RIPE GRS Service is either more efficient or for any other reason is preferable to obtaining the exact same information from the daily RIR stats files. No hurry. I'll wait.
It will tell you exactly where any RIR administered address space is as of yesterday.
So will the daily stats files. What's your point? I can get the daily stats files using just WGET or CURL, both of which are already installed on my system, and I DO NOT have to either download or rely on anybody else's mystery code and I DO NOT have to install any bleedin' suspect Java interpreter, and I DO NOT have to waste time figuring out which exact version of the Java interpreter is compatible with your code, and I DO NOT thenceforth and forever have to worry about keeping that Java interpreter up-to-date with the latest security patches. I understand that you are very proud of the hammer you've built. Really I do. But the fact that you've built a very beautiful & shiny hammer does not render every problem in the world as a nail. My needs were and are perfectly met by the modest amount of Perl code and shell scripts that I wrote... code that I wrote and that I can now extend, maintain, and integrate with my other tools because unlike Java, I do actually speak Perl.
The mirrored RIR databases are updated daily by the RIPE NCC. It is probably more accurate and more reliable than any home built work around.
No. I have made this point already. The daily RIR stats files are updated by the RIRs themselves "daily". If you are being fed data by the RIRs that is more up-to-date and (thus) more accurate than that, then please do tell me where I can sign up for that "early update" service from the five RIRs also. Otherwise the data that is present in your GRS thing is no more accurate than what I have, and may possibly be even less so. Regards, rfg P.S. It's up to you, of course, but I do think that in future your time would be more productively spent in reviewing your own design decisions, rather than trying to second guess or "Monday morning quarterback" other people's design decisions. Their needs may not be your needs, and their goals may not be your goals.
In message <CAKvLzuH7dhj6ti_RW_hqo61BOsXT_7iiihkVs9D_O0M-uPb9uQ@mail.gmail.com> denis walker <ripedenis@gmail.com> wrote:
Why don't you use the RIPE GRS service?
Although I have already listed most of the numerous reasons why I don't use this service in my prior posting, I suppose that for the sake of completeness I should also point out the following, which is an absolute and irrefutable deal-breaker. I don't just build tools for the sake of building tools. I like coding, but I have plenty else to do. I build tools to achieve a goal. I work on network abuse issues. I have done so for about 20 years and I continue to do so. If I become aware of a situation, like the one I have become aware of recently, wherein two different networks in the APNIC region and one in the RIPE region have apparently taken up the rather deplorable habit of hosting phishing web sites, I like to contact the administrators of such networks and ask them why they are doing this and if they plan to continue to do so. When I say "contact" in this context, I generally mean either via email or phone. The specific tool that I have been talking about here recently allows me to get the full *unredacted* WHOIS record for any given IP block, anywhere on the planet. Emphasis on "unredacted". It is of very nearly -zero- use to me to get the name of a company to which a given IP address block is registered if I do not also get a contact email address and/or phone number for the company in question. A brief quote relating to the RIPE GRS Service: https://labs.ripe.net/author/denis/the-ripe-global-resource-service/ "When we display any data we can obfuscate the data depending on the requirements of the data set owner and the European Data Protection directives. The data can be queried by any of the RIPE Database query methods: The Web Query form The RESTful API Command line queries. ..." The bottom line is that GRS does not provide the information that either I or anyone else who is combatting network abuse actually needs. Instead, the advice is given that in order to get this key information, the user should resort to good old fashion port 43 queries, which is *exactly* what my tool does. (So maybe I'm not such a big dummy after all.) I shall not debate the merits, or the lack thereof, of this european invention called "GDPR". I understand its noble intent and motivation. That having been said, it is distinctly *not* helpful to anyone who is ernestly and proactively seeking to make the global Internet a better and safer place for all, and not just by way of protecting end users from evil American giant corporations and their voracious and generally sinister appetites for unlimited quantities of data relating to natural persons. That is quite certainly not the only threat that end users face when they venture onto the Internet. I would however be more than happy to debate the now nearly universal and atrociously misguided attempts by some to hobble otherwise useful sources of contact information for entities that are quite evidentally *not* natural persons, and the unambiguously negative effects this has on the security and stability of the Internet globally, not to mention its clearly destructive and deleterious effects upon the safety of billions of ordinary Intetnet end users worldwide. (Not that I would expect anyone on a mailing list like this to give a rat's ass about any of those poor ordinary end users or their routine and day-to-day victimizations at the hands of professional cybercriminals.) Regards, rfg
Dear all, On Tue, Sep 14, 2021 at 09:09:24PM +0300, Frank Habicht via db-wg wrote:
Whois directed to ripe, ripe said it's iana, iana said it's ripe
[ BGP said ..... 4134 23724 45090 ]
and .....
there's a route object in APNIC:
[snip]
and also "inetnum: 82.156.0.0 - 82.157.255.255" (in APNIC)
So, I tend to believe that I'm on the wrong list here, because my question turns out to be: can I trust whois.iana.org ?
It seems to tell me something different from what APNIC is saying.
Another interesting source of data might be "RDAP". The WHOIS query protocol had some shortfalls, which the RDAP design community attempted to address. Wikipedia offers a good summary on what RDAP is here: https://en.wikipedia.org/wiki/Registration_Data_Access_Protocol RDAP is a query protocol which facilitates search clients to find the most current information, even after transfers. For example, the following three URLs are RDAP endpoints redirecting towards (or republishing data from) a singular 'most current' database. https://rdap.db.ripe.net/ip/82.156.114.62 https://search.arin.net/rdap/?query=82.156.114.62 https://client.rdap.org/?type=ip&object=82.156.114.62 In-depth technical documentation can be found in RFC 9082 https://datatracker.ietf.org/doc/html/rfc9082 I recommend all 'WHOIS' users to study if their information query needs are not better served via RDAP. Kind regards, Job
Thanks Job! On 14/09/2021 23:59, Job Snijders wrote:
https://rdap.db.ripe.net/ip/82.156.114.62 https://search.arin.net/rdap/?query=82.156.114.62 https://client.rdap.org/?type=ip&object=82.156.114.62
Frank
Hi Frank The RIPE NCC mirrors all the RIR's whois databases and provides a Global Resource Service (GRS). This can be easily accessed using the webupdates interface https://apps.db.ripe.net/db-web-ui/query You select the option "Search resource objects in all available databases" and you will get the correct data from the RIR responsible for this resource. This link gives the data for the resource you are interested in: https://apps.db.ripe.net/db-web-ui/query?bflag=true&dflag=false&rflag=true&searchtext=82.156.114.62&source=GRS cheers denis co-chair DB-WG On Tue, 14 Sept 2021 at 20:09, Frank Habicht via db-wg <db-wg@ripe.net> wrote:
Hi,
so on my self-hosted MTA I got an email [unsure about good intentions, thus checking origin] from 82.156.114.62
Whois directed to ripe, ripe said it's iana, iana said it's ripe
[ BGP said ..... 4134 23724 45090 ]
and .....
there's a route object in APNIC: route: 82.156.0.0/15 origin: AS45090 descr: Tencent Cloud Computing (Beijing) Co., Ltd 309 West Zone, 3F. 49 Zhichun Road. Haidian District. mnt-by: MAINT-TENCENT-CN last-modified: 2020-02-24T07:34:42Z source: APNIC
and also "inetnum: 82.156.0.0 - 82.157.255.255" (in APNIC)
So, I tend to believe that I'm on the wrong list here, because my question turns out to be: can I trust whois.iana.org ?
It seems to tell me something different from what APNIC is saying.
PS: a prefix containing IP in question is not seen in https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovered...
am i right to be confused by the iana answer? who should get 'encouraged' to change something?
Thanks, Frank
[frank@fisi ~]$ whoisiana 82.156.114.62 [Querying whois.iana.org] [whois.iana.org] % IANA WHOIS server % for more information on IANA, visit http://www.iana.org % This query returned 1 object
refer: whois.ripe.net
inetnum: 82.0.0.0 - 82.255.255.255 organisation: RIPE NCC status: ALLOCATED
whois: whois.ripe.net
changed: 2002-11 source: IANA
[frank@fisi ~]$ whois 82.156.114.62 [Querying whois.ripe.net] [whois.ripe.net] % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Note: this output has been filtered. % To receive output for a database update, use the "-B" flag.
% Information related to '82.156.0.0 - 82.157.255.255'
% No abuse contact registered for 82.156.0.0 - 82.157.255.255
inetnum: 82.156.0.0 - 82.157.255.255 netname: NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK descr: IPv4 address block not managed by the RIPE NCC remarks: ------------------------------------------------------ remarks: remarks: For registration information, remarks: you can consult the following sources: remarks: remarks: IANA remarks: http://www.iana.org/assignments/ipv4-address-space remarks: http://www.iana.org/assignments/iana-ipv4-special-registry remarks: http://www.iana.org/assignments/ipv4-recovered-address-space remarks: remarks: AFRINIC (Africa) remarks: http://www.afrinic.net/ whois.afrinic.net remarks: remarks: APNIC (Asia Pacific) remarks: http://www.apnic.net/ whois.apnic.net remarks: remarks: ARIN (Northern America) remarks: http://www.arin.net/ whois.arin.net remarks: remarks: LACNIC (Latin America and the Carribean) remarks: http://www.lacnic.net/ whois.lacnic.net remarks: remarks: ------------------------------------------------------ country: EU # Country is really world wide admin-c: IANA1-RIPE tech-c: IANA1-RIPE status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT created: 2019-01-07T10:49:20Z last-modified: 2019-01-07T10:49:20Z source: RIPE
role: Internet Assigned Numbers Authority address: see http://www.iana.org. admin-c: IANA1-RIPE tech-c: IANA1-RIPE nic-hdl: IANA1-RIPE remarks: For more information on IANA services remarks: go to IANA web site at http://www.iana.org. mnt-by: RIPE-NCC-MNT created: 1970-01-01T00:00:00Z last-modified: 2001-09-22T09:31:27Z source: RIPE # Filtered
% This query was served by the RIPE Database Query Service version 1.101 (ANGUS)
[frank@fisi ~]$
Thanks. perfect. Frank On 15/09/2021 00:03, denis walker wrote:
Hi Frank
The RIPE NCC mirrors all the RIR's whois databases and provides a Global Resource Service (GRS). This can be easily accessed using the webupdates interface https://apps.db.ripe.net/db-web-ui/query
You select the option "Search resource objects in all available databases" and you will get the correct data from the RIR responsible for this resource.
This link gives the data for the resource you are interested in: https://apps.db.ripe.net/db-web-ui/query?bflag=true&dflag=false&rflag=true&searchtext=82.156.114.62&source=GRS
cheers denis co-chair DB-WG
On Tue, 14 Sept 2021 at 20:09, Frank Habicht via db-wg <db-wg@ripe.net> wrote:
Hi,
so on my self-hosted MTA I got an email [unsure about good intentions, thus checking origin] from 82.156.114.62
Whois directed to ripe, ripe said it's iana, iana said it's ripe
[ BGP said ..... 4134 23724 45090 ]
and .....
there's a route object in APNIC: route: 82.156.0.0/15 origin: AS45090 descr: Tencent Cloud Computing (Beijing) Co., Ltd 309 West Zone, 3F. 49 Zhichun Road. Haidian District. mnt-by: MAINT-TENCENT-CN last-modified: 2020-02-24T07:34:42Z source: APNIC
and also "inetnum: 82.156.0.0 - 82.157.255.255" (in APNIC)
So, I tend to believe that I'm on the wrong list here, because my question turns out to be: can I trust whois.iana.org ?
It seems to tell me something different from what APNIC is saying.
PS: a prefix containing IP in question is not seen in https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovered...
am i right to be confused by the iana answer? who should get 'encouraged' to change something?
Thanks, Frank
[frank@fisi ~]$ whoisiana 82.156.114.62 [Querying whois.iana.org] [whois.iana.org] % IANA WHOIS server % for more information on IANA, visit http://www.iana.org % This query returned 1 object
refer: whois.ripe.net
inetnum: 82.0.0.0 - 82.255.255.255 organisation: RIPE NCC status: ALLOCATED
whois: whois.ripe.net
changed: 2002-11 source: IANA
[frank@fisi ~]$ whois 82.156.114.62 [Querying whois.ripe.net] [whois.ripe.net] % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Note: this output has been filtered. % To receive output for a database update, use the "-B" flag.
% Information related to '82.156.0.0 - 82.157.255.255'
% No abuse contact registered for 82.156.0.0 - 82.157.255.255
inetnum: 82.156.0.0 - 82.157.255.255 netname: NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK descr: IPv4 address block not managed by the RIPE NCC remarks: ------------------------------------------------------ remarks: remarks: For registration information, remarks: you can consult the following sources: remarks: remarks: IANA remarks: http://www.iana.org/assignments/ipv4-address-space remarks: http://www.iana.org/assignments/iana-ipv4-special-registry remarks: http://www.iana.org/assignments/ipv4-recovered-address-space remarks: remarks: AFRINIC (Africa) remarks: http://www.afrinic.net/ whois.afrinic.net remarks: remarks: APNIC (Asia Pacific) remarks: http://www.apnic.net/ whois.apnic.net remarks: remarks: ARIN (Northern America) remarks: http://www.arin.net/ whois.arin.net remarks: remarks: LACNIC (Latin America and the Carribean) remarks: http://www.lacnic.net/ whois.lacnic.net remarks: remarks: ------------------------------------------------------ country: EU # Country is really world wide admin-c: IANA1-RIPE tech-c: IANA1-RIPE status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT created: 2019-01-07T10:49:20Z last-modified: 2019-01-07T10:49:20Z source: RIPE
role: Internet Assigned Numbers Authority address: see http://www.iana.org. admin-c: IANA1-RIPE tech-c: IANA1-RIPE nic-hdl: IANA1-RIPE remarks: For more information on IANA services remarks: go to IANA web site at http://www.iana.org. mnt-by: RIPE-NCC-MNT created: 1970-01-01T00:00:00Z last-modified: 2001-09-22T09:31:27Z source: RIPE # Filtered
% This query was served by the RIPE Database Query Service version 1.101 (ANGUS)
[frank@fisi ~]$
Frank Habicht via db-wg <db-wg@ripe.net> wrote:
so on my self-hosted MTA I got an email [unsure about good intentions, thus checking origin] from 82.156.114.62
Whois directed to ripe, ripe said it's iana, iana said it's ripe
Yes, but it's a bit more subtle than that. I have hacked a bit on FreeBSD's whois client, and the way it handles cases like this is to start off with whois.iana.net as the authority for IPv4 /8 allocations. IANA says (amongst other things): whois: whois.ripe.net which is a common format for a whois referral. So, ask whois.ripe.net, which says (amongst other things): netname: NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK In the context of the IANA referral, that line means the address block has been transferred out of the RIPE region, but RIPE's whois server will not tell you which other RIR to ask. (ARIN provides referrals in this situation; AfriNIC says which RIR to try in comments rather than as a formal referral.) So FreeBSD whois tries the other RIRs in turn, starting with ARIN, because ARIN is often more knowledgable/informative than the other RIRs, especially for legacy allocations. But ARIN doesn't know about this block and just provides a referral to RIPE: ReferralServer: whois://whois.ripe.net So next guess APNIC, which it turns out does know about this address block. I have complained before that RIPE's whois server ought to provide proper referrals when the database has information about which RIR is responsible for an address block. Tony. -- f.anthony.n.finch <dot@dotat.at> https://dotat.at/ Shannon, Rockall: Westerly or northwesterly, backing southerly or southwesterly, then westerly later in west, 4 to 6, occasionally 7 later. Moderate or rough, becoming rough. Thundery showers. Good, occasionally poor later.
In message <6d7c9cf4-7a83-fa1a-d013-d7f89c9c964f@dotat.at>, Tony Finch <dot@dotat.at> wrote:
I have complained before that RIPE's whois server ought to provide proper referrals when the database has information about which RIR is responsible for an address block.
As I mentioned earlier I rather dislike the words "complain", "complaint", "complaining", or "complained" in this context. I personally would prefer to say that you attempted to assist RIPE NCC in improving the output of the RIPE WHOIS server for the benefit of the entire worldwide Internet community. In any case, I cannot help but note that neither RIPE nor ARIN nor any other RIR would need to provide referrals for number resource queries if only the whois.iana.org server were consistantly giving out proper referrals. (It isn't.) I don't know who pays those IANA people or who thus controls their tasking and priorities. All I know is that it isn't me. So I have neither any right nor any leverage which I could persuade them to fix the obvious brokeness of their WHOIS server, and even if I did, completion of the task might possibly be mesurable on a geologic time scale. So I just count myself lucky that there is some other basis on which to reliably determine which RIR owns what, i.e. the daily RIR stats files. Regards, rfg
Hi, On Fri, Sep 17, 2021 at 05:39:14PM -0700, Ronald F. Guilmette via db-wg wrote:
I don't know who pays those IANA people or who thus controls their tasking and priorities. All I know is that it isn't me.
I suspect it is me/us, after all... a fair amount of ICANN financing comes from the joint RIRs, if I'm not mistaken. So yes, if we tell the RIRs, they should be able to achieve an effect. (Inter-RIR politics leading to non-agreement on ICANN requirements aside, but that would be remarkably short-sighted in a simple case as this) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 18/09/2021 12:21, Gert Doering via db-wg wrote:
Hi,
On Fri, Sep 17, 2021 at 05:39:14PM -0700, Ronald F. Guilmette via db-wg wrote:
I don't know who pays those IANA people or who thus controls their tasking and priorities. All I know is that it isn't me.
I suspect it is me/us, after all... a fair amount of ICANN financing comes from the joint RIRs, if I'm not mistaken. So yes, if we tell the RIRs, they should be able to achieve an effect.
Based on: https://www.icann.org/en/system/files/files/budget-fy22-2021-en.pdf page 10 (page 12 per PDF), RIR contribution is .8MUSD out of 144MUSD budget. The vast majority of their budget comes from registrar transaction fees. Regards, Hank
On 18/09/2021 20:29, Hank Nussbacher via db-wg wrote:
On 18/09/2021 12:21, Gert Doering via db-wg wrote:
Hi,
On Fri, Sep 17, 2021 at 05:39:14PM -0700, Ronald F. Guilmette via db-wg wrote:
I don't know who pays those IANA people or who thus controls their tasking and priorities. All I know is that it isn't me.
I suspect it is me/us, after all... a fair amount of ICANN financing comes from the joint RIRs, if I'm not mistaken. So yes, if we tell the RIRs, they should be able to achieve an effect.
Based on: https://www.icann.org/en/system/files/files/budget-fy22-2021-en.pdf page 10 (page 12 per PDF), RIR contribution is .8MUSD out of 144MUSD budget. The vast majority of their budget comes from registrar transaction fees.
Regards, Hank
ICANN just published their detailed funding sources report: https://www.icann.org/en/system/files/files/fy21-funding-source-30jun21-en.p... Regards, Hank
participants (11)
-
Clement Cavadore -
denis walker -
Frank Habicht -
Gert Doering -
Hank Nussbacher -
Job Snijders -
Leo Vegoda -
Randy Bush -
Ronald F. Guilmette -
Sander Steffann -
Tony Finch