0

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

Subdomain hosted on AWS sometimes doesn't resolve towards 8.8.8.8

8.8.8.8 Fails to resolve our subdomains randomly

8.8.8.8 returns NXDOMAIN randomly for all our subdomains

UPDATE:

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

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

  1. 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.
  1. Here you can test the loops for yourself:

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!

11lll
  • 41
  • 2
  • Point 3 does not prove anything. By definition recursive caching nameserver do not contact authoritative ones for all and any queries, they keep (or try to keep) results for the length of the TTL... – Patrick Mevzek Dec 15 '20 at 22:04
  • Also, do you know that `8.8.8.8` is just NOT the alpha and omega of the Internet and that there are other public recursive nameservers? Why do you focus only on this? DNSviz shows no problem for both `sip.` and `xip.`, or the name below, and your loop even works as is correctly for me, – Patrick Mevzek Dec 15 '20 at 22:10
  • @Patrick The problem is that our customers who use our app often do it via 8.8.8.8. It is unfortunately not our choice... e.g. 1.1.1.1 does not show the problem. Secondly, when it does not find the domain in the cache it should ask the name server, but it does not. We checked. Instead it returns NXDOMAIN – 11lll Dec 29 '20 at 14:58

0 Answers0