Looks like some of the big pools in china are having DNS problems

[philipma1957]

To follow up

I had maybe 100 different pieces of gear pointed to them.

around 11 dropped off.

I have another issue in that the anydesk I use to run the btc and LTC asic is down so I will need to drive the 150 mile round  trip to fix those miners they are idle.

The other 89 just ran with no issues.

[Toughit]

I just got this email from Viabtc.  Looks like .top is the extension for mining.

    

Support Team (ViaBTC)

Nov 27, 2021, 14:49 GMT+8
Dear user,


Thank you for contacting ViaBTC Support.


Sorry for having kept you waiting.


Recently, due to the impact of DNS pollution, some of the users in certain regions experienced abnormal resolution of the ViaBTC domain name (www.viabtc.com) and were unable to access the website properly. After emergency maintenance, ViaBTC has activated a new domain name (www.viabtc.net). If you have ever encountered the above situation, please use the new domain name to visit the website.


+++++++++++++++++++++++++++++++++++++++++
【App guides】

If you have problem using App, please update your ViaBTC App to the latest version.

For the Android, please upgrade to the latest App from Google Play Store or via the Direct download link (https://download.viabtc.net/ViaBTC_Pool_3.0.4.apk)


For the iOS , it is currently unavailable, you may wait patiently and update from theApp Store in coming days.


+++++++++++++++++++++++++++++++++++
【Mining guides】

Simply put, please use (viabtc.net) for visiting website and use(viabtc.top) for mining configuration.

The current available coins: BTC, ETH, LTC, BCH, and Smart Mining, please refer to the mining configuration page https://www.viabtc.net/pool/state


Updated mining URL：
BTC: stratum+tcp://btc.viabtc.top:3333
BCH: stratum+tcp://bch.viabtc.top:3333
ETH: stratum+tcp://eth.viabtc.top:3333
LTC: stratum+tcp://ltc.viabtc.top:3333
Smart Mining: stratum+tcp://bitcoin.viabtc.top:3333

For example, if you are mining BTC, your new mining URL would be stratum+tcp://btc.viabtc.top:3333

Please stay tuned for the configuration of more coins later.

[DaveF]

What is interesting is that the registrar for both domains is https://net.cn but the .com is still on registrar hold as of now as I posted above, but the .net is fine.

I am starting to think more and more this has nothing to do with anything China related and more of someone got access to something they should not have.

If China wanted to block it registrar hold is not the way to do it. Just an edge block would work fine, just like any firewall.
If viabtc wanted to deal with this quickly all they would have to do it send out a list of IP addresses to connect to instead of names that needed to be resolved.

Since miners that were connected were still connected and mining then we know that the stratum servers and related services are not and were not being filtered or blocked.

To me, on the surface that looks like something else.

... and moving DNS outside China is not a 5 minute exercise.

If it's on hold you can't move it at all. If it's not it take about an hour to propagate it. Which was about what the .net did from the alibaba DNS to cloudflare.

-Dave

[Artemis3]

To me, this was the gov adding blocks to the GFW, this took them by "surprise" and they just scrambled to change dns.

As you know, when you change the dns of your server/website whatever, it can take a couple of days to propagate to the whole internet. There is dns caching and dns servers asking other dns servers, etc. To some the change is quick, to some it takes longer as it has always been.

But why did these Chinese pools took so long to do this change, why wait until their gov cut them? Its not like they didn't know this was coming, and its one reason Slush Pool dropped the Chinese nodes at least half a year ago.

This was also a good call on people relying too much in Chinese pools, they ignored decentralization, and paid the price.

[philipma1957]

To me, this was the gov adding blocks to the GFW, this took them by "surprise" and they just scrambled to change dns.

As you know, when you change the dns of your server/website whatever, it can take a couple of days to propagate to the whole internet. There is dns caching and dns servers asking other dns servers, etc. To some the change is quick, to some it takes longer as it has always been.

But why did these Chinese pools took so long to do this change, why wait until their gov cut them? Its not like they didn't know this was coming, and its one reason Slush Pool dropped the Chinese nodes at least half a year ago.

This was also a good call on people relying too much in Chinese pools, they ignored decentralization, and paid the price.

And worse yet it shows that any pow coin of any type can be attacked at the government level by major countries.

So the fall out is interesting.

I think a lot has to do with China and USA trade war.

ie Trump tax is now Biden tax and imports from China are still being hurt bigly.

China is trying to figure ways to fight against that trade tariff.

[DaveF]

To me, this was the gov adding blocks to the GFW, this took them by "surprise" and they just scrambled to change dns.

And once again no, read what I posted above. Nothing is blocked. Not the IPs, not the services, nothing.
The registrar that viabtc.com is hosted at put a block on the domain / shut it down. BUT they left every other VIA name untouched, just the .com is offline.

If they wanted to block access all they had to do was put a block at the great firewall and those IPs would have dropped out of existence. But as others have reported, so long as you did not need to re-confirm the IP you could just keep mining. VIABTC could have just gone out and gotten a new domain name anywhere and said go here to mine. But they did not. So something else is going on.

I run my own DNS servers, and since I log every request I went back and looked at what my miners asked for, put in those IPs and away they went to mine.

There are 2 different things at play here when it comes to DNS
1) How long it takes to change DNS servers i.e. go from alibaba DNS to cloudflare. That is anywhere from 1 to 6 hours. Usually close to 1 hour.

2) How long it takes for other places to notice you changed IPs (having nothing to do with #1) that is configurable. And usually a few hours. BUT a lot of providers can and use their own time limits ignoring what the DNS provider says. I can set it to 1 minute, but no matter what there are a lot of places out there that default to 7200 seconds (2 hours) or 86400 seconds (24 hours) no matter what the DNS server tells them.

-Dave

Notes:
1) I was not mining BTC but ETH but that should not matter the IPs still pass data no problems.
2) I switched to nicehash as primary since the profit is much higher at the moment but the VIA IPs still show online

[stompix]

I am starting to think more and more this has nothing to do with anything China related and more of someone got access to something they should not have.

And how did they get access to something that would have affected also f2pool and binance which both have reported issues?
What would be that thing aside from the GFW that could impact everything like this?

Since miners that were connected were still connected and mining then we know that the stratum servers and related services are not and were not being filtered or blocked.

Miners that were connected to the pool were still mining with no problem, you don't need to solve a DNS for an active connection, if you would have tried to reconnect or add a new miner to it it won't reach the pool, I did so with one of my miners early in the morning, and now I've had to switch pool it as it can't reach any via server.

[MoparMiningLLC]

I also noticed that there is now a viabtcpool . com - whole different look so could possibly be non legit.

[stompix]

I also noticed that there is now a viabtcpool  - whole different look so could possibly be non legit.

It's an old scam website, check their offers page, 200-300% ROI in 48 hours? just lol.
There is one with a btc-pool, and there was another one but I can't remember what it used differently.

[DaveF]

And how did they get access to something that would have affected also f2pool and binance which both have reported issues?
What would be that thing aside from the GFW that could impact everything like this?

Because they all use the same registrar.
Not saying that it does happen a lot, but it does happen regularly:

https://www.zdnet.com/article/hackers-breached-greeces-top-level-domain-registrar/

https://www.cpomagazine.com/cyber-security/domain-registrar-godaddy-breached-attackers-trick-employees-into-transferring-ownership-of-cryptocurrency-sites/

https://arstechnica.com/information-technology/2019/02/inside-the-dnspionage-hacks-that-hijack-domains-at-an-unprecedented-scale/

Now this is also an interesting little take on it. I am not saying that it happened here, just that it has happened.
IF I get access to your DNS control I can set the IPs to wherever I like.

I then set the TTL (How long once you ask for the IP for me to store it and not check again) to a very high number. So even if you get control there are still places around the world that will give the wrong information for days.

However, if you shutdown the domain at the root registrars there is a good chance that even though it said this is the proper IP for this name and don't look for another X seconds. There are actually 2 TTLs (prepare for some really boring shit here) that although not going to be 100% the way it works it's the best I can do in a post not a 120 minute power point seminar....

Picking on stackoverflow.com here I pull all their DNS info:

Code:

HEADER:
    opcode = QUERY, id = 19492, rcode = NOERROR
    header flags: reply, auth. answer, want recursion.
    questions = 1, answers = 4, auth. records = 4, additional = 0
QUESTIONS:
    stackoverflow.com., type = XX, class = 1
ANSWERS:
->  stackoverflow.com.
    type = A, class = 1, ttl = 300, dlen = 4
    IP address = 151.101.65.69
->  stackoverflow.com.
    type = A, class = 1, ttl = 300, dlen = 4
    IP address = 151.101.129.69
->  stackoverflow.com.
    type = A, class = 1, ttl = 300, dlen = 4
    IP address = 151.101.193.69
->  stackoverflow.com.
    type = A, class = 1, ttl = 300, dlen = 4
    IP address = 151.101.1.69
AUTHORITY RECORDS:
->  stackoverflow.com.
    type = NS, class = 1, ttl = 172800, dlen = 23
    nameserver = ns-1033.awsdns-01.org.
->  stackoverflow.com.
    type = NS, class = 1, ttl = 172800, dlen = 19
    nameserver = ns-358.awsdns-44.com.
->  stackoverflow.com.
    type = NS, class = 1, ttl = 172800, dlen = 28
    nameserver = ns-cloud-e1.googledomains.com.
->  stackoverflow.com.
    type = NS, class = 1, ttl = 172800, dlen = 14
    nameserver = ns-cloud-e2.googledomains.com.

You can see that they have an A (Address) record set to expire in 300 seconds:

stackoverflow.com.
    type = A, class = 1, ttl = 300, dlen = 4
    IP address = 151.101.65.69

BUT they also have these these things called AUTHORITY RECORDS which more or less mean that these are the proper DNS servers for them and don't worry about it for the next 172800 seconds (2880 minutes / 48 hours) so even if you hijack that domain and point it's DNS servers someplace else for the next 2 days from when you looked. IF YOU DNS IS SETUP TO OBEY THE TTLs then you will never ever care where the new DNS servers are. Those listed are it.

AUTHORITY RECORDS:
->  stackoverflow.com.
    type = NS, class = 1, ttl = 172800, dlen = 23
    nameserver = ns-1033.awsdns-01.org.

However, if your domain is shutdown (like what viabtc.com) then it all stops then and there. I go to look for something and the root DNS zones say nope.

Now as I said, this is not 100% the way it works but it does give you a general view. If you got control of the domain and did something funky then I could see them doing something like this to stop an attack.

Now, I am not saying that is what happened. But all this "China is blocking" stuff just seems a bit off since traffic is passing.

If you think about it, if China wanted to block it all they would have to do it tell the registrar, shut off access and give us the domain. And then tell the 100% owned by the government internet provider stop passing traffic to these IP addresses and call it a day.

-Dave

[stompix]

And how did they get access to something that would have affected also f2pool and binance which both have reported issues?
What would be that thing aside from the GFW that could impact everything like this?

Because they all use the same registrar.

Had to cut this short, sorry, but you've started with the wrong assumption, no they don't!
Neither binance pool, not f2pool use it and I'm willing to bet that kano isn't either.

[DaveF]

And how did they get access to something that would have affected also f2pool and binance which both have reported issues?
What would be that thing aside from the GFW that could impact everything like this?

Because they all use the same registrar.

Had to cut this short, sorry, but you've started with the wrong assumption, no they don't!
Neither binance pool, not f2pool use it and I'm willing to bet that kano isn't either.

Was going from here:

Looks like it might be related to Alibaba Cloud.

From CityAM

It seems the major pools of viaBTC, Poolin, F2Pool, Binance and BTCcom suddenly experienced connection interruptions. The only thing they all had in common was their DNS was provided by Alibaba Cloud, a Chinese owned operation. All had stopped resolving.

I will admit I didn't look to see where they were, I saw the article posted and did not check more. That is on me. No idea about kano.

Without getting into anything else, I will say that if they were using a different DNS provider (outside of China) then nothing makes sense.
If China wanted to block external mining then all they had to do was block the pool IPs at the edge of China
If they wanted to block internal miners from reaching them then you just block the routes internally to the country.

This just puts a (very) small bump in the road. If your stratum did not disconnect then you never stopped mining.
If you could get the IPs from someone who had them then you are back mining.
If the pools changed name (viabtc.top) and started using cloudflare then you are back mining.

Shutting down DNS and not keeping it down does not really do much.

And if DNS / registrar were outside of China then there would be no way for them to stop resolving names to IPs. INSIDE China could be stopped, but Phil / Mopar and all of us in the USA and the rest of the world would not have had DNS resolution stop if they were using DNS and registrars outside of China.

Since the government controls all telcom in China then it really is as easy as:

Code:

Router(config)# ip route A.B.C.D Sub.Net.Mask.Here null0                  

And then propagate it. If you are using Cisco. But more or less it's all the same.

-Dave

[Biffa]

Can confirm .top addresses for mining work, .net address for main web site legit.

Just had an auto-payout go through as normal.

[kano]

The point that appears to be the problem is the GFW.

No, I'm not guessing at what is going on, I'm guessing at the point where the changes occur.

I run my own DNS servers, hidden unlisted inaccessible master, and 3 slaves that are listed as NS records for the DNS for domains e.g. of course kano.is
The other day, after this started, I changed the kano.is NS records by removing the DNS that was in china - down to 2 NS records (in usa)
The TTL for an NS record on *.is is required to be 86400 (or more)
*.com is typically a lot lower (I always set it a lot lower) but being lower also means an outage can fail DNS resolution more easily if your DNS servers are not reliable (not my problem )

I've since also added a new DNS server (in germany) and added it to kano.is thus again mean kano.is has 3 NS records
These changes of course have also been done at the domain registrar in Reykjavík as is required for it to actually work.

Now to see what is actually going on I can run some dig commands from inside and outside china and compare them.
i.e. this is actual data, no guesses at what is being done.

I'll just repeat this one command since it's good enough to show it:

Code:

dig @104.238.158.242 la6.kano.is

What it does is directly ask my new DNS server what is the address of la6.kano.is
It's 'supposed' to be a direct IP connection to 104.238.158.242 for the answer.
(yes anyone can lookup those values to work out that command)

So from outside the GFW, the correct and consistent answer is:

Code:

# dig @104.238.158.242 la6.kano.is

; <<>> DiG 9.16.1-Ubuntu <<>> @104.238.158.242 la6.kano.is
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60263
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 15796e8f400f631f0100000061a2b483af1b5fa2fac05f07 (good)
;; QUESTION SECTION:
;la6.kano.is.			IN	A

;; ANSWER SECTION:
la6.kano.is.		600	IN	A	149.28.75.193

;; Query time: 248 msec
;; SERVER: 104.238.158.242#53(104.238.158.242)
;; WHEN: Sat Nov 27 22:43:15 UTC 2021
;; MSG SIZE  rcvd: 84

However, from inside the GFW (Beijing) the answer (which changes every time I run it, I've give: two results) is:

Code:

#  dig @104.238.158.242 la6.kano.is

; <<>> DiG 9.16.1-Ubuntu <<>> @104.238.158.242 la6.kano.is
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9846
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;la6.kano.is.			IN	A

;; ANSWER SECTION:
la6.kano.is.		102	IN	A	108.160.172.1

;; Query time: 4 msec
;; SERVER: 104.238.158.242#53(104.238.158.242)
;; WHEN: Sat Nov 27 22:45:28 UTC 2021
;; MSG SIZE  rcvd: 45

and

Code:

#  dig @104.238.158.242 la6.kano.is

; <<>> DiG 9.16.1-Ubuntu <<>> @104.238.158.242 la6.kano.is
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23882
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;la6.kano.is.			IN	A

;; ANSWER SECTION:
la6.kano.is.		248	IN	A	128.242.240.29

;; Query time: 8 msec
;; SERVER: 104.238.158.242#53(104.238.158.242)
;; WHEN: Sat Nov 27 22:46:17 UTC 2021
;; MSG SIZE  rcvd: 45

Now you can see firstly that the answers are wrong but state that they are from the correct DNS IP
The answers are clearly random, those two answers are Dropbox CA and NTT America, Inc. CO

i.e. it appears that either the GFW or Aliyun or both are randomly screwing with DNS requests.

However, when I lookup some of my other domains, the answers are correct.
So it appears to be directed at mining/bitcoin DNS lookups.
(e.g. it happens looking up bitcointalk.org as a straight dig and no server specified)

[HagssFIN]

Whoah, things are getting quite evil in there, if they are actually sabotaging the IT infrastructure.

[kano]

Whoah, things are getting quite evil in there, if they are actually sabotaging the IT infrastructure.

Well the GFW (which was designed and setup by Cisco to help China violate the human rights of it's citizens ... and the reason I never have and never will buy anything from Cisco) is designed to allow them to screw with anything crossing it.

I guess they decided to play anti-bitcoin this week (and who knows for how much longer)

[mikeywith]

Can confirm .top addresses for mining work, .net address for main web site legit.
Just had an auto-payout go through as normal.

Same here, nothing unusual, the .net website was posted in their official Telegram group which I know is legit because I have been there long before this mess, and the payout (just about an hour ago) went through with no issues.


I noticed something strange happened earlier on, which could be a bug in cgminer!, at one point and out of a sudden, some miners went offline (not showing on either pools), about 20-30 of them, I thought there was an issue with the electricity or something, but when I accessed them via anydesk, everything seemed fine, but all pools (including cksolo which is the secondary pool) were showing dead on those miners, but cksolo was showing alive on the other miners.

When I added the new stratum link on the primary pool (viabtc) the miners started hashing and ckpool was showing alive, I know ckpool was good the whole time judging by the other miners, I just didn't know why those miners failed to connect to ckpool when viabtc went offline for a brief while.

of course, I didn't bother investigating the matter any further, I just used Awesomeminer to change the primary pool on all miners pointed to viabtc to the new URL viabtc.top, and everything started working just fine.

On a side but related note, Binance pool seems like the only Chinese pool that was prepared for this, hashrate was safu.

[Yrth]

It's funny that they expect everyone to be on telegram, they should have sent out emails right after this shit happened, anyway, mining is going alright, heck, this is less scary than my experience with Poolin a while back, the pool was working just fine but my hashrate was showing zero.

I logged into the .net site and was unable to make any changes to the payout addresses as the email verification never came. They are probably having the same issue with their email server.

I was however able to withdraw all mined coin to previously setup payment addresses.

[DaveF]

It's funny that they expect everyone to be on telegram, they should have sent out emails right after this shit happened, anyway, mining is going alright, heck, this is less scary than my experience with Poolin a while back, the pool was working just fine but my hashrate was showing zero.

I logged into the .net site and was unable to make any changes to the payout addresses as the email verification never came. They are probably having the same issue with their email server.

I was however able to withdraw all mined coin to previously setup payment addresses.

I did a quick look at the email that came in on Friday about the name going from .com to .net and it did not have any SPF / DKIM / DMARC information in it so there are a lot of email services that may just blackhole the email not even accept it.

What those acronyms mean:
SPF = https://en.wikipedia.org/wiki/Sender_Policy_Framework
DKIM = https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
DMARC = https://en.wikipedia.org/wiki/DMARC


On a related note, things like this are why everyone should use DNSSEC, but for some reason trying to get people to do it is an uphill fight.
I do it on the 2 domains that I have that matter. But not on the rest. Getting others to do it is just about impossible.
There was even a discussion about a year ago on the bitcoin core github about making DNSSEC required for the seed nodes that went nowhere.
Would not have made much of a difference on what happened here, but in general it's a good thing.

DNSSEC = https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

-Dave