Wie behebe ich das Problem "no GLUE" bei DNS-Lookups?

Wenn ich meine Domain unter http://www.intodns.com nachschlage, tritt folgendes Problem auf:

GLUE wurde nicht gesendet, als ich Ihre Nameserver nach Ihren NS-Datensätzen fragte. Dies ist in Ordnung, aber Sie sollten wissen, dass in diesem Fall eine zusätzliche Suche nach einem Datensatz erforderlich ist, um die IP-Adressen Ihrer NS-Datensätze abzurufen. Sie können dies beispielsweise beheben, indem Sie Ihren Nameservern A-Datensätze für die oben aufgeführten Zonen hinzufügen.

Aber ich habe A-Einträge für alle meine Nameserver in jedem Zoneneintrag:

ns1.example.com. IN A <IP>
ns2.example.com. IN A <IP>

Wie behebe ich dieses Kleberproblem?

Leimdatensätze sind spezielle A-Datensätze, die benötigt werden, wenn sich der Nameserver für eine DNS-Domäne selbst in derselben Domäne befindet.

Wenn Ihre Domain beispielsweise example.com und Ihr Nameserver ns.example.com lautet, müssen Sie in der nächsthöheren DNS-Zone, in diesem Fall in der, einen "Glue" -Eintrag für ns.example.com erstellen "com" Zone. Dies sollte über Ihren Registrar erfolgen.

Dies ist erforderlich, da DNS-Anforderungen für Nameserver (NS-Einträge) immer mit einem Namen und nicht mit einer IP beantwortet werden.

Ohne einen Leimsatz würde ein Nameserver, der "com" bedient, den NS-Datensatz für "example.com" als "ns.example.com" (keine IP) zurückgeben, wenn eine Anfrage für die A-Datensätze "www.example.com" gestellt würde Die ursprüngliche Anfrage hätte keine Möglichkeit, gelöst zu werden, da jeder weitere Versuch, ns.example.com zu lösen, lediglich auf ns.example.com verweisen würde.

Das Problem mit GLUE von den Stamm-DNS-Servern ist, wenn Sie die folgende Situation haben:

example.com hat die DNS-Einträge ns1.example.net und ns2.example.net als NS-Server. Die .com-Berechtigung, bei der der DNS-Resolver nach dem Domänennamen suchen wird, kann die IP-Adressen für ns1.example.net und ns2.example.net NICHT bereitstellen, da sie nicht in seiner Berechtigung sind.

Die Möglichkeit, dies zu beheben, besteht darin, dass eine .com-Domäne von .com stammende NS-Server verwendet. Example.com würde also ns1.example-2.com und ns2.example-2.com verwenden, und alles wird in Ordnung sein, da die .com-Behörde die IP-Adresse für den Nameserver bereitstellen kann. Dies erspart mehrere Roundtrips zu den Root-DNS-Servern, da in Ihrem Fall für example.com jetzt auch .net nach example.net gefragt werden muss.

In meinem Fall haben alle meine Domains ihre eigenen NS-Einträge, also habe ich für example.com a.ns.example.com und b.ns.example.com und für meine example.net-Domain a.ns.example .net und b.ns.example.net.

Es ist mehr Setup erforderlich, und möglicherweise sind nicht alle Hosts dazu bereit. Sie können mit dem, was Sie derzeit haben, stecken!

Wenn ich das Tool selbst versuche und sehe, was es mit einigen mir vertrauten Domänen meldet, würde ich sagen, dass es eine Reihe von Dingen sein kann, die zu dieser Informationsnachricht führen (beachten Sie, dass es ein 'i' für Information ist, kein 'i' für Information) '!')

Beispielsweise hat eine meiner Zonen Nameserver außerhalb der Zone, und von den maßgeblichen Nameservern für die Zone haben nicht alle A-Datensätze in ihren maßgeblichen Daten, die in einer Antwort zurückgegeben werden sollen.

Aber das ist in Ordnung - jeder abfragende Nameserver sollte solchen Daten sowieso nicht vertrauen. Vor langer Zeit wären Sie damit durchgekommen, aber heutzutage könnte jeder Nameserver versuchen, zu lügen und sich aus Zonendaten in Ihren Cache zu schleichen.

Also mach dir keine Sorgen. Wenn die Abfrage Ihren Nameserver erreicht, wurden bereits einige der IP-Adressen Ihrer Nameserver gefunden. Sorgen Sie sich mehr darum, dass die Delegierungen mit Ihren eigenen Zonendaten übereinstimmen (nächster Eintrag: "Nicht übereinstimmende NS-Datensätze") und dass keine lahm sind ("Nameserver sind lahm: Alle auf den übergeordneten Servern aufgelisteten Nameserver antworten maßgeblich für Ihre domain "- falsch formuliert, aber Sie möchten sicherstellen, dass dort ein Häkchen steht.)