Telegram and/or DoH tunnel services affected by Google Public DNS DoH migration to anycast IP addresses

[dupuy]

The Telegram app (or derived versions of it) uses Google Public DNS over HTTPS (DoH) queries to resolve domains. In aggregate it represents a significant component of DoH traffic to the Google Public DNS service. As part of the restructuring of the DoH service announced in June Google updated the dns.google.com domain name to resolve to its anycast IP addresses (8.8.8.8 etcetera) and this completed several weeks ago.

As a result of this change, DoH clients that resolve the dns.google.com domain to determine the IP addresses to use for DoH switched to the anycast addresses rather than the distributed addresses previously returned by resolving dns.google.com. However, only some of the DoH traffic to Google Public DNS has switched over, with many DoH clients still using the distributed addresses.

Next week, Google is turning down DoH support from the distributed addresses, which will no longer return DoH responses but rather HTTP 301 redirects to dns.google (which has always resolved to the anycast addresses). At that point, the only way to use the DoH service of Google Public DNS will be to send queries to the Google Public DNS anycast addresses, which will accept DoH queries for either dns.google or dns.google.com.

Google does not want to disrupt any significant part of the Google Public DNS DoH client base, and it is concerning that a large percentage of DoH traffic is still using the distributed addresses, which will no longer work after the next stage of the turndown. It appears that in some locations where state authorities may block encrypted access to the Internet, Telegram users may be using DoH/HTTPS proxy/tunneling services on other IP addresses (and those services could be forwarding the DoH queries to Google Public DNS using the distributed addresses).

At this time, the vast majority of DoH queries being received by Google Public DNS via DoH on distributed addresses have this User-Agent header:

Mozilla/5.0 (iPhone; CPU iPhone OS 10_0 like Mac OS X) AppleWebKit/602.1.38 (KHTML, like Gecko) Version/10.0 Mobile/14A5297c Safari/602.1

with a much smaller number of queries using a similar User-Agent header:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36

The exact string of the more popular iPhone version of these user agent strings appears in the Ruby source of the GitHub Gist jefmathiot/telegram-dns. No exact copy of the Windows variant has been found.

If anyone is in contact with the people, or knows of software or services using these User-Agent headers, please encourage them to contact Google though the restricted issue tracker for Google Public DNS to discuss their plans to migrate away from the Google Public DNS distributed DoH IP addresses, and in any case to alert them to the imminent shutdown of the DoH service on those addresses.

[catfluoride]

Excuse me for the slightly OT question, but does this mean that Telegram relies on hardcoded DNS to resolve domains? I prefer to avoid using anything from google and for the moment I blocked dns.google and dns.google.com on my pihole and everything seems to work anyway.

[thermatk]

@catfluoride No, it doesn't

[catfluoride]

@thermatk Thanks for your response

[ghost]

@catfluoride Telegram uses TCP/IP and Google is used for domain fronting to circumvent censorship. Just block Google domains completely including dns.google with hosts, telegram won't break.

[Shituation]

n fronting to circumvent censorship. Just block Google domains completely including dns.google with hosts, telegram won't break.

Using Rethink DNS + firewall. I don't like what I see here.

While circumventing censorship is ok, using google dns and general unsecure DNS is not privacy friendly. Also the app doesn't use end2end encryption by default...

is Telegram is starting to behave like whatsapp? In my case, blocking any of those ip's completely breaks telegram.

[chrcoluk]

Same on windows.

I had setup two rules in pfsense, one to block unauthorised DoH queries on guest LAN, and on my normal LAN initially I allowed it but audited it, to see if any leaks.

Then started seeing these.

Oct 31 03:27:46 | LAN | audit DoH dns bypass (1638303360) | 192.168.1.124:20062 | 8.8.4.4:443
Oct 29 07:26:53 | LAN audit DoH dns bypass (1638303360) | 192.168.1.124:28625 | 104.16.249.249:443

I then on windows firewall control on my windows desktop setup a block rule to the mainstream DoH ip's that are publicly known, basically grabbed them from my pfsense rules. Waited some days, and sure enough I seen queries blocked by telegram.exe.

These were only to the coudflare addresses, so I suspect the 8.8.4.4 might have been another app, but telegram is the offender I have caught.

The obvious problem with DoH is that it can be abused in this manner to circumvent firewall policies using a commonly used https port, and its a shame telegram is doing this. The right behaviour is to use the OS configured DNS server, and if this feature is to be added, it should be a visible option the end user can toggle.

For me telegram is still working with the direct DoH qeuries blocked, its either falling back to a DoH DNS ip I dont know off, or falling back to my own configured DNS.