1

Our customers make quite a few domain checks towards Google public DNS with the following domains <userid>.sip.teltel.io, but they often fail. To others, like Cloudflare it is always successful.

When we run nslookup in a loop towards 8.8.8.8, about 80% of the time Google fails to resolve. To 1.1.1.1 it is always successful. See below a failed example:

Request:

while :
do
    nslookup 7157599388.sip.teltel.io 8.8.8.8
done

Response:

Server:     8.8.8.8
Address:    8.8.8.8#53

** server can't find 7157599388.sip.teltel.io: NXDOMAIN

Additionally, when doing a dig towards 8.8.8.8 sometimes it fails, sometimes not: enter image description here Does anyone have an idea why?

Thank you in advance!

11lll
  • 41
  • 2
  • Is there any substantial difference between this question and your previous question https://serverfault.com/questions/1045308/8-8-8-8-fails-to-resolve-our-subdomains-randomly ? – Håkan Lindqvist Dec 09 '20 at 11:04
  • Does this answer your question? [8.8.8.8 Fails to resolve our subdomains randomly](https://serverfault.com/questions/1045308/8-8-8-8-fails-to-resolve-our-subdomains-randomly) – Håkan Lindqvist Dec 09 '20 at 11:04
  • Those seem to be 2 different things from our side and the answer in the previous question does not resolve the issue. – 11lll Dec 09 '20 at 11:37
  • I just added a screenshot to give a bit more details. – 11lll Dec 09 '20 at 11:40

1 Answers1

3

From a dig +trace 7157599388.sip.teltel.io query:

teltel.io.      86400   IN  NS  dina.ns.cloudflare.com.
teltel.io.      86400   IN  NS  kanye.ns.cloudflare.com.


sip.teltel.io.      1800    IN  NS  ns1.teltel.io.
sip.teltel.io.      1800    IN  NS  ns2.teltel.io.


ns1.teltel.io.      1800    IN  A   3.9.142.25
ns2.teltel.io.      1800    IN  A   3.9.142.25

7157599388.sip.teltel.io. 300   IN  A   104.248.101.248

We can see that the sip.teltel.io subdomain is delegated from the CloudFlare DNS servers to the ns1.teltel.io and ns2.teltel.io nameservers.

For starters those two nameservers records both resolve to 3.9.142.25. When you don't have redundant DNS servers you might as well only use a single NS record and live with that single point of failure.

Also the zone for the sip.teltel.io subdomain currently still does not contain any NS records and the query dig -t NS sip.teltel.io @ns1.teltel.io still fails. See Why do DNS zone files require NS records? and Clarification of why DNS zone files require NS records for more detailed reasoning of why that is bad.

I don't know if either of those is the reason resolving fails intermittently though.

Bob
  • 5,335
  • 5
  • 24