Why did asia1.ethermine.org IP address change from Singapore to Seattle ?

jmsjrjmsjr Member Posts: 43
edited March 1 in Pool Discussion
I moved from mining at nanopool.org to ethermine.org about 2 - 3 days ago.

Since I live in Australia, the closest and with the lowest average ping RTT was asia1.ethermine.org
Before I started, I did a DNS lookup of asia1.ethermine.org ( e.g. dig asia1.ethermine.org ) and I swear that the DNS reply were all DNS A records, no CNAME records.

About yesterday when I restarted my rig, the DNS records for asia1.ethermine.org are now returning DNS CNAME records indicating it asia1.ethermine.org were using amazonws.com, and the IP addresses returned were totally different than 2 - 3 days ago.

They were different because:
1) I have a bash history showing which IP addresses I tried
2) Claymore's log.txt showed the original IP addresses were resolved / used.
3) The new resolved IP addresses ( the one using amazonws.com ) have a higher ping RTT so much so that my hashrate is much much lower.

To resolve the lower hashrate, I have to use the original IP addresses that I can see in Claymore's log.txt instead of using asia1.ethermine.org, and now I am back to my original hashrate.

Here is what dig asia1.ethermine.org look now, showing resolved IP addresses 13.x.x.x:

$ dig asia1.ethermine.org ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.2 <<>> asia1.ethermine.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56053 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;asia1.ethermine.org. IN A ;; ANSWER SECTION: asia1.ethermine.org. 120 IN CNAME ethermineasia1elb-c996283bb764fb61.elb.ap-southeast-1.amazonaws.com. ethermineasia1elb-c996283bb764fb61.elb.ap-southeast-1.amazonaws.com. 60 IN A 13.228.161.243 ethermineasia1elb-c996283bb764fb61.elb.ap-southeast-1.amazonaws.com. 60 IN A 13.250.135.167 ;; Query time: 145 msec ;; SERVER: 10.1.1.1#53(10.1.1.1) ;; WHEN: Thu Mar 01 20:31:11 AEDT 2018 ;; MSG SIZE rcvd: 150


While I do not have the original dig output from 2 - 3 days ago, here is what my claymore's log.txt shows the IP addresses were used were originally 139.99.9.x or 139.99.8.x ... and you can see below the shift to 13.x.x.x:

1519730630_log.txt:22:23:56:025 c45f9700 ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.9.175> port 4444 1519730737_log.txt:22:25:43:630 6b7fe700 ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.8.222> port 4444 1519730737_log.txt:22:44:43:654 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.8.158> port 4444 1519730737_log.txt:23:44:44:416 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.9.175> port 4444 1519730737_log.txt:00:44:45:544 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.9.175> port 4444 1519730737_log.txt:01:44:46:207 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.8.158> port 4444 1519730737_log.txt:02:44:46:911 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.9.175> port 4444 1519730737_log.txt:03:44:47:588 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.9.157> port 4444 1519730737_log.txt:04:44:48:308 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.9.157> port 4444 1519730737_log.txt:05:44:48:939 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.9.175> port 4444 1519730737_log.txt:06:44:49:723 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.8.158> port 4444 1519730737_log.txt:07:44:50:369 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.8.158> port 4444 1519730737_log.txt:08:44:51:071 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.8.158> port 4444 1519730737_log.txt:09:44:51:741 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.8.158> port 4444 1519730737_log.txt:10:44:52:478 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.8.222> port 4444 1519730737_log.txt:11:44:53:165 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.9.157> port 4444 1519730737_log.txt:12:44:54:355 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.9.157> port 4444 1519730737_log.txt:13:44:55:079 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.9.175> port 4444 1519730737_log.txt:14:44:55:784 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.8.222> port 4444 1519730737_log.txt:15:44:56:478 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.8.158> port 4444 1519730737_log.txt:16:44:57:116 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.9.175> port 4444 1519730737_log.txt:17:44:58:227 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.8.222> port 4444 1519730737_log.txt:18:44:58:860 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <139.99.8.222> port 4444 1519730737_log.txt:19:44:59:536 6affd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <13.250.135.167> port 4444 1519810631_log.txt:20:37:17:412 d27fc700 ETH: Stratum - connecting to 'asia1.ethermine.org' <13.250.135.167> port 4444 1519811430_log.txt:20:50:35:762 f77fe700 ETH: Stratum - connecting to 'asia1.ethermine.org' <13.228.161.243> port 4444 1519811430_log.txt:21:06:05:851 f6ffd700 DevFee: ETH: Stratum - connecting to 'asia1.ethermine.org' <13.228.161.243> port 4444 1519813552_log.txt:21:25:58:737 b9ffb700 ETH: Stratum - connecting to 'asia1.ethermine.org' <13.228.161.243> port 4444

For now, I am using the original / fixed IP address 139.99.8.222, even though DNS does not return this IP address anymore for asia1.ethermine.org.
My hashrate is still OK from ethermine.org website.

What does everyone else's "dig asia1.ethermine.org" output look like ?
Anyone else using asia1.ethermine.org and noticed the change to 13.x.x.x in claymore's log.txt ?
Am I being a victim of DNS poisoning / MITM to divert the hashrate somewhere else ?


Post edited by jmsjr on

Comments

  • jmsjrjmsjr Member Posts: 43
    For what it's worth, the original asia1.ethermine.org IP address of 139.99.8.222 is in Singapore.
    The new IP address 139.99.8.222 is in Seattle ( e.g. Amazon ). Why would ASIA1 use a host in Seattle ??

    The above according to www.geoip.co.uk

    No wonder I got lower hashrates with the new IP address, so am sticking with the old IP address ( the one in Singapore ) even though it is not returned in my DNS responses.




  • jmsjrjmsjr Member Posts: 43
    Changed the title of this thread so that it is more obvious
  • Ericjh801Ericjh801 Utah, USAMember Posts: 365 ✭✭
    That IP address shows it's owned by Amazon and is located in Singapore. (Thus why it says AP-Southeast) as it's south east asia I believe.


    https://ipinfo.io/AS16509/13.250.0.0/15-13.250.134.0/23

    ID
    AMAZON-SIN

    Description
    Amazon Data Services Singapore

    ASN
    AS16509
    Amazon.com, Inc.

    Parent IP Range
    13.250.0.0/15

    Country
    Singapore

    Registry
    arin



    I don't have dig on my windows machine. When doing a traceroute it seems to go through Singapore also.

    Tracing route to ec2-13-250-135-167.ap-southeast-1.compute.amazonaws.com [13.250.135.167]
    over a maximum of 30 hops:

    1 <1 ms <1 ms <1 ms 192.168.0.1
    2 1 ms <1 ms <1 ms 65.103.231.254
    3 8 ms 7 ms 7 ms slcy-dsl-gw16.slcy.qwest.net [207.108.176.16]
    4 8 ms 7 ms 7 ms slcy-agw1.inet.qwest.net [207.108.177.121]
    5 17 ms 18 ms 17 ms dvr-brdr-02.inet.qwest.net [67.14.24.14]
    6 17 ms 17 ms 18 ms 63.146.26.154
    7 210 ms 209 ms 210 ms if-ae-6-2.tcore1.PDI-Palo-Alto.as6453.net [66.198.127.69]
    8 202 ms 209 ms 203 ms if-ae-7-2.tcore2.SV1-Santa-Clara.as6453.net [209.58.86.73]
    9 143 ms 141 ms 140 ms if-et-5-2.hcore1.KV8-Chiba.as6453.net [209.58.86.143]
    10 208 ms 208 ms 207 ms if-ae-21-2.tcore1.TV2-Tokyo.as6453.net [120.29.217.66]
    11 207 ms 208 ms 207 ms if-ae-31-2.tcore2.SVW-Singapore.as6453.net [180.87.15.40]
    12 199 ms 199 ms 213 ms 180.87.15.206
    13 * * * Request timed out.


  • jmsjrjmsjr Member Posts: 43
    That is weird...I swear when I did traceroute yesterday from the rig it never went to Singapore but went to Seattle from Australia..hence lower effective hashrate and hence using a fixed old IP address that is not returned by DNS anymore. I will test again when I get back home from work.
  • Ericjh801Ericjh801 Utah, USAMember Posts: 365 ✭✭
    Yeah it would be interesting to see what you get now. That ip address range is definitely for Amazon's Asia presence though.
  • jmsjrjmsjr Member Posts: 43
    OK .. I am confused now .. though I admit everything seems to pointing to Singapore ( except for 1 IP address ), and traceroute are inconclusive because it shows * * * at the 9th hop after coming out of Perth Australia.

    1) If you look at https://www.robtex.com/dns-lookup/asia1.ethermine.org ...

    ( image shown below just in case the results are different over time ):




    it shows 139.99.8.222 as one of the IP addresses ... which I originally was using and now am using instead of the FQDN of asia1.ethermine.org

    2) However, when you do a nslookup or dig, asia1.ethermine.org is showing a different result of IP addresses:

    asia1.ethermine.org. 120 IN CNAME ethermineasia1elb-c996283bb764fb61.elb.ap-southeast-1.amazonaws.com. ethermineasia1elb-c996283bb764fb61.elb.ap-southeast-1.amazonaws.com. 60 IN A 13.250.135.167 ethermineasia1elb-c996283bb764fb61.elb.ap-southeast-1.amazonaws.com. 60 IN A 13.228.161.243

    Why would you get different DNS records ( just like what happened to me over time .. or from different locations ) ? The robtex website still have the DNS records for asia1.ethermine.org before it used amazonws IP addresses


    3) Furthermore, one of the IP addresses for asia1.ethermine.org ( 139.99.8.222 ) is not in Asia, but i either in Montreal Canada or San Jose Californa USA ... well at least according to ipinfo.io and geoiptool.com:

    https://ipinfo.io/139.99.8.222
    https://geoiptool.com/en/?ip=139.99.8.222

    Though I am in Australia, I am actually getting a better effective hashrate using 139.99.8.222 .. .as in I am submitting accepted shares .. than when I was using the IP addresses in Singapore ( the one with AmazonWS ).



  • rigproxyrigproxy Member Posts: 26
    edited March 2
    There is something wrong with the "load balancing" which permits to dispatch clients toward different servers based on their availability.
    This load balancing is done with the DNS returning the most appropriate server's IP based on overall servers load and normally also your location and/or latency (normally it should behave this way).

    It also handles failover switching.
    So you can do as you do using directly the server IP with the best latency but use an url as failover server to your mining software (ideally located elsewhere in case servers in the same data centers are all down at the same time).
  • jmsjrjmsjr Member Posts: 43
    rigproxy said:

    There is something wrong with the "load balancing" which permits to dispatch clients toward different servers based on their availability.
    This load balancing is done with the DNS returning the most appropriate server's IP based on overall servers load and normally also your location and/or latency (normally it should behave this way).

    It also handles failover switching.
    So you can do as you do using directly the server IP with the best latency but use an url as failover server to your mining software (ideally located elsewhere in case servers in the same data centers are all down at the same time).

    Thanks @rigproxy .

    For awhile, I thought I was being a victim of a MITM because the IP that I was using before ( and still using now ), was no longer returned from a DNS lookup .. but I can still see my stats being reported.
  • rigproxyrigproxy Member Posts: 26
    edited March 12
    @jmsjr we are (internal) testing our ipv4 DNS proxy service before opening for public beta test.
    Rigproxy DNS could help secure a little bit more your rigs.
    Our DNS proxy is filtering requests and it blocks undesired access (windows update and more).
    The DNS filtering doesn't prevent a malware software from changing the DNS within the OS, nor direct IP accesses, but the malware installation process often includes the access to one or multiple websites and we can prevent accessing a malicious url.
    Our filtering database will grow with usage and as soon as we have enough data, we will change our filtering method to go from a "blacklist" filtering to "whitelist" filtering, which means that only whitelisted domains will be allowed. The security will be better as our DNS protection will only allow pool accesses.
    Post edited by rigproxy on
Sign In or Register to comment.