Infocom unprovisions the Samara reverse proxy

December 18, 2017

Infocom unprovisions the Samara technical setup

days before the Press Conference

Until the 9th of December 2017, has managed their domain using a third party free infrastructure from Yandex This weak outsourced setup seems surprising for a State Enterprise that claims to follow high standards of computer security.

Until then, the State Enterprise (SE) Infocom  has run all the State Registration Services (SRS) as part of a small network suballocation in the space allocated to the IET KSTU.

inetnum: -
netname: IET_KSTU
descr: IET_KSTU Office Network
country: KG
admin-c: AU2408-RIPE
tech-c: IM5222-RIPE
mnt-by: AS12764-MNT
created: 2013-06-21T03:13:56Z
last-modified: 2013-06-21T03:13:56Z
source: RIPE

It was inside this small network where we discovered the reverse proxy that hosted and later

The 14th of December took place in Bishkek the press conference where SRS announced officially  the long awaited results of their “Samara” internal investigation:  “Trust us, no evidence was found”.

But in a surprising last minute turn in this case, Infocom decided to migrate all the services in their network to a new setup removing the reverse proxy from the address


Ops! The reverse proxy address is now gone.

The morning of the 8th of December, Infocom started the migration of their services to a new allocated IP space obtained from RIPE as a new LIR in middle November. The route was present in the BGP routing table for first time the 18th of November 2017.


All services were moved to the new fresh network and Infocom stopped using the AS12764 to operate its own AS39659.


This new IP space is managed by Azamat Soyuzbekov ( Азамат Союзбеков ) that according to his social media profile he is a former worker of ОсОО Нуртелеком, and Мегаком

During the weekend before the press conference, the domain zone in was initially updated with the new SOA counter record 2017120801. On Saturday 9th,  two more DNS servers were added and to the pool and using a completely different SOA record 2017112912 (problably these ones were initially configured the 29th of November)

A SOA flawed new DNS setup

It seems that this new setup has been done in a hurry, judging for the several consistency problems that they have encountered and the current errors in this new configuration as described here