Blocking of DNS, DoH, DoT servers (Google, Cloudflare, OpenDNS) in Russia

[wkrp]

This is a summary of information from an NTC thread, which was originally about the reported blocking of https://dns.google/, but which grew in scope as additional information became available.

Блокировка DoH сервера dns.google / Block of the dns.google DoH server

• Since about 2021-09-03, there have been reports of the blocking of DNS, DNS over HTTPS, and DNS over TLS servers in some, but not all, ISPs and cities in Russia.
• Blocking has been inconsistent, with the same server being sometimes accessible and other times blocked on the same ISP.
• Servers that have been tested and found to be blocked at some point:
  • Plaintext UDP DNS
    • 8.8.8.8
  • DNS over HTTPS
    • dns.google
    • doh.opendns.com
    • 1.1.1.1
  • DNS over TLS
    • dns.google
    • 1dot1dot1dot1.cloudflare-dns.com
• Some other DNS over HTTPS servers (AdGuard, Quad9) are not blocked anywhere.
• Blocking of DoH and DoT is by TCP RST after the TLS ClientHello. Blocking of plaintext UDP DNS is evidently by packet dropping, as queries time out.
  • TLS connections to the same IP address with a different SNI do not get RST.
  • The names of DoH and DoT servers resolve correctly.
• There are screenshots of emails circulating on Telegram that announces a plan to block exactly the three services that have been experiencing trouble in the past week (Google, Cloudflare, OpenDNS) on 2021-09-09 (tomorrow).

As far as I can tell, the email screenshots come from a post on Telegram: https://t.me/usher2/2106 https://t.me/usher2/2106?comment=9195. I don't really know how to use Telegram (it would be helpful if someone more adept can explore the channel and see if there is more information there), but I found an online viewer (archive) that shows the text of the main post:

#dnsживи 👉 Когда-то давно, когда ещё не было войны за Телеграм, все ещё казалось смешным и «они не смогут», в сеть утекла бумага Роскомнадзора с блоками IP Амазон: https://t.me/zatelecom/4071 Все посмеялись над этим фейком. Стоял весенний месяц март 2018 года

☝️ Но одна крупная и очень известная российская интернет-компания (история довольно публична, но не буду теребить имена) решила, что риски слишком высоки, и за пару недель аврала поставила между своими бэкендами в облаке Амазона и сервисами в России «прослойки», которые позволяли работать, в случае блокировки IP Амазона. 16 апреля 2018 года они ощутили... Что-то они ощутили.

❌ Эта бумага может быть блефом, фейком, фишингом, как и та в далеком 2018-ом. Мы до сих пор не знаем, была ли она. Но дата отключения Google DNS в России — 09 сентября 2021

#livedns 👉 Once upon a time, when there was still no war over Telegram, everything still seemed ridiculous and "they can't", a Roskomnadzor paper with Amazon IP blocks leaked online: https://t.me/zatelecom/4071 Everyone laughed at this fake. It was the spring month of March 2018

☝️ But one large and very famous Russian Internet company (the story is quite public, but I won't tease out names) decided that the risks were too high, and in a couple of weeks of a rush put "layers" between their backends in the Amazon cloud and services in Russia, which allowed them to work, in case Amazon's IP was blocked. On April 16, 2018, they felt... Something they felt.

❌ This paper could be a bluff, a fake, a phishing, just like that one back in 2018. We still don't know if it was. But the date of Google DNS shutdown in Russia is September 09, 2021.

Here are the screenshots themselves, followed by transcriptions and translations into English. Note that there must be more than one version of this email, since the overlapping parts of these pictures do not match exactly.

В целях противодействия угрозам устойчивости, безопасности и целостности функционирования на территории Российской Федерации информационно-телекоммуникационной сети «Интернет» и сети связи общего пользования Центром мониторинга и управления сетью связи общего пользования Федеральной службы по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор) планируется осуществление комплекса мер по ограничению доступа к ряду иностранных DNS-сервисов.

Перечень сервисов, к которым будут применяться ограничения по протоколам DNS DNS-over-HTTPS (DoH) и DNS-over-TLS (DoT):

• DNS-сервера Google (IP-адреса: 8.8.8.8, 8.8.4.4, dns.google);
• DNS-сервера Cloudflare (IP-адреса: 1.1.1.1, 1.0.0.1);
• сервис DoH Cisco (doh.opendns.com).

В целях исключения влияния на функционирование российских сервисов просим дать указание отраслевым организациям, входящих в контур Вашего управления, убедиться, что технологические сети, корпоративные сервисы и приложения не зависят от работы сервисов DNS, DNS-over-HTTPS (DoH) и DNS-over-TLS (DoT) вышеперечисленных ресурсов и для гарантированной работы DNS-сервиса в срок до 9 сентября 2021 года (срок установлен Роскомнадзором) по возможности подключиться к DNS-сервисам российских

In order to counter threats to the sustainability, security and integrity of the Internet information and telecommunications network and public communication network on the territory of the Russian Federation, the Center for Monitoring and Control of Public Telecommunications Network of the Federal Service for Supervision of Communications, Information Technology and Mass Media (Roskomnadzor) plans to implement a set of measures to restrict access to a number of foreign DNS services.

The list of services, which will be restricted by DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) protocols:

• Google DNS servers (IP addresses: 8.8.8.8, 8.8.4.4, dns.google);
• Cloudflare DNS servers (IP addresses: 1.1.1.1, 1.0.0.1);
• DoH Cisco service (doh.opendns.com).

In order to exclude any impact on the operation of Russian services, we kindly ask you to instruct sectoral organizations included in your control loop to make sure their technological networks, corporate services and applications do not depend on the functioning of DNS, DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) services of the above-listed resources and, in order to guarantee the functioning of DNS service, connect to Russian DNS services by September 9, 2021 (the deadline is set by Roskomnadzor) if possible

Перечень сервисов, к которым будут применяться ограничения по протоколам DNS, DNS-over-HTTPS (DoH) и DNS-over-TLS (DoT):
DNS-серверы Google (IP-адреса: 8:8:8:8, 8:8:4:4, dns.google);
DNS-серверы Cloudflare (IP-адреса: 1:1:1:1, 1:0:0:1);
Сервис DoH (doh.opendns.com).

Прошу проверить, что технологические сети, корпоративные сервисы и приложения не зависят от работы DNS, DNS-over-HTTPS (DoH) и DNS-over-TLS (DoT) перечисленных выше ресурсов.
Для гарантированной работы DNS-сервиса в срок до 09 сентября 2021г. необходимо подключиться к DNS-сервисам российских операторов связи или к Национальной системе доменных имён (НСДИ) по следующим IP-адресам: 195.208.6.1, 195.208.7.1, 2a0c:a9c7:‍a::1, 2a0c:a9c7:‍b::1.
Инструкция по подключению к НСДИ находится на Едином портале пользователей Центра мониторинга и управления сетью связи общего пользования (ЕПП ЦМУ ССОП) в разделе «Предоставление информации согласно приказам Роскомнадзора» по ссылке https://epp.noc.gov.ru/information.
По вопросам подключения просим при необходимости обращаться в круглосуточную дежурную смену ЦМУ ССОП по тел.: +7(495)748-13-18 или по электронной почте: ndr@noc.gov.ru. 2
Консолидированную информацию о проведении проверки DNS-сервисов и о наличии/отсутствии использования вышеуказанных иностранных DNS-сервисов в дивизионах/дирекциях прошу предоставить в электронном виде в срок до 20.09.2021

List of services to which DNS, DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) restrictions will apply:
Google DNS servers (IP addresses: 8:8:8:8, 8:8:4:4, dns.google);
Cloudflare DNS servers (IP addresses: 1:1:1:1:1, 1:0:0:1);
DoH service (doh.opendns.com).

Please verify that technology networks, corporate services, and applications are not dependent on the DNS, DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) resources listed above.
In order to guarantee DNS service operation it is necessary to connect to the DNS services of the Russian telecom operators or to the National Domain Name System (NSDI) by the following IP addresses by September 09, 2021: 195.208.6.1, 195.208.7.1, 2a0c:a9c7:‍a::1, 2a0c:a9c7:‍b::1.
Instructions on how to connect to NSDI can be found on the Single User Portal of the Public Switched Communications Network Monitoring and Control Center (EPP CMU SSOP) in the "Providing information according to Roskomnadzor orders" section at https://epp.noc.gov.ru/information.
If you have any questions regarding connection, please contact the 24/7 duty shift of the CMU SSOP by phone: +7(495)748-13-18 or by email: ndr@noc.gov.ru. 2
Please provide consolidated information about DNS checking and availability/absence of use of the above-mentioned foreign DNS services in divisions/directories in electronic form by 20.09.2021

[wkrp]

There was an apparent temporary block of Google and Cloudflare DNS servers on 2021-09-08 from 18:00 to 19:00 (21:00 to 22:00 Moscow Time) in some Russian ISPs.

https://vc.ru/tech/291648-it-specialisty-zayavili-o-testirovanii-roskomnadzorom-massovoy-blokirovki-publichnyh-dns-servisov-google-i-cloudflare (archive)

ИТ-специалист команды Алексея Навального Артём Ионов рассказал, что блокировка производилась 8 сентября с 21:00 до 22:00 на нескольких крупных провайдерах с использованием технических средств противодействия угрозам (ТСПУ) — их операторы должны устанавливать по закону об «суверенном рунете».

О частичной блокировке DNS-сервисов Google и Cloudflare также сообщил своём Telegram-канале эксперт «Общества защиты интернета» Михаил Климарёв. Он отметил, что полностью был заблокирован и VPN-протокол WireGuard.

Artyom Ionov, an IT specialist for Alexei Navalny's team, said that the blocking was carried out on September 8 from 9:00 to 10:00 p.m. on several major providers using technical means of countering threats (TSPU) - operators must install them under the law on "sovereign runet".

The partial blocking of Google and Cloudflare DNS services was also reported on his Telegram channel by Mikhail Klimarev, an expert of the Internet Defense Society Mikhail Klimarev. He noted that the WireGuard VPN protocol was also completely blocked.

From what I can gather, the immediate cause of these blocks and threatened blocks of DNS may be a specific Smart Voting (Умное голосование) app and the legislative elections that will happen this weekend. According to discussion on NTC, the app hardcoded Google, Cloudflare, and OpenDNS DNS resolvers, which would explain why those specific resolvers are targeted, and not others. It is reported by TASS that Roskomnadzor wrote letters to foreign technology companies and DNS providers, naming Google, Cloudflare, and Cisco specifically, and warning not to permit access to the Smart Voting app and web site.

https://tass.ru/obschestvo/12345663 (archive)

"Роскомнадзор и Центр мониторинга управления сетями связи общего пользования РФ (ЦМУ ССОП РФ) на основании требований Центральной избирательной комиссии и Генеральной прокуратуры России направили в адрес ряда иностранных компаний, в том числе провайдерам DNS- и CDN-сервисов, письма с требованиями прекратить предоставление возможностей для обхода ограничения доступа к приложению и сайту "Умное голосование" на территории Российской Федерации", - сказали в пресс-службе.

...

Кроме того, Роскомнадзором и ЦМУ ССОП РФ установлено, что средства обхода блокировок предоставляют более 10 иностранных провайдеров, расположенных на территории США, Украины, Германии, Франции, Японии, Великобритании и других государств. Законные требования о недопустимости предоставления технических средств для обхода ограничения доступа игнорируются магазинами приложений компаний Apple и Google, DNS- и CDN-сервисами Google, Cisco, Cloudflare и ряда других компаний. Для пресечения распространения средств незаконной агитации, а также исключения возможности иностранного вмешательства в любых формах в избирательную кампанию доступ к упомянутым ресурсам должен быть ограничен, подчеркнули в РКН.

"Roskomnadzor and the Public Communications Network Management Monitoring Center of the Russian Federation (CMU SSOP RF) have sent letters to a number of foreign companies, including providers of DNS and CDN services, with demands to stop providing opportunities to circumvent access restrictions to the "Smart Voting" app and website in the Russian Federation," the press-service said.

...

In addition, Roskomnadzor and the CMU SSOP RF found that more than 10 foreign providers located in the United States, Ukraine, Germany, France, Japan, the United Kingdom and other countries provide blocking circumvention tools. Legal requirements regarding the inadmissibility of providing technical means to bypass access restrictions are ignored by Apple and Google app stores, DNS and CDN services of Google, Cisco, Cloudflare and a number of other companies. In order to prevent the spread of means of illegal campaigning, as well as to exclude the possibility of foreign interference in any form in the election campaign, access to the above-mentioned resources should be limited, the RKN stressed.

[wkrp]

NTC users have posted a letter from Roskomnadzor (dated 2021-09-08) that prohibits configuring Google, Cloudflare, and OpenDNS resolvers for subscribers, and a news post from the ISP SkyNet (dated 2021-09-13) telling customers that if they have Internet problems, the first thing they should do is configure their DNS to a resolver other than 8.8.8.8 or 1.1.1.1.

• https://ntc.party/t/doh-dns-google/1265/41 (translation)
• https://ntc.party/t/doh-dns-google/1265/47 (translation)

The Roskomnadzor letter, and the earlier email screenshot, recommend the use of National Domain Name System resolvers:

• 195.208.6.1
• 195.208.7.1
• 2a0c:a9c7:‍a::1
• 2a0c:a9c7:‍b::1

Anyone who does DNS measurements, this could be an opportunity to test these resolvers and see what queries they resolve incorrectly.

[gfw-report]

The Roskomnadzor letter, and the earlier email screenshot, recommend the use of National Domain Name System resolvers:

195.208.6.1
195.208.7.1
2a0c:a9c7:‍a::1
2a0c:a9c7:‍b::1

Anyone who does DNS measurements, this could be an opportunity to test these resolvers and see what queries they resolve incorrectly.

We sent DNS queries to 195.208.6.1 and 195.208.7.1 from the outside of Russia. We haven't been able to observe any "incorrect" answers yet. Actually the resolvers responded no answer RR as they are non-recursive. The responses indeed include authority RRs and additional RRs though, which appears to be correct.

This is an example DNS query to 195.208.6.1:

dig +recurse @195.208.7.1 www.google.com

; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24020
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.google.com.			IN	A

;; AUTHORITY SECTION:
com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
com.			172800	IN	NS	c.gtld-servers.net.
com.			172800	IN	NS	d.gtld-servers.net.
com.			172800	IN	NS	e.gtld-servers.net.
com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	h.gtld-servers.net.
com.			172800	IN	NS	i.gtld-servers.net.
com.			172800	IN	NS	j.gtld-servers.net.
com.			172800	IN	NS	k.gtld-servers.net.
com.			172800	IN	NS	l.gtld-servers.net.
com.			172800	IN	NS	m.gtld-servers.net.

;; ADDITIONAL SECTION:
a.gtld-servers.net.	172800	IN	A	192.5.6.30
b.gtld-servers.net.	172800	IN	A	192.33.14.30
c.gtld-servers.net.	172800	IN	A	192.26.92.30
d.gtld-servers.net.	172800	IN	A	192.31.80.30
e.gtld-servers.net.	172800	IN	A	192.12.94.30
f.gtld-servers.net.	172800	IN	A	192.35.51.30
g.gtld-servers.net.	172800	IN	A	192.42.93.30
h.gtld-servers.net.	172800	IN	A	192.54.112.30
i.gtld-servers.net.	172800	IN	A	192.43.172.30
j.gtld-servers.net.	172800	IN	A	192.48.79.30
k.gtld-servers.net.	172800	IN	A	192.52.178.30
l.gtld-servers.net.	172800	IN	A	192.41.162.30
m.gtld-servers.net.	172800	IN	A	192.55.83.30
a.gtld-servers.net.	172800	IN	AAAA	2001:503:a83e::2:30
b.gtld-servers.net.	172800	IN	AAAA	2001:503:231d::2:30
c.gtld-servers.net.	172800	IN	AAAA	2001:503:83eb::30
d.gtld-servers.net.	172800	IN	AAAA	2001:500:856e::30
e.gtld-servers.net.	172800	IN	AAAA	2001:502:1ca1::30
f.gtld-servers.net.	172800	IN	AAAA	2001:503:d414::30
g.gtld-servers.net.	172800	IN	AAAA	2001:503:eea3::30
h.gtld-servers.net.	172800	IN	AAAA	2001:502:8cc::30
i.gtld-servers.net.	172800	IN	AAAA	2001:503:39c1::30
j.gtld-servers.net.	172800	IN	AAAA	2001:502:7094::30
k.gtld-servers.net.	172800	IN	AAAA	2001:503:d2d::30
l.gtld-servers.net.	172800	IN	AAAA	2001:500:d937::30
m.gtld-servers.net.	172800	IN	AAAA	2001:501:b1f9::30

;; SERVER: 195.208.7.1#53(195.208.7.1)
;; MSG SIZE  rcvd: 839

[ValdikSS]

@gfw-report

We sent DNS queries to 195.208.6.1 and 195.208.7.1 from the outside of Russia. We haven't been able to observe any "incorrect" answers yet. Actually the resolvers responded no answer RR as they are non-recursive.

The resolvers actually used to work in the beginning of September, both from and outside of Russia. I don't know what has happened with them, and why.

[wkrp]

We sent DNS queries to 195.208.6.1 and 195.208.7.1 from the outside of Russia. We haven't been able to observe any "incorrect" answers yet. Actually the resolvers responded no answer RR as they are non-recursive. The responses indeed include authority RRs and additional RRs though, which appears to be correct.

Although it's not what we usually see, I suppose a non-recursive DNS resolver could equally be used for censorship. For a censored query, the resolver could return an empty or incorrect list of NS records. It could even be a deliberate design choice to reduce load and complexity at the censoring resolver, pushing the DNS traffic for non-censored queries onto third-party resolvers.

However, such an approach to censorship would not work if the downstream resolver practices QNAME minimization: in that case, of a query for www.example.com, the resolver would only see the com part and would not know whether to apply its censorship rules. But I'm guessing that clients do not minimize their queries when a resolver is configured as the immediate upstream recursive resolver (e.g. in /etc/resolv.conf).