Was sind DNS-Glue-Records und wann brauchen Sie sie

Was ist ein Glue Record?

Ein Glue Record ist die IP-Adresse eines Nameservers, die nicht in Ihrer eigenen Zone veröffentlicht wird, sondern eine Ebene höher — in der Elternzone, bei der Registry, über Ihren Registrar. Er existiert, um eine zirkuläre Abhängigkeit aufzulösen.

Nehmen wir example.com mit den Nameservern ns1.example.com und ns2.example.com. Ein Resolver, der www.example.com auflösen möchte, fragt zunächst die .com-Server, wer für example.com autoritativ ist. Die Antwort lautet „ns1.example.com und ns2.example.com“. Um diese Server überhaupt etwas fragen zu können, braucht der Resolver ihre IP-Adressen — doch die A-Records für ns1.example.com liegen innerhalb von example.com, auf genau den Servern, die er zu finden versucht. Ohne Hilfe kann die Auflösung nie beginnen.

Der Glue Record ist diese Hilfe: Zusammen mit den NS-Records geben die .com-Server die IP-Adressen von ns1 und ns2 in der Additional Section der Antwort mit. Der Resolver nutzt sie, erreicht die Nameserver, und die Zone funktioniert.

Sie können Glue in einer echten Delegation sehen, indem Sie einen TLD-Server nach Ihrer eigenen Domain fragen (die echte example.com ist an externe Nameserver delegiert und zeigt daher keines):

dig NS yourdomain.com @a.gtld-servers.net

Die Authority Section listet die NS-Namen; die Additional Section listet deren Glue-Adressen. Liegt ein Nameserver-Name innerhalb der Zone und erscheint für ihn nichts in der Additional Section, fehlt das Glue.

Wann Glue Records erforderlich sind

Glue ist genau dann erforderlich, wenn der Hostname eines Nameservers innerhalb der Zone liegt, die er ausliefert — DNS-Fachleute nennen das einen in-bailiwick Nameserver.

Erforderlich: example.com ist an ns1.example.com und ns2.example.com delegiert. Beide Namen liegen unter example.com, also brauchen beide Glue.

Nicht erforderlich: example.com ist an ns1.hosting-provider.net und ns2.hosting-provider.net delegiert. Ein Resolver findet diese Adressen über die .net-Delegation von hosting-provider.net; der Registrar von example.com hat nichts beizusteuern. Das ist der Alltagsfall, wenn Sie die Standard-Nameserver Ihres DNS-Anbieters verwenden.

Ein gemischter Fall: example.com ist an ns1.example.com und ns3.seconddns.com delegiert — ein in-bailiwick Name, der Glue braucht, und ein externer Name, der keines braucht. Das ist die typische Konstellation, wenn Ihr eigener Server der primäre ist und ein gehosteter sekundärer Nameserver unter seinem eigenen Hostnamen antwortet.

Die Regel gilt pro Nameserver-Name, nicht pro Zone: Prüfen Sie jeden NS-Record und fragen Sie, ob dieser Name innerhalb der delegierten Zone liegt.

Wo Glue Records liegen

Glue ist kein Record, den Sie in Ihre eigene Zonendatei eintragen. Es gehört in die Elternzone — die TLD-Registry — und der einzige Weg dorthin führt über Ihren Registrar, denn der Registrar ist derjenige, der in Ihrem Auftrag mit der Registry spricht.

Jeder Registrar bietet dies irgendwo in den Einstellungen der Domain an, unter stark variierenden Bezeichnungen:

- „Nameserver registrieren“ / „Host registrieren“ - „Child Nameserver“ / „Child Hosts“ - „Host-Records“ / „Glue Records“ - „Private Nameserver“ / „Eigene Nameserver“

Wie auch immer es heißt, das Formular fragt zwei Dinge ab: den Hostnamen des Nameservers (ns1.example.com) und seine IP-Adresse (IPv4 und, falls vorhanden, IPv6). Nach dem Absenden veröffentlicht die Registry das Glue in der TLD-Zone; von da an antworten die .com-Server damit.

Daraus folgen zwei Dinge. Das Glue ist eine Kopie der Adresse Ihres Nameservers, die beim Registrar von Hand gepflegt wird — ändert sich die IP des Servers, ändert sich das Glue nicht automatisch mit. Und der Record in Ihrer eigenen Zone (der A-Record für ns1.example.com) muss weiterhin existieren und übereinstimmen: Resolver nutzen das Glue zum Einstieg und vertrauen danach dem, was Ihre Zone sagt.

Was ohne Glue kaputtgeht

Fehlendes Glue. Die Delegation zeigt auf ns1.example.com, aber die Registry hat keine Adresse dafür. Resolver können die Nameserver nicht erreichen; die Domain löst überhaupt nicht auf. Manche Resolver geben sich mehr Mühe als andere, deshalb tritt der Fehler oft uneinheitlich auf — „bei mir funktioniert es, bei den Kunden nicht“ — was die Diagnose erschwert.

Veraltetes Glue. Sie haben den Server umgezogen, den A-Record in der Zone aktualisiert und den Registrar vergessen. Die Registry gibt weiter die alte IP heraus. Resolver, die dem Glue folgen, landen bei einer toten Adresse oder, schlimmer, bei demjenigen, dem diese IP inzwischen gehört. Da die meisten Resolver den funktionierenden Nameserver lange im Cache halten, kann dieser Ausfall erst Tage nach der Migration sichtbar werden.

Glue ohne passenden A-Record. Die Registry sagt, ns1.example.com sei 192.0.2.10; Ihre Zone sagt nichts oder etwas anderes. Glue ist nicht autoritativ: Sobald ein Resolver die Adresse aus der Zone selbst erfährt, verwendet er diese statt des Glue. Ein falscher A-Record in der Zone setzt sich also gegenüber korrektem Glue durch, während ein fehlender A-Record das Glue in Kraft lässt. Halten Sie beides synchron.

Lame Delegation. Das Glue ist korrekt, die Adresse antwortet, aber der Server liefert die Zone tatsächlich nicht aus — typisch, wenn ein Nameserver außer Betrieb genommen oder eine Zone auf einem sekundären Server nie geladen wurde. Manche ccTLD-Registries prüfen das bei einer Delegationsänderung (gTLD-Registries nicht), und Monitoring-Werkzeuge melden es; Resolver behandeln den Server als defekt und weichen auf die anderen aus, sofern es welche gibt.

Alle vier Fälle schlagen aus Sicht des Betreibers still fehl: Nichts in Ihren Logs sagt „Glue ist falsch“. Das Symptom zeigt sich immer weiter hinten — sporadische Auflösungsfehler, langsame Abfragen, Mailverzögerungen —, daher lohnt es sich, die Delegation ausdrücklich zu prüfen.

Delegation und Glue mit dig prüfen

Verfolgen Sie die Delegation von der Root abwärts, um genau zu sehen, was jede Ebene herausgibt:

dig +trace www.example.com @1.1.1.1

Der Resolver wird ausdrücklich angegeben, weil +trace ihn nur nach dem Root-NS-Set fragt und die Delegation von dort selbst durchläuft; jeder Resolver, der dieses Set zurückliefert, funktioniert.

Suchen Sie in der Ausgabe den Schritt, in dem die TLD-Server für example.com antworten: Die dortigen NS-Records sind die Delegation. Beachten Sie, dass +trace nur die Delegation selbst ausgibt, nicht die Additional Section, und daher kein Glue zeigt. Um das Glue zu sehen, wählen Sie einen beliebigen autoritativen Server der TLD und fragen ihn direkt nach dem NS-Set:

dig NS example.com @a.gtld-servers.net +norecurse

Die Additional Section zeigt das Glue so, wie die Elternzone es sieht; ein in-bailiwick Nameserver ohne Eintrag dort hat kein Glue. Vergleichen Sie es mit dem, was Ihre eigene Zone sagt:

dig A ns1.example.com @ns1.example.com +short

Die beiden Adressen müssen übereinstimmen. Bestätigen Sie schließlich, dass jeder aufgeführte Nameserver die Zone tatsächlich ausliefert und dieselbe Version hat:

dig SOA example.com @ns1.example.com +short
dig SOA example.com @ns2.example.com +short

Beide sollten autoritativ mit derselben Seriennummer antworten. Ein REFUSED oder SERVFAIL an dieser Stelle ist eine Lame Delegation; eine Seriennummer, die auf einem Server hinterherhinkt, bedeutet, dass die Zonentransfers nicht Schritt halten — siehe Was ist ein DNS-SOA-Record.

Glue Records und sekundäre Nameserver

Glue kommt am häufigsten ins Spiel, wenn jemand einen zweiten Nameserver unter der eigenen Domain hinzufügt. Zwei Konstellationen, zwei verschiedene Antworten:

Sekundärer Nameserver unter dem Hostnamen des Anbieters. Ihre Zone ist an ns1.example.com (Ihr Server) und an den eigenen Namen des Secondary-Anbieters delegiert, etwa ns3.seconddns.com. Nur ns1 ist in-bailiwick, also braucht nur ns1 Glue. Beim Registrar ändert sich nichts, wenn sich die Adressen des Anbieters ändern.

Sekundärer Nameserver unter Ihrem eigenen Hostnamen — ein personalisierter oder Vanity-Nameserver wie ns2.example.com, der auf den Server des Anbieters zeigt. Jetzt ist auch ns2 in-bailiwick und braucht Glue mit der IP-Adresse des Anbieters. Sie tragen es beim Registrar genau wie ns1 ein und müssen es aktuell halten: Ändert der Anbieter diese Adresse jemals, muss das Glue nachziehen. Außerdem brauchen Sie den passenden A-Record für ns2.example.com in Ihrer eigenen Zone, der dann mit jedem Zonentransfer zum sekundären Server wandert.

Das ist der Schritt, der beim Einrichten eigener Nameserver am häufigsten übersprungen wird, und der Grund, warum ein sekundärer Server, der perfekt synchron ist, trotzdem keine Anfragen erhält. Die vollständige Einrichtung — Hostname, Glue, A-Records und Prüfung — finden Sie unter Personalisierte Nameserver: Einrichtung, Glue-Records und Stolperfallen.

Häufige Fehler

- Den A-Record ändern, aber nicht das Glue nach einem Serverumzug. Aktualisieren Sie beides und prüfen Sie anschließend die Elternzone mit dig. - Glue für Namen außerhalb der Zone hinzufügen. Die meisten Registrare lehnen das ab; die, die es annehmen, veröffentlichen Daten, die die Elternzone nie verwenden wird. Registrieren Sie nur Namen unterhalb der Domain selbst. - Glue mit privater oder falscher IP. Registrare validieren wenig; ein Tippfehler geht bei der Registry live. Prüfen Sie mit einer Anfrage an die TLD-Server, nicht nur an Ihren eigenen Nameserver. - IPv6 vergessen. Hat Ihr Nameserver einen AAAA-Record, registrieren Sie auch das IPv6-Glue, sonst können reine IPv6-Resolver ihn nicht erreichen. - Sofortige Wirkung erwarten. Große gTLD-Registries veröffentlichen Änderungen innerhalb von Minuten, während manche ccTLDs ihre Zone stündlich oder nur wenige Male am Tag neu erzeugen — und Resolver halten die vorherige Delegation bis zur TTL der Elternzone im Cache, bei .com üblicherweise 48 Stunden. Planen Sie IP-Änderungen von Nameservern mit Überlappung: Lassen Sie die alte Adresse weiter antworten, bis die Caches abgelaufen sind. - Nur ein in-bailiwick Nameserver mit Glue. Hat ns1 Glue und ns2 (ebenfalls in-bailiwick) nicht, funktioniert die Zone nur, solange ns1 erreichbar ist — was den Sinn von zwei Nameservern zunichtemacht.