Strange DNS behaviour

[fruchtenstein 0]

Hi, folks,
I observe a strange behavior when trying to bypass DNS-based site blocking in Russia. The name flibusta.is gets unexpectedly resolved to the ban site lawfilter.ertelecom.ru.

I use openvpn under Debian Linux.
OpenVPN 2.5.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Oct 31 2020
Configuration files are downloaded from airvpn.org generator.
By default, /etc/resolv.conf contains the following:
nameserver 192.168.1.1
When I connect to VPN, the settings do not change. My browser (Firefox 84) is configured to use DNS over HTTPS, but I can also change /etc/resolv.conf to use the Cloudflare DNS:
nameserver 1.1.1.1

Now, I run tcpdump to capture all DNS exchange and try to open flibusta.is in the browser.
Here's what I get:
19:32:41.326041 Out ethertype IPv4 (0x0800), length 73: 10.7.213.47.41548 > 1.1.1.1.53: 38651+ A? flibusta.is. (29)
19:32:41.326052 Out ethertype IPv4 (0x0800), length 73: 10.7.213.47.41548 > 1.1.1.1.53: 2303+ AAAA? flibusta.is. (29)
19:32:41.345679 Out ethertype IPv4 (0x0800), length 84: 10.7.213.47.37238 > 1.1.1.1.53: 25045+ A? lawfilter.ertelecom.ru. (40)
19:32:41.345690 Out ethertype IPv4 (0x0800), length 84: 10.7.213.47.37238 > 1.1.1.1.53: 13267+ AAAA? lawfilter.ertelecom.ru. (40)
19:32:41.471163  In ethertype IPv4 (0x0800), length 100: 1.1.1.1.53 > 10.7.213.47.37238: 25045 1/0/0 A 188.186.157.49 (56)
19:32:41.619187  In ethertype IPv4 (0x0800), length 149: 1.1.1.1.53 > 10.7.213.47.41548: 2303 0/1/0 (105)
19:32:41.619205  In ethertype IPv4 (0x0800), length 128: 1.1.1.1.53 > 10.7.213.47.37238: 13267 0/1/0 (84)
19:32:41.619214  In ethertype IPv4 (0x0800), length 89: 1.1.1.1.53 > 10.7.213.47.41548: 38651 1/0/0 A 81.17.19.227 (45)

10.7.213.47 is the address of the VPN interface. The request seems to go through VPN to Cloudflare, but for some reason it resolves to lawfilter.ertelecom.ru. This response gets inserted between request and the correct response (the last line).
But this doesn't happen every time. Sometimes, after re-establishing VPN connection, tcpdump captures the correct response:
19:53:46.028205 Out ethertype IPv4 (0x0800), length 73: 10.20.213.58.38277 > 1.1.1.1.53: 10615+ A? flibusta.is. (29)
19:53:46.028224 Out ethertype IPv4 (0x0800), length 73: 10.20.213.58.38277 > 1.1.1.1.53: 4978+ AAAA? flibusta.is. (29)
19:53:46.121195  In ethertype IPv4 (0x0800), length 89: 1.1.1.1.53 > 10.20.213.58.38277: 10615 1/0/0 A 81.17.19.227 (45)

So, basically, there are two things I can't understand. First, why the browser seems to ignore DOH settings, sending requests via plain UDP. But it is not related to VPN, so, let's not bother ourselves with this one. The second question is how the DNS request sent via VPN gets a spoofed response from the provider's blocker? Am I simply doing something wrong?
 

Edited ... by fruchtenstein

[OpenSourcerer 1435]

5 hours ago, fruchtenstein said:

Now, I run tcpdump to capture all DNS exchange and try to open flibusta.is in the browser.

tcpdump is not the right tool to troubleshoot DNS. Try dig.

$ dig a in flibusta.is +trace

On Debian, this is not installed by default.

# apt-get install dns-utils

Try your luck with that, see if you're getting more out of it.

[fruchtenstein 0]

Thanks. Next time I get the same issue, I'll check the output of 'dig'.