DNS SERVFAIL for servers with Cloudflare's name servers (gray and orange cloud)

[arandomgstring]

It has been already known that servers behind Cloudflare's CDN are blocked, either at IP level or with DNS poisoning, nothing new here.

The servers without Cloudflare's CDN (aka gray cloud) which only use Cloudflare as their DNS propagator were fine till now, however, it's been at least two days since I am experiencing DNS poisoning for such servers in some ISPs (most notably in TIC or the so called Mokhaberat). This usually happens at ~5:30 AM till ~11AM. The solution is quite easy, one can either use host file or plain DNS requests from 8.8.8.8 or 1.1.1.1, both works fine and fix the issue.

That said, what's the reasoning behind such DNS poisoning in the first place? It will only disrupt the traffic of legitimate websites. Is it just some kind of mistake from their part? or are they testing something? Maybe they want to force users to use Arvancloud? Whatever their reasoning is,

if they actually make this change permanent, and they block even plain DNS requests from Cloudflare and Google (or make them useless with bogon IPs), inevitably people will be forced to use Arvancloud, linking their real life identity with the servers they own, which will put them in danger of making proxies in the first place. Host file could be a solution; but distribution of proxy among normal people will become harder, as normal people would need to modify their host file; which is easy but a pain nevertheless. At the worst case scenario, ISPs might only allow users to connect to foreign IPs that they have got through plain DNS request. That can potentially make host file useless (I guess? because with host file, DNS resolution will be done locally), although since many applications (e.g Browsers) cache DNS responses, that may or may not be feasible.

I tested a few proxy servers on cloud-flare with gray cloud; I can't obviously share either of their IP or domains. That said, even legitimate well-known websites are affected by this type of DNS poisoning. For example:

and nslookup & dig returned no result for this legitimate web server. This server is behind cloudflare CDN (orange cloud). I couldn't think of any way to find servers with gray cloud, except those of which I own.

[alirezaac]

Well hello again to persisting issue here and if anyone can access naive developer plz ask him handle dns proper cause chromium acts on its request differently. and i see some idiot spam genius who says its cipher its fingerprint, its alien tech plz let's fix lvl by lvl and you still email man? cause nowadays it can be fixed only by that type of dns thing i emailed you before.

[wkrp]

It's interesting that the IP address 127.154.0.92 is returned. All of 127.*.*.* is localhost, which is why ping reports a round-trip-time of <1 ms. In Turkmenistan the firewall injects 127.0.0.1, but I think this is the first time I've seen localhost addresses other than 127.0.0.1 being used.

You say that direct plaintext DNS queries sent directly to a foreign resolver (such as 1.1.1.1 or 8.8.8.8) do not get false responses. That tells me that it is the Iranian ISP resolver that is creating the false DNS response. In other words, it's not like the familiar injection of the IP address 10.10.34.34 into DNS responses. If you look at a packet capture, do you see only 1 DNS response (127.*.*.*), or 2 responses (127.*.*.* and the real one)?

Cloudflare makes their IP ranges public: https://www.cloudflare.com/ips/. I was going to guess that the ISP resolvers are replacing any DNS responses with an IP address in that range (orange cloud), but you say that it affects even websites that don't use Cloudflare for proxying but only for DNS service (gray cloud). In that case they may be filtering for upstream DNS queries addressed to ns1.cloudflare.com, ns2.cloudflare.com, etc.

What's the reasoning? It doesn't make sense to me either. I would guess it's a mistake, maybe an attempt to block something else.

[arandomgstring]

@wkrp

These website couldn't be opened on different devices (PC, Android) nxdomain-noreach, dns prob, etc were their errors. On Irancell, a different ISP, no such problem was present at that day, but in another day I could observer a similar problem. And with a VPN they could be opened, so I don't think it was a problem from my part, it was ISP's fault.

If you look at a packet capture, do you see only 1 DNS response (127...), or 2 responses (127... and the real one)?

In Wireshark what I could see was a single response contained a "no response" as a response for DNS queries to these particular hosts. Maybe the Windows itself replaces no response with local-addresses? I am not sure. But I couldn't see bogon IPs on Wireshark DNS queries either, which confuses me even more. Hopefully they repeat this, and this time I will share packets.

@alirezaac
They did use TLS fingerprint blocking though. For example, on Irancell, every time that I used utls = chrome I couldn't connect to my VLESS + TLS + WS + NGINX setup, 2 weeks ago. On ults = firefox everything was OK. However, I think they understood their mistake, since some websites were broken because of this, and now even utls = chrome works fine.

It seems that they have focused their attention on DNS. I haven't used naive personally, but @Nyxil says that naive TLS handshaking fails in this topic klzgrad/naiveproxy#404 which has nothing to do with DNS. Also I can't check my email frequently because it's a TOR based email. Often, It becomes inaccessible .

[alirezaac]

@arandomgstring well whatever it is working it has bug in android plugin that keep using 8.8.8.8 plain and they dont fix it, and it is working fine and that ssl error even

so that guy kept shizo shit issuing but people have it in china too but its working in iran its dns that is failing but ok keep concentrating on one method and see the result on the long run.

[MH140000]

Hello. Can this problem be solved? I have a domain set up on cloudflare and I created an a record for it, but since a few days ago when I test the subdomain ping in windows I get an error

[seakfind]

Does it work to use an alternative CDN? https://palitechsociety.blogspot.com/2022/11/xray-vless-ws-tls-gcore.html

[arandomgstring]

@MH140000
Is your cloud in cloudflare "orange" or is it "gray"? If it's orange, turn it off. The IP of cloudflare has been banned. If your cloud is gray, then go to c:\Windows\System32\Drivers\etc and open hosts with notepad. At the end of it add

xx.xx.xx.xx yourdomain.com

Ofcourse xx.xx.xx.xx is your server IP address, and yourdomain.com is your domain that I am not aware of. Then open cmd, and run ipconfig /flushdns. Ping your domain again. Do you get timeouts again? Ping your server IP address directly. Do you see timeouts? If so, you need to buy another VPS.

[wkrp]

I have a domain set up on cloudflare and I created an a record for it, but since a few days ago when I test the subdomain ping in windows I get an error

@MH140000 can you be more specific about the error you see? Is it a timeout, or do you get IP addresses that start with 127 like in the first post?

[MH140000]

I have a domain set up on cloudflare and I created an a record for it, but since a few days ago when I test the subdomain ping in windows I get an error

@MH140000 can you be more specific about the error you see? Is it a timeout, or do you get IP addresses that start with 127 like in the first post?

Ping request could not find host ***. Please check the name and try again.

[MH140000]

Does it work to use an alternative CDN? https://palitechsociety.blogspot.com/2022/11/xray-vless-ws-tls-gcore.html

Yes. This service works, but unfortunately this service does not proxy the IP and there is a possibility of blocking the IP.

[alirezaac]

@arandomgstring for the problem with datacenters, they are likely to to just let go of iranian datacenters and make a centralized point to take control and people still can use methods but with the same difficulty as before, at this point i'm going to use datacenters that powers some sensitive services like this github, google and other stuff they gonna need for later, if it will come successful this can be an alternative instead of using arvan.

[arandomgstring]

@MH140000

Ping request could not find host ***. Please check the name and try again.

Did you follow my instruction? Ping the IP of your server directly; what is the result?! As I have already reported in this topic, they are returning "NULL" or loop back responses in DNS queries, and it can be solved quite easily.

@alirezaac
Honestly, they don't need foreign data centers to give correct respond for DNS queries of users. An ISP already knows the true IP of google, github, etc. Therefore, when a user request IP of these sensitive services through DNS queries, they can respond with correct IP, through any internal datacenter such as Arvan.

[NimaEagle]

Does it work to use an alternative CDN? https://palitechsociety.blogspot.com/2022/11/xray-vless-ws-tls-gcore.html

after nearly 3 hours its still stucked on Abort Let's Encrypt certificate status.

[arandomgstring]

@wkrp
I promised the next time it happens I will demonstrate DNS packets, so here it is:

For Orange Cloud:

And for gray cloud (which I have my personal website on):

Obviously 192.168.1.1 corresponds to IP of router, which redirects requests to ISP's DNS resolver. At the beginning I became suspicious that maybe router is the origin of problem. But no, first of all, why it happens at certain hours to begin with? Secondly, I changed DNS servers of router to that of google and cloudflare, and everything works fine. Therefore, it's not router's fault. And finally, I added dnsleaktest IP to hostfile to forcefully open it with ISP's DNS resolver (without doing so, I couldn't open this website, again because of I received no response for DNS query of this website. So I presume, dnsleaktest is using cloudflare's DNS propagator too, on gray cloud, that is) and here is the result:

So these bad boys are the origin of problem. Interestingly, these DNS resolvers open google, github, etc just fine, so it's not like they are totally busted or anything. It just so happens that they have some problems with cloudflare, at certain hours (5:30 AM to 11:30 AM approximately). Suspicious, isn't it?

[Azadzadeh]

@arandomgstring
If I understood correctly, to find out whether our domain was subject to DNS spoofing or not, we could just nslookup my.domain.name and see if the correct IP is listed there. Am I right?

[arandomgstring]

@Azadzadeh
Well you can ping your domain directly, it will show the IP returned by DNS request. I think it is the most easy way to do this.

nslookup domain.tld dns is another option, although I tested nslookup domain.tld 2.189.44.11 and nslookup domain.tld 2.189.44.10 quite a few times, and all I get is timeouts. And if you use only nslookup domain.tld without specifying a dns resolver, you might get response from google or cloudflare, which doesn't tell you the whole story behind DNS poisoning. You might have been a subject of DNS poisoning in ISP's DNS resolver, whereas google and cloudflare plain DNS could return the true result. Or you might also get bogon IP from google and cloudflare too, which means ISP has rewritten google and cloudflare responses (it's plain text after all).

[wkrp]

@arandomgstring I don't understand how a SERVFAIL (which is RCODE=2) transforms into a 127.154.0.92 IP address. It's possible that there is something else going on.

The dnsleaktest experiment is clever, but if I understand correctly it is inconclusive. The IP addresses 2.189.44.10 and 2.189.44.11 are reported by the dnsleaktest service as being the source addresses of honest DNS queries; i.e., ones that are not being tampered with and that are reaching the dnsleaktest servers. It could be that the queries that are being responded to with SERVFAIL (or whatever is resulting in 127.154.0.92) are handled differently.

With a recent version of dig, you may be able to get a more specific error reason from the SERVFAIL responses. The same information will be available in Wireshark if you expand the dissection tree.

It's a good idea to do a systematic test to try to falsify your hypothesis that the time of day has something to do with it. Something like this, to make a log of resolution results every 10 minutes:

while true; do date -u --iso=sec; dig @192.168.1.1 $HOSTNAME; sleep 600; done | tee $HOSTNAME.log

[arandomgstring]

@wkrp

I don't understand how a SERVFAIL (which is RCODE=2) transforms into a 127.154.0.92 IP address. It's possible that there is something else going on.

Now, I know why I was getting 127.154.0.92 even with SERVFAIL; it made no sense to me as well. I was using proxifier on my device which uses "Fake DNS" underhood. Even ipconfig /flushdns couldn't get rid of it; so I had to restart the device to see the "actual" response (what I saw in wireshark). I pinged these hosts, and the respond was "Ping request could not find host ***. Please check the name and try again." just like how @MH140000 #172 (comment) said.

I did the test with dig command on another device with another IP outside of Iran:

Same goes for nslookup:

And all of these results are consistent with SERVFAIL, I guess. So what's up with dnsleaktest website results?! And besides, I tested tci.ir which belongs to TCI ISP itself.

[alirezaac]

@wkrp

I don't understand how a SERVFAIL (which is RCODE=2) transforms into a 127.154.0.92 IP address. It's possible that there is something else going on.

Now, I know why I was getting 127.154.0.92 even with SERVFAIL; it made no sense to me as well. I was using proxifier on my device which uses "Fake DNS" underhood. Even ipconfig /flushdns couldn't get rid of it; so I had to restart the device to see the "actual" response (what I saw in wireshark). I pinged these hosts, and the respond was "Ping request could not find host ***. Please check the name and try again." just like how @MH140000 #172 (comment) said.

I did the test with dig command on another device with another IP outside of Iran:

Same goes for nslookup:

And all of these results are consistent with SERVFAIL, I guess. So what's up with dnsleaktest website results?! And besides, I tested tci.ir which belongs to TCI ISP itself.

well gaming community solves this with taklol and such dns services that have cache relay or any dns tools on domestic servers, so i guess you know next thing you can achieve with such technic is(emailed you before this might solve many problem but DOH on them is tricky too.)

[pirooz-gthb]

My servers are behind Cloudflare with proxy status as proxied (in other words, it is orange) and they are working with no problems in Iran.

Can it be dependent on your V2Ray or web server configurations?

[Azadzadeh]

My servers are behind Cloudflare with proxy status as proxied (in other words, it is orange) and they are working with no problems in Iran.

works on mobile (irancell / mci) too?

[pirooz-gthb]

My servers are behind Cloudflare with proxy status as proxied (in other words, it is orange) and they are working with no problems in Iran.

works on mobile (irancell / mci) too?

Oh, mea culpa. As I double-checked it. No, it doesn't work when using cellular data.

[wkrp]

I did the test with dig command on another device with another IP outside of Iran:

;; connection timed out; no servers could be reached

Same goes for nslookup:

DNS request timed out.

And all of these results are consistent with SERVFAIL, I guess. So what's up with dnsleaktest website results?! And besides, I tested tci.ir which belongs to TCI ISP itself.

No, a timeout and SERVFAIL are different. Timeout means you never received a DNS response packet. SERVFAIL means you received a DNS response packet with a specific response code.

An upstream timeout could happen when you are using a recursive resolver and the upstream resolver times out. But if you get a SERVFAIL you will know it, because you receive a packet.

Querying the IP addresses 2.189.44.10 and 2.189.44.11 doesn't really show anything. Those IP addresses do not appear to be configured to accept DNS queries from the general Internet. The fact that they appear in the dnsleaktest output only shows what IP addresses were used to send the recursive queries; it does not mean that those same IP addresses also receive queries. They may be recursive resolvers that only respond to queries from a limited set of source addresses. The servers may have multiple network cards, with different IP addresses for incoming or outgoing. The IP addresses you saw may be NAT gateways for a real DNS recursive resolver that resides on a private LAN. There are many possibilities; I don't think the timeouts tell us much.

What I meant to ask you to do is to use dig with the server 192.168.1.1, the resolver that was producing SERVFAIL results in #172 (comment). If there is more information about the cause of the failure, it is in those packets.

I am trying to understand now what remains of this question. The strange 127.*.*.* addresses were attributed to a Fake DNS proxifier. So the remaining mystery is that, with your router's built-in recursive DNS resolver, at certain times of day, for certain domain names associated with Cloudflare DNS hosting, you get SERVFAIL responses? If so, then some information gathering along the lines of #172 (comment) can help find the cause.

[pirooz-gthb]

My servers are behind Cloudflare with proxy status as proxied (in other words, it is orange) and they are working with no problems in Iran.

works on mobile (irancell / mci) too?

As I checked with someone else from Iran using MCI (Hamrahe Aval) mobile operator, I was reported that this person has access to the free Internet using cellular data. Probably the first one was probably using another mobile operator (Irancell ?).

[Azadzadeh]

As I checked with someone else from Iran using MCI (Hamrahe Aval) mobile operator, I was reported that this person has access to the free Internet using cellular data. Probably the first one was probably using another mobile operator (Irancell ?).

I believe if they succeed in blocking our proxy in one network, they're gonna use it on other ISPs too, should the time comes. Our method should be resilient in every network.

[MH140000]

I creat new account and add a subdomain via cdn and proxy but when i ping this, i got ping request can not found host در تاریخ سه‌شنبه 20 دسامبر 2022،‏ 9:12 Azadzadeh ***@***.***> نوشت:

…

As I checked with someone else from Iran using MCI (Hamrahe Aval) mobile operator, I was reported that this person has access to the free Internet using cellular data. Probably the first one was probably using another mobile operator (Irancell ?). I believe if they succeed in blocking our proxy in *one* network, they're gonna use it on other ISPs too, should the time comes. Our method should be resilient in *every* network. — Reply to this email directly, view it on GitHub <#172 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCWHPOQ4R2FO53OUIV6AT3WOFBL5ANCNFSM6AAAAAAS5YAXWE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[arandomgstring]

@MH140000
You should wait a little. Sometimes it might take 24h to 48h until DNS propagation completes. Do another ping test with a VPN to see if you get any results?

[MH140000]

Yes. I set dns about 3 days ago. With other vpn, i can ping this domain در تاریخ سه‌شنبه 20 دسامبر 2022،‏ 9:43 arandomgstring < ***@***.***> نوشت:

…

@MH140000 <https://github.com/MH140000> You should wait a little. Sometimes it might take 24h to 48h until DNS propagation completes. Do another ping test with a VPN to see if you get any results? — Reply to this email directly, view it on GitHub <#172 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCWHPPXZRWJLRHYLSWT2MDWOFFALANCNFSM6AAAAAAS5YAXWE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[arandomgstring]

@MH140000

Wonderful. You might be able to get it work, unless they have blocked CDN IPs on IP level. To do it,, turn on VPN and if you are on windows run this command nslookup yourdomain and if you are on linux run this command dig yourdomain. You will get a list of IPs, typically 4 IPs. Two of them are IPv6 (that contain characters and numbers) and 2 of them are IPv4 (just numbers). Then edit host folder of your device. On windows, it's in C:\Windows\System32\drivers\etc\host, on Linux /etc/hosts . At the end of it, add

first IPv4 yourdomain
second IPv4 yourdomain

Now turn off VPN and ping again. This time, either you see normal pings which means you can connect to your personal VPN on that domain with no problem, or you will see timeouts which means you need to create another account and try again. Although I should add that, you can also ping those two IPv4s directly, without modifying hostfile. If they return timeouts, it also means you need another account. If they returned correct latencies, then you need to modify host file to make you proxy work

[free-the-internet]

It's about 2 AM in Iran. Right now they are responding with a Google IP (e.g. 216.239.aaa.bbb) for every DNS query for domains that has foreign IP!

[arandomgstring]

@free-the-internet

You sure? Why would they respond with google's IP when they can send ITA massenger's IP to get more fake traffic from people? That's even stranger than my experience. I believe we need several people to collectively gather data about DNS queries to get a verifiable result.

I've written a bash code, that I hope people start using it for collecting more data about DNS poisoning, serverfail, etc. If you are on Windows, you should install WSL first to make it work, I don't like nslookup that much. Simply save this code in a file called "dns.bash" first,

#!/bin/bash
mkdir -p log
cd log
hosts=("google.com" "seconddomain.ir" "thirddomain.gg")
while true
do
	for str in ${hosts[@]}; do
	
	  date -u --iso=sec | tee -a $str.log
	  result=$(dig @192.168.1.1 $str)
	  
	  if [[ "$result" == *"NOERROR"* ]]; then
		  grep "ANSWER SECTION" -A 1 <<< $result | grep -v ';; ANSWER SECTION:' | tee -a $str.log >/dev/null
	  else
		echo "ISP's DNS resolver:"  | tee -a $str.log >/dev/null
		dig @192.168.1.1 $str | grep -v "WHEN" | tee -a $str.log >/dev/null
		echo "Cloudflare:"  | tee -a $str.log >/dev/null
		dig @1.1.1.1 $str | grep -v "WHEN" | tee -a $str.log >/dev/null
		echo "check logs"
	  fi
	  
	done
sleep $((600 + $((60*$((1 + $RANDOM % 10)))) ))
done

Then run tr -d '\r' <dns.bash> dns.sh to remove unnecessary white spaces caused by Windows, and finally sudo bash dns.sh. What this script does is simple. It will use dig command to do a dns query for every domain mentioned in hosts. If the DNS resolver responds successfully, we save the IP we have got (this is to ensure that we are not getting bogon IPs). Otherwise, in the case of errors we save the whole result of dig query, and we use dig query on cloudflare plain dns resolver as well and save its results. (This is needed for debugging servfail peckets). This bash file wait 600 seconds + (something between 60 to 600, randomly) seconds between each query and avoids writing user local time to log files. Maybe I should make a repository for this, maybe not. I simply want to monitor what they are doing.

[FinalityChanger]

@arandomgstring
If it's OK with you, I will make a repo for it. I will add a bat file as well.

[wkrp]

Thanks @arandomgstring. It will help a lot to have some systematic experimental results.

You can also try looking at recent OONI measurements. The measurement results will show what IP address the domain name resolved to.

https://explorer.ooni.org/search?since=2022-11-21&until=2022-12-22&failure=false&domain=twitter.com&probe_cc=IR&test_name=web_connectivity

From a quick scan, I only see "Confirmed" and "http-failure" OONI classifications (for twitter.com from Iran). I would expect to see some "dns-failure" if DNS were being tampered with as described in this thread. You may have to refine the search to include only a specific mobile ISP AS, etc.

• https://explorer.ooni.org/measurement/20221221T142028Z_webconnectivity_IR_58224_n1_TwyaezlgOEzWVpXf?input=https%3A%2F%2Ftwitter.com%2F
  • This one used a Cloudflare resolver (162.158.85.111) and the DNS response was 10.10.34.36, which is a well-known DNS injection address used in Iran that points to a block page.
• https://explorer.ooni.org/measurement/20221221T122913Z_webconnectivity_IR_58224_n1_TMCC5iCguMnyO7y6?input=https%3A%2F%2Ftwitter.com%2F
  • This one uses the resolver 5.200.200.50, which belongs to TCI. The DNS response is 104.244.42.193, which belongs to Twitter, so it looks like there is no problem with DNS in this measurement. You can see this under the "network_events", "tls_handshakes", and "requests" sub-keys of the "test_keys" key in the JSON.

    {
      "test_keys": {
        "network_events": [
          {
            "failure": "generic_timeout_error",
            "operation": "tls_handshake_done",
            "t": 13.738084109999999,
            "tags": [
              "tcptls_experiment"
            ]
          }
        ],
        "tls_handshakes": [
          {
            "network": "",
            "address": "104.244.42.193:443",
            "cipher_suite": "",
            "failure": "generic_timeout_error",
            "negotiated_protocol": "",
            "no_tls_verify": false,
            "peer_certificates": null,
            "server_name": "twitter.com",
            "t": 13.738084109999999,
            "tags": [
              "tcptls_experiment"
            ],
            "tls_version": ""
          }
        ],
        "requests": [
          {
            "failure": "generic_timeout_error",
          }
        ],
      },
    }
    

[arandomgstring]

@FinalityChanger
Sure, this is a throwaway account anyway. But I assume there are better monitoring tools for that, if you look at github more carefully.

@wkrp
My original post was at 12.14 #172 (comment) and if you look at https://explorer.ooni.org/country/IR you will see a sharp decrease from 10 to 13, does this count or am I misinterpreting/misreading it? I guess correlation does not always indicate causation. That said, it's been a few days that I am not receiving any DNS SERVFAIL at all, which is kind of unfortunate since I was really looking for it.

[arandomgstring]

@wkrp
Ok, I was lucky and got a SERVFAIL packet with dig command, as you can see we have an empty response, just like how I saw in wireshark (note that dig command was done at roughly the same time for cloudflare and ISP's DNS resolver):

2022-12-22T18:22:14+00:00 (UTC)

ISP's DNS resolver:

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> @192.168.1.1 7ho.st
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25897
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;7ho.st.				IN	A

;; Query time: 28 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; MSG SIZE  rcvd: 35


Cloudflare:

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> @1.1.1.1 7ho.st
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12554
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;7ho.st.				IN	A

;; ANSWER SECTION:
7ho.st.			246	IN	A	172.67.71.151
7ho.st.			246	IN	A	104.26.9.212
7ho.st.			246	IN	A	104.26.8.212

;; Query time: 113 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; MSG SIZE  rcvd: 83

Interestingly when there is no error, the response from ISP's DNS resolver is 7ho.st. 140 IN A 188.114.98.0 which is also an IP from cloudflare, but for some reason, it's different from cloudflare response. So far, it has been the only Servfail that I have got. Also I did dig command for 3 hosts at the same time, only this one returned servfail (which has orange cloud), others were fine.

[free-the-internet]

You sure?

@arandomgstring
Yes, I am.

[free-the-internet]

@wkrp Ok, I was lucky and got a SERVFAIL packet with dig command, as you can see we have an empty response, just like how I saw in wireshark (note that dig command was done at roughly the same time for cloudflare and ISP's DNS resolver):

2022-12-22T18:22:14+00:00 (UTC)

ISP's DNS resolver:

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> @192.168.1.1 7ho.st
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25897
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;7ho.st.				IN	A

;; Query time: 28 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; MSG SIZE  rcvd: 35


Cloudflare:

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> @1.1.1.1 7ho.st
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12554
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;7ho.st.				IN	A

;; ANSWER SECTION:
7ho.st.			246	IN	A	172.67.71.151
7ho.st.			246	IN	A	104.26.9.212
7ho.st.			246	IN	A	104.26.8.212

;; Query time: 113 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; MSG SIZE  rcvd: 83

Interestingly when there is no error, the response from ISP's DNS resolver is 7ho.st. 140 IN A 188.114.98.0 which is also an IP from cloudflare, but for some reason, it's different from cloudflare response. So far, it has been the only Servfail that I have got.

I would like to see this from another point of view: that is they want to show or introduce or redefine a new type of the Internet for the people where there is no blocking (forwarding to "This is a blocked domain" page, or responding with 10.x.x.x), but instead, doing nothing! which would make it very difficult to investigate the problem for people, and people can't say the website/IP is blocked, and they can not complain. This, along the throttling, will make VPNs available but not stable. So, nobody could use (see video or upload files). So we see a change in the policy here. Maybe this is the reason why minister of the technology[!!] and communications[!!!] of regime says "do tests, there is no issue".

But, the side effect of this is that it would make VPNs highly unstable, and we should use direct IP, or provide a private DNS server. However, with a private DNS server, there is a issue: dropping the DNS requests to/from foreign private servers.

[wkrp]

My original post was at 12.14 #172 (comment) and if you look at https://explorer.ooni.org/country/IR you will see a sharp decrease from 10 to 13, does this count or am I misinterpreting/misreading it?

I don't think there is much to learn from the aggregate graphs at https://explorer.ooni.org/country/IR. I only wanted to suggest that, in addition to asking people to run their own test scripts, you can see if there are any existing OONI measurements for the domains you are interested in.

Using a tool like jq you can extract just the DNS portion of the measurement JSON files, for inspecting many results at once. OONI has a blog post of download and mining large numbers of measurements.

$ jq -c '.test_keys.queries[].answers' *.json
[{"asn":13414,"as_org_name":"Twitter Inc.","answer_type":"A","ipv4":"104.244.42.193","ttl":null}]
[{"answer_type":"A","ipv4":"10.10.34.36","ttl":null}]

Ok, I was lucky and got a SERVFAIL packet with dig command, as you can see we have an empty response

I see. I was hoping there might be an Extended DNS Error with more information, but there is not. My guess is that the recursive resolver at 192.168.1.1 just had a random timeout while contacting the authoritative resolver, or something like that.