Is GeoDNS still an issue?

[ldb]

I recently moved to a different country and created a new App as I though it may create some issues, however -> ESP8226 redirects to 45.55.96.146:80 and pinging from the PC = 139.59.206.133… This causes an Invalid Token response when use HTTP API with blynk-cloud.com

   / _ )/ /_ _____  / /__
  / _  / / // / _ \/  '_/
 /____/_/\_, /_//_/_/\_\
        /___/ v0.5.4 on Arduino

[2822] Connecting to blynk-cloud.com:80
[2944] Redirecting to 45.55.96.146:80
[2995] Connecting to 45.55.96.146:80
[3266] Ready (ping: 150ms).

PING blynk-cloud.com (139.59.206.133) 56(84) bytes of data.
64 bytes from 139.59.206.133 (139.59.206.133): icmp_seq=1 ttl=55 time=24.1 ms
64 bytes from 139.59.206.133 (139.59.206.133): icmp_seq=2 ttl=55 time=24.7 ms

[lvennard]

Both devices are in the same country ? or you moved and left the arduino in the previous country?

Maybe try this (from the pc)?

http://45.55.96.146:8080/<token>/project

basically, skip dns and go right to the ip address.

[ldb]

Both devices are in the same country and same network.

http://45.55.96.146:8080/<token>/project will work, sure. My problem is that in the same code i use Blynk library and also query the project via HTTP, and this returns “invalid token” when i query for blynk-cloud.com/<token>/project

My question is more like, why one redirects to different IPs.

[lvennard]

Big guess here, but it sounds like you’re using seperate dns servers… i know thats not the case, but its just a vibe.

add this code to the esp ?

Ethernet.begin(mac, ip);
Serial.print("The DNS server IP address is: ");
Serial.println(Ethernet.dnsServerIP());

and run ipconfig /all on the pc

compare the dns server settings?

[ldb]

I’m on WiFI, and just for information, few years ago we had problems with GeoDNS and after further reading it still an issue for HTTP API: http://docs.blynk.cc/#http-restful-api
@Dmitriy is it the latest from the docs?

[PeteKnight]

Read his thread:

Load balancing deployment for local blynk server

Right now we use Geo DNS as load balancer. So when app/hardware connects to the closest server it checks if this is correct server. In most cases it is. Otherwise server returns redirect response with correct server address. Every server holds it’s own userbase, so this is more like sharding scheme that is based on location.

It explains why the app and your hardware code that uses Blynk.begin works correctly. You’re seeing the re-direction to the original server where your project lives.

It’s a bit ambiguous as to whether this same redirection occurs when calling the API, but issues with IFTTT and your own experience says that the issue still exists.

Fortunately for you, the solution is simple - update the API calls to 45.55.96.146 instead of blynk-cloud.com
You may get faster re-connections if you also specify 45.55.96.146 and port 80 in your Blynk connection code, rather than relying on the DNS redirection process.

Pete.

[Gunner]

@PeteKnight got it in one.

It’s a bit ambiguous as to whether this same redirection occurs when calling the API, but issues with IFTTT and your own experience says that the issue still exists.

Yes, still an issue…

the solution is simple - update the API calls to 45.55.96.146 instead of blynk-cloud.com

[lvennard]

good to know, i was under the assumption it was fixed.

https://docs.blynk.cc/#troubleshooting-geo-dns-problem

[PeteKnight]

But the screenshot from @Gunner above is taken from the same document, which is one of the reasons why I said that there’s some ambiguity.

I’ve also seen posts like this one:

Two Identical IFTTT Applets Google Assistant - One Works, the other one doesn't

OK, I just wanted to close the loop on this one. As @PeteKnight suggested, I decided to keep testing to try to figure out what was going on… Just because I like to get to the bottom of things (even if there are alternative solutions)… My conclusion is that IFTTT was having a glitch that day causing this strange behavior. I am saying this because, in addition to this issue, I wasn’t able to access the “New Applet” option from their webpage, the only way for me to do it was through the app… It wa…

which say that Geo DNS isn’t an issue with IFTTT anymore.

Personally, I think it’s as I said earlier - it’s not an issue with the app or code that uses Blynk.begin, but is still an issue with API calls.

So the documentation is correct, but ambiguous and somewhat contradictory.

Pete.

[Gunner]

Hey all,

This is just based on my observations over time, but the Documentation is fluid… molasses like, but fluid The Devs are busy deving, so Documentation takes time and effort they don’t always have.

But in this case I believe both references are correct, as the general more common GEO-DNS issue with Apps and sketch connection was fixed, but the same-in-name but less common and probably different in structure API method is seemingly not so much… yet.

I think Blynk is working on solutions for both Docs and issues as fast as they can… something about Blynk 2.0 keeps getting hinted at

[ldb]

Well, documentation being up to date or not, the issue mentioned only happened after moving from New Zealand to Denmark, therefore my assumption of GeoDNS.

Not a big deal at this stage as it can be “fixed” but good to know.