Re: incorporation state of ARIN's asn.txt / LACNIC AS name data

[nusenu <nusenu-lists@riseup.net>]

[-- Attachment #1: Type: text/plain, Size: 2728 bytes --]

Hi Peter,

thanks for your comprehensive reply.

Peter Müller 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. :-)

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?

I understand AS name as the name attribute of the AutNum WHOIS object.

to use an example again:
"DIGITALOCEAN-ASN" is the AS name of AS14061 according to [1], WHOIS [2] and well
established tools like RIPEstat show the very same string [3].

[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=AS14061

> 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.

with regards to LACNIC: Maybe their bulk whois data is something you
find useful? (I didn't use it myself)

https://www.lacnic.net/en/web/lacnic/manual-8
https://github.com/microsoft/WhoisParsers/blob/fb54e3cf576e5caa4d2f8e0c15768925d14dc464/WhoisDownload/WhoisDownload.cs#L45

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.


>  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.

Do you have a rough estimate on when this next version will be released?


> 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.

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/onionoo.html)
which uses ipfire's db as data source as well since recently.

kind regards,
nusenu



-- 
https://nusenu.github.io