From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: location@lists.ipfire.org Subject: Re: incorporation state of ARIN's asn.txt / LACNIC AS name data Date: Wed, 14 Jul 2021 17:43:23 +0100 Message-ID: <5746CCA4-BBFB-4690-BF5A-09C8EB256AC7@ipfire.org> In-Reply-To: <20cbf1a1-1c08-b610-e6a8-519545e168ec@riseup.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8795848642075974342==" List-Id: --===============8795848642075974342== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello nusenu, > On 27 Jun 2021, at 11:14, nusenu wrote: >=20 > Hi Peter, >=20 > thanks for your comprehensive reply. >=20 > Peter M=C3=BCller wrote: >> the AS names file provided by ARIN does not contain human-readable AS >> names (although DigitalOcean is one of the better examples in >> there), I rather see it as an improvement than a solution. :-) >=20 > out of curiosity: I haven't understood your differentiation between "human-= readable" and "technical" AS names. > Would you mind elaborating on your definitions of human-readable AS names? >=20 > I understand AS name as the name attribute of the AutNum WHOIS object. >=20 > to use an example again: > "DIGITALOCEAN-ASN" is the AS name of AS14061 according to [1], WHOIS [2] an= d well > established tools like RIPEstat show the very same string [3]. >=20 > [1] https://ftp.arin.net/info/asn.txt > [2] https://whois.arin.net/rest/asn/AS14061 > [3] https://stat.ripe.net/widget/as-overview#w.resource=3DAS14061 >=20 >> If you or anybody else has any idea of getting more precise location >> or AS data for space maintained by these two RIRs in a reliable way, >> we will be most interested in hearing about it. >=20 > with regards to LACNIC: Maybe their bulk whois data is something you > find useful? (I didn't use it myself) >=20 > https://www.lacnic.net/en/web/lacnic/manual-8 > https://github.com/microsoft/WhoisParsers/blob/fb54e3cf576e5caa4d2f8e0c1576= 8925d14dc464/WhoisDownload/WhoisDownload.cs#L45 >=20 > RIPEstat is also an option for AS names but it is not bulk data and > requires one request per ASN to get the well formated JSON response. >=20 >=20 >> The reason why you do not see those AS names in production is >> because there is no new libloc release, yet. There is one bug >> (#12553) left to fix, but afterwards, I guess we are fine to release >> libloc 0.9.7; a day later, the generated database dump should contain >> the AS information. >=20 > Do you have a rough estimate on when this next version will be released? >=20 >=20 >> For the sake of completeness, I take the liberty to note that the >> database.txt file you are referring to, and the Tor maintainers >> retrieve for baking it into their releases is _not_ the actual >> location database. So, technically, Tor is using the data >> conglomerated together by libloc - which we are happy about -, but >> not libloc itself. As far as I am aware, they decided against >> shipping libloc with Tor for the moment, primarily due to >> compatibility issues with the 0.3.5.x LTS branch. >=20 > I'm aware of the differences here. To be precise I'm not referring to the > db file that the torproject ships with tor releases. > I'm referring to their onionoo service (https://metrics.torproject.org/onio= noo.html) > which uses ipfire's db as data source as well since recently. I just wanted to add something (potentially rather obvious here): We originally designed this project with the library which is where probably = the biggest value is. It comes with many features like: * Super fast lookup of any data because we store it in a quite smart way. * A simple C API so it can be integrated into many projects (and we have bind= ings for Python 3 and Perl, too). * One of the most important ones: It cryptographically verifies the database = when it is being updated. That way, it can be trusted as it not being downloa= ded from a random HTTP server. As far as I can see (couldn=E2=80=99t find any up to date source code) oniono= o is written in Java. Is that an obstacle and are there any blockers why libl= oc cannot be used apart from that there are no bindings for Java available? Best, -Michael > kind regards, > nusenu >=20 >=20 >=20 > --=20 > https://nusenu.github.io --===============8795848642075974342==--