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, about 80% of the time Google fails to resolve. To it is always successful. See below a failed example:


while :
    nslookup 7157599388.sip.teltel.io



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

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

Thank you in advance!


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
ns2.teltel.io.      1800    IN  A

7157599388.sip.teltel.io. 300   IN  A

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.