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

DaveF

legendary

Activity: 3500

Merit: 6320

Crypto Swap Exchange

Quote from: Yrth on November 28, 2021, 04:08:05 AM

Quote from: mikeywith on November 26, 2021, 05:27:17 PM

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

Yrth

member

Activity: 123

Merit: 21

Quote from: mikeywith on November 26, 2021, 05:27:17 PM

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.

mikeywith

legendary

Activity: 2436

Merit: 6643

be constructive or S.T.F.U

Quote from: Biffa on November 27, 2021, 12:27:19 PM

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.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: HagssFIN on November 27, 2021, 06:03:24 PM

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)

HagssFIN

legendary

Activity: 2506

Merit: 1714

Electrical engineer. Mining since 2014.

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

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

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)

Biffa

legendary

Activity: 3234

Merit: 1221

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

Just had an auto-payout go through as normal.

DaveF

legendary

Activity: 3500

Merit: 6320

Crypto Swap Exchange

Quote from: stompix on November 27, 2021, 10:45:02 AM

Quote from: DaveF on November 27, 2021, 10:29:09 AM

Quote from: stompix on November 27, 2021, 09:25:10 AM

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:

Quote from: Biffa on November 26, 2021, 10:38:19 AM

Looks like it might be related to Alibaba Cloud.

From CityAM

Quote

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

stompix

legendary

Activity: 2912

Merit: 6403

Blackjack.fun

Quote from: DaveF on November 27, 2021, 10:29:09 AM

Quote from: stompix on November 27, 2021, 09:25:10 AM

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

legendary

Activity: 3500

Merit: 6320

Crypto Swap Exchange

Quote from: stompix on November 27, 2021, 09:25:10 AM

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:

Quote

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.

Quote

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

legendary

Activity: 2912

Merit: 6403

Blackjack.fun

Quote from: MoparMiningLLC on November 27, 2021, 09:36:49 AM

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. Grin

There is one with a btc-pool, and there was another one but I can't remember what it used differently.

MoparMiningLLC

legendary

Activity: 2254

Merit: 2419

EIN: 82-3893490

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

stompix

legendary

Activity: 2912

Merit: 6403

Blackjack.fun

Quote from: DaveF on November 27, 2021, 08:44:13 AM

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?

Quote from: DaveF on November 27, 2021, 08:44:13 AM

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.

DaveF

legendary

Activity: 3500

Merit: 6320

Crypto Swap Exchange

Quote from: Artemis3 on November 27, 2021, 08:49:30 AM

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

philipma1957

legendary

Activity: 4326

Merit: 8950

'The right to privacy matters'

Quote from: Artemis3 on November 27, 2021, 08:49:30 AM

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.

Artemis3

legendary

Activity: 2030

Merit: 1573

CLEAN non GPL infringing code made in Rust lang

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.

DaveF

legendary

Activity: 3500

Merit: 6320

Crypto Swap Exchange

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.

Quote from: kano on November 26, 2021, 07:27:54 PM

... 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

Toughit

full member

Activity: 378

Merit: 197

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.

philipma1957

legendary

Activity: 4326

Merit: 8950

'The right to privacy matters'

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.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

As I just mentioned in the other thread:

Quote from: kano on November 26, 2021, 07:21:15 PM

The issue is where their DNS servers exist.

If they where inside China (doesn't matter where the pool you mine to is) then the DNS is being manipulated by GFW and/or Aliyun.

This is still going on (I just checked it again now)

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

Topic: Looks like some of the big pools in china are having DNS problems (Read 548 times)