maxmouchet

IP-to-ASN mappings are typically built from route collectors [2,3] that peer with various networks and receive their announcements. AFAIK route collectors don't filter anything and it's easy to find bogus announcements (e.g. private ASNs) in the data.

I can't find 4294967296 from a quick glance at the latest RouteViews data but I can find other private ASNs. For example AS7594 - AS2764 - AS4294901866 for 210.10.189.0/24 seen by the route-views.perth collector.

I don't know what kind of filtering iptoasn.com is doing but at work (ipinfo.io) we do filter bogus origins, as well as a bunch of other things like RPKI/IRR-invalid routes and hyper-specific prefixes (> /24 or /48) [4].

[1] https://bgpfilterguide.nlnog.net

[2] https://www.routeviews.org/routeviews/

[3] https://www.ripe.net/analyse/internet-measurements/routing-i...

[4] https://hyperspecifics.io

Comment · 2 years ago

Another solution is to use an MMDB (“MaxMind DB”) file [1] which is essentially a binary tree + deduplicated values (same as idea 3.1).

There are several free ASN MMDBs [2,3] but you can also build your own MMDB files from any Prefix->Value mapping with the mmdbwriter library [4] or a CLI tool built on top of it like mmdbctl [5].

Assuming the ASN MMDB is fully loaded in memory, it would use around 60MB.

[1] https://maxmind.github.io/MaxMind-DB/

[2] https://dev.maxmind.com/geoip/docs/databases/asn/

[3] https://ipinfo.io/products/free-ip-data-downloads

[4] https://github.com/maxmind/mmdbwriter

[5] https://github.com/ipinfo/mmdbctl

(I work for IPinfo, but there are lots of other companies offering MMDB files).

Comment · 2 years ago

I can't speak for AWS specifically, but in my PhD thesis [1] I found a bunch of such examples by using RIPE Atlas probes. Essentially looking for pairs of probes where the RTT between probe A and probe C is larger than probe A-B + B-C.

Now there are some issues with this methodology (all common issues with ICMP/RTT measurements + traffic was not really routed through the "relay" probe), but such pairs do exist.

[1] https://theses.hal.science/tel-03666771/document (see page 84 for an example; if you can read French :-))

Comment · 2 years ago

https://news.ycombinator.com/item?id=8018818 and https://github.com/philipl/pifs :-)

Comment · 2 years ago

Nice achievement but always a bit disappointing that those records are based on throwing more money at the problem, rather than new theoretical grounds, or software improvements (IIRC y-cruncher is not open source).

Comment · 2 years ago

Additionally, I would not expect such “baseline” changes in the minimum RTT to be due to variation in CPU processing time.

These changes are more typical of a physical path change, as suggested by the author.

CPU/soft processing latency would look more like additive noise.

I give some examples of RTT patterns in this talk: https://ripe77.ripe.net/archives/video/2250/

Comment · 2 years ago

Hosts with randomized addresses are likely to have auto-generated PTR records, or none at all, so for the purpose of rDNS resolution those are not a big issue.

And that’s a detail, but SLAAC as in RFC4842 is deterministic. The randomization is introduced by the privacy extensions in RFC4941.

Comment · 2 years ago

It works by querying a specific DNS resolver (dns.toys):

  dig +short TXT mumbai.weather @dns.google
  # NXDOMAIN
 
  dig +short TXT mumbai.weather @dns.toys  
  "Mumbai (IN)" "30.90C (87.62F)" "45.90% hu." "clearsky_day" "15:30, Sun"
  "Mumbai (IN)" "28.10C (82.58F)" "56.00% hu." "fair_day" "17:30, Sun"
  ...

Comment · 3 years ago

The same way glasses in restaurants are washed and reused :-)

Another solution is to bring your own cup.

Comment · 3 years ago

Rosetta is used to run the amd64 binaries, but not the (arm) kernel of the Docker VM.