DNSFS and PingFS

The other day I came across this fun read – DNSFS. Store your files in others DNS resolver caches. And this bit in the article really cracked me up:

This is not the first time something like this has been done, Erik Ekman made PingFS, a file system that stores data in the internet itself .

This works because inside every ping packet is a section of data that must be sent back to the system that sent the ping, called the data payload.

Because you can put up to 1400-ish bytes in this payload, and pings take time to come back, you can use the speed of light in fiber as actual storage.

Now obviously this is not a great idea for long term data storage, since you have to keep transmitting and receiving the same packets over and over again, plus the internet gives no promise that the packet won’t be dropped at any time, and if that happens then the data is lost.

However. DNS has caches. It has caches everywhere.

Obviously, neither DNSFS, nor PingFS should be used for anything serious, but both are excellent experiments, demonstrating the flexibility of the TCP/IP and thinking outside the box.

Telegram’s description of DDoS attack is the best

The servers of Telegram, a popular instant messenger, were under a DDoS attack recently. While they were working on the problem, they’ve tweeted a couple of explanations of what’s going on. CNET brings those tweets to our attention, as they explain rather complex things in a very short and simple way.

Ansible + AWS + GraphViz = aws-securitygroup-grapher


aws-securitygroup-grapher is a handy tool that can generate a variety of graphs visualizing Amazon Security Groups. It is implemented as an Ansible role and uses GraphViz to produce the results.

This is particularly useful when you need to get familiar with a complex VPC setup by someone else, or when you want to review the results of an automated setup.

Packets-per-second limits in EC2

Packets-per-second limits in EC2” is an interesting dive into network limits on the Amazon EC2. Even if you aren’t hitting any limits yet, this article provides plenty of useful information, including benchmarking tools and quick reference links for Enhanced Networking.

The conclusion of the article is:

By running these experiments, we determined that each EC2 instance type has a packet-per-second budget. Surprisingly, this budget goes toward the total of incoming and outgoing packets. Even more surprisingly, the same budget gets split between multiple network interfaces, with some additional performance penalty. This last result informs against using multiple network interfaces when tuning the system for higher networking performance.
The maximum budget for m5.metal and m5.24xlarge is 2.2M packets per second. Given that each HTTP transaction takes at least four packets, we can translate this to a maximum of 550k requests per second on the largest m5 instance with Enhanced Networking enabled.

How to disable IPv6 on CentOS / RHEL 7

Sometimes I miss the good old days …

Recently, I had an issue with one of the servers, where a bunch of services were attaching to IPv6 ports instead of the IPv4 ones. Rather than editing the configuration of each of these services, I wanted to simply disabled IPv6 on the machine.

In the old good days, things like these were easily done via the sysctl. I surely tried that option too, but it wasn’t enough. Turns out, the proper way these days is to do this via Grub, as per this blog post:

  1. Vim /etc/default/grub file
  2. Change: GRUB_CMDLINE_LINUX=”ipv6.disable=1 crashkernel=auto rhgb quiet”
  3. Regenerate and overwrite Grub config with: grub2-mkconfig -o /boot/grub2/grub.cfg
  4. Reboot.

That sounds a bit too excessive. But then again a reboot is also required for the proper disabling of SELinux, so I guess its’ fine.