11lll

Asked: 2020-12-16 11:06:11 +0800 CST2020-12-16 11:06:11 +0800 CST 2020-12-16 11:06:11 +0800 CST

Subdomain sometimes fails to resolve towards 8.8.8.8

We took care of implementing the changes you suggested for sip.teltel.io in our previous questions, but it did not improve.

UPDATE:

We even made a test subdomain xip.teltel.io which is set up exactly the same way as sip.teltel.io and when resolving that domain towards 8.8.8.8 it works fine every time. The only difference between sip.teltel.io and xip.teltel.io is the load: sip receives our customer's traffic and xip only our test requests.

How can you explain that?

Here is what we also noticed: When resolving towards 8.8.8.8 from a local wi-fi or a personal hotspot, etc. it sometimes fails. Responses are received from these Google IP addresses:

74.125.46.10
74.125.112.1
74.125.112.9
74.125.x.x
74.125.z.z
74.125.w.w

But when resolving towards 8.8.8.8 from a server on AWS or DO it always succeeds. The responses are received from different Google IP addresses:

172.253.199.4
172.253.1.194
172.217.33.132

Does Google give a higher priority for big customers like AWS or DO vs the public...? Or is there a different explanation?

We captured the traffic by performing a tcpdump (tcpdump udp and port 53) and noticed that when Google fails to resolve, our name servers never receive a request from Google.

This sometimes fails with "sip" - while true; do dig A 42894078.sip.teltel.io @8.8.8.8; done;

This is always OK with "xip"- while true; do dig A 42894078.xip.teltel.io @8.8.8.8; done;

Can you help us solve this? It all seems quite mysterious to us.

Thanks!