Home / server / Questions / 1045308
In Process
11lll
Asked: 2020-12-08 07:52:47 +0800 CST

8.8.8.8 Fails to resolve our subdomains randomly

  • 772

We have a lot of users on our VoIP software. The softphone checks each user's domain every minute, users make calls, send messages, etc. the usual VoIP stuff. Each user usually makes DNS checks several times a minute and altogether there are quite a few requests.

We cannot control to which public DNS the end-user tries resolving. When it is to Google public DNS sometimes, randomly it fails. To others like Cloudflare (1.1.1.1) it always works.

We've researched this and the issue is not the amount of DNS checks from the end-user towards Google DNS, which we know has a limit. Actually, the issue is from Google DNS to our Name Server when Google refuses to check the subdomain SOMETIMES. It seems that there is another limit here.

Here is an example of an unsuccessful request towards 8.8.8.8 after a nslookup (the domain exists).

dns.google can't find 7157599388.sip.teltel.io: Non-existent domain

Any idea how to change this limit?

Help will be highly appreciated!

Thank you in advance!

domain-name-system domain google resolve public

1 Answers

  1. I can't be completely sure what causes 8.8.8.8 to (sometimes) fail to resolve your names, but I can see one thing that is broken and could potentially cause problems.

    The nameserver for the sip.teltel.io zone responds nonsensically to sip.teltel.io NS queries:

    $ dig @ns1.teltel.io sip.teltel.io NS +norec

; <<>> DiG 9.11.24-RedHat-9.11.24-2.fc33 <<>> @ns1.teltel.io sip.teltel.io NS +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40833
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;sip.teltel.io.                 IN      NS

;; ANSWER SECTION:
sip.teltel.io.          3600    IN      CNAME   www.teltel.io.

;; Query time: 82 msec
;; SERVER: 3.9.142.25#53(3.9.142.25)
;; WHEN: Mon Dec 07 17:20:52 UTC 2020
;; MSG SIZE  rcvd: 60

$

    Which means that if 8.8.8.8 were to cache the sip.teltel.io NS response it would know that there are no nameservers, which could potentially be the reason for your troubles.

    • 4