ValdikSS

1. Домен IN-ADDR.ARPA это реальный физический домен, который где-то находится, и обслуживается реальными людьми, или это абстрактное название, которое просто зарезервировано под использование для E-Mail, наравне с 192.168..., 172.27... и 127.0.0.1?

in-addr.arpa — реальный существующий домен. PTR — понятие DNS, к email оно имеет только косвенное отношение (email использует ptr-записи для ip-адресов).
Когда вы делаете traceroute на какой-то IP-адрес, имена доменов, которые вы видите в выводе, получаются путём запроса PTR-записи IP-адреса:

traceroute to ya.ru (87.250.250.242), 30 hops max, 60 byte packets
 1  _gateway (192.168.101.1)  49.797 ms  119.433 ms  119.416 ms
 2  hosted-by.yourserver.se (95.215.45.5)  119.308 ms  119.242 ms  119.179 ms
 3  stk-tct-cr3.be22-1841.rascom.as20764.net (81.27.252.200)  166.091 ms  165.839 ms  165.776 ms
 4  * * *
 5  178.18.226.119.ix.dataix.ru (178.18.226.119)  165.459 ms  165.345 ms  165.312 ms
 6  * ya.ru (87.250.250.242)  79.669 ms *

PTR был, пожалуй, первой технологией защиты от спама со взломанных серверов или недоверенных сетей, но только потому, что его «нетривиально» сменить в общем случае, когда у совершающего рассылку нет на это полномочий.

2. Почему в PTR записях IP адреса записываются в обратном порядке? Какой в этом смысл?

Лёгкость хранения «обратного» дерева в памяти DNS-сервера, быстрый поиск записей. Скорее, технологическая особенность 80-х, а не необходимость.

3. Есть ли какой-то софт, позволяющий моделировать сети, скажем поднимать несколько виртуальных машин, и настраивать им разные роли. Например одну сконфигурировать как провайдера, другую как просто компьютер и т.д, чтобы наглядно моделировать взаимодействие в сети интернет, и больше не задавать подобные вопросы здесь

Зависит от того, что конкретно вам нужно моделировать. См. в сторону Cisco Packet Tracer, gns3.

Но не могу понять, как это, что значит децентрализованный сервис

Буквально — сервис, у которого нет какой-то единой точки, с которой он загружается, выполняется, и т.п., а вместо них — множество точек, напрямую не подконтрольных администратору этого сервиса.

У вас есть очень смешной видеоролик, вы загружаете его на свой сервер и выкладываете ссылку в интернете. Проходит какое-то время, ролик вам надоел, вы его удаляете с сервера, и его больше никто не может скачать по вашей ссылке.
Если бы вы использовали децентрализованный BitTorrent вместо централизованного сервера, вы бы делились magnet-ссылкой в интернете, и каждый скачавший файл продолжал бы его раздавать. Файл можно бы было скачать даже после того, как вы удалили его со своего компьютера, и он продолжит раздаваться до тех пор, пока есть хотя бы один человек, который продолжает его раздавать.

его же все равно кто-то должен администрировать

Децентрализованный сервис может иметь администраторов и модераторов, а может и не иметь, это зависит от типа и особенностей реализации сервиса. В одном случае сервис не предполагает никакого управления ни создателем, ни участниками (BitTorrent), в другом — может иметь глобальное или локальное (самим пользователем) модерирование. Идея децентрализации ценна неподконтрольностью, но это не её свойство. Вы вполне можете сделать децентрализованный сервис с централизованным управлением (DNS, Tor).

ZeroNet — самый серьёзный Web 3.0-проект, который мне известен. Принцип его работы похож на BitTorrent — каждый заходящий на сайт скачивает всю основную информацию полностью, и начинает раздавать сайт после скачивания. Сайт полностью подконтролен его администратору, он управляет содержимым, функциями, возможностями. ZeroNet предоставляет функции аутентификации пользователей, добавления определенных данных на сайт, работы с данными, что позволяет создавать динамические сайты с возможностью добавления информации от пользователей. Администратор настраивает сайт так, чтобы пользователи могли добавлять данные заданного формата по заданному протоколу, что выливается в блоги с комментариями, форумы, чаты, социальные сети, и т.п.

кто-то должен администрировать, как это происходит

Чаще всего так или иначе используется доверенная сторона, чей публичный криптографический ключ известен всем, внесён в сам сервис или программу, которому система доверяет полностью или в определённой мере. Администратор совершает какие-то операции, подписывает их цифровой подписью и рассылает в сеть, другим пользователям децентрализованного сервиса. У других пользователей нет ключа (приватной части) для подписи этих операций, поэтому они не могут выполнять то же, что может владелец сервиса.

В ZeroNet, например, администратор имеет полный контроль над добавленными другими пользователями на свой сайт данными, может их удалять или модифицировать. Также, так как это самый обычный сайт с точки зрения браузера, на сайте может быть инструмент локального модерирования самими пользователями: возможность скрытия определенных сообщений, сообщений от определенного пользователя, и т.п.

Как будет выглядеть децентрализованный мессенджер или социальная сеть например?

Такой «мессенджер» существует почти столько же, сколько существует интернет — email. Протокол почты использует частный случай децентрализации — федерацию. Нет единого «центра email», а существуют множество почтовых серверов, которые обмениваются между собой письмами. У каждого отдельного сервера есть администратор, но никто не управляет email глобально.