Unsere Kunden führen mit den folgenden Domänen eine ganze Reihe von Domänenprüfungen in Bezug auf das öffentliche DNS von Google durch <userid>.sip.teltel.io, die jedoch häufig fehlschlagen. Bei anderen, wie beispielsweise Cloudflare, sind die Prüfungen immer erfolgreich.
Wenn wir nslookup in einer Schleife in Richtung 8.8.8.8 ausführen, schlägt die Auflösung bei Google in etwa 80 % der Fälle fehl. In Richtung 1.1.1.1 ist es immer erfolgreich. Nachfolgend sehen Sie ein fehlgeschlagenes Beispiel:
Anfrage:
while :
do
nslookup 7157599388.sip.teltel.io 8.8.8.8
done
Antwort:
Server: 8.8.8.8
Address: 8.8.8.8#53
** server can't find 7157599388.sip.teltel.io: NXDOMAIN
Darüber hinaus schlägt das Diggen in Richtung 8.8.8.8 manchmal fehl, manchmal nicht:
Hat jemand eine Idee, warum?
Vielen Dank im Voraus!
Antwort1
Aus einer dig +trace 7157599388.sip.teltel.ioAbfrage:
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
Wir können sehen, dass die Subdomäne sip.teltel.io von den CloudFlare-DNS-Servern an die Nameserver ns1.teltel.io und ns2.teltel.io delegiert wird.
Zunächst einmal werden diese beiden Nameserver-Einträge beide auf 3.9.142.25 aufgelöst. Wenn Sie keine redundanten DNS-Server haben, können Sie genauso gut nur einen einzigen NS-Eintrag verwenden und mit diesem einzigen Ausfallpunkt leben.
Auch die Zone für die Subdomain sip.teltel.io enthält derzeit noch keine NS-Einträge und die Abfrage dig -t NS sip.teltel.io @ns1.teltel.ioschlägt weiterhin fehl. SieheWarum erfordern DNS-Zonendateien NS-Einträge?UndErläuterung, warum DNS-Zonendateien NS-Einträge erfordernfür eine detailliertere Begründung, warum das schlecht ist.
Ich weiß jedoch nicht, ob eines davon der Grund dafür ist, dass die Auflösung zeitweise fehlschlägt.