Zusammenfassung

  • Das DNS-Bit Authoritative Answer ist an den Namen in Question oder den ersten Owner-Namen in Answer gebunden. Aliasziele, Authority-Daten, Glue und Additional-RRsets derselben Nachricht können eine andere Herkunft haben.
  • Ein belastbarer Resolver-Beleg speichert für jedes RRset Owner, Typ, Abschnitt, Zonenschnitt, Cachequelle und DNSSEC-Status sowie die Folgeabfragen, statt ein Headerbit zur Autoritäts- oder Echtheitsaussage über das ganze Paket zu machen.

Ein Resolver fragt nach shop.example. Der angesprochene Server ist für diesen Namen autoritativ und liefert einen CNAME. Die Adresse des Ziels stammt aus seinem Cache; in Additional steht eine weitere Adresse, die einen zusätzlichen Schritt ersparen kann. AA ist gesetzt.

Das Betriebsarchiv schreibt dennoch nur authoritative=true neben die gesamte Nachricht. Als eine direkte Antwort aus der Zielzone später abweicht, fehlt die Erklärung. Die autoritative Aliasaussage, der Cachezeitpunkt und die Zusatzinformation wurden schon beim Einlesen zu einer Eigenschaft verschmolzen.

Das Szenario ist hypothetisch. Es beschreibt keinen bekannten Ausfall, sondern prüft die Beweisgrenzen des Datenmodells.

Das Bit hat einen Bezugspunkt

RFC 1035 von Paul Mockapetris definiert AA für Antworten: Der antwortende Nameserver ist für den Domainnamen im Question-Abschnitt autoritativ. Da Aliase mehrere Owner-Namen in Answer erzeugen können, ordnet der Text AA dem Abfragenamen oder dem ersten Owner-Namen in Answer zu.

AA ist folglich keine Folge von Einzelbescheinigungen für jedes RRset. Es beschreibt die Zuständigkeit des Servers am Anfang des Antwortpfades. Wer dieselbe Zuständigkeit auf spätere Namen, alle Abschnitte und jede Datenquelle überträgt, ergänzt etwas, das nicht im Header steht.

RFC 1034 zeigt, wie gemischte Herkunft entsteht. Findet ein Server in autoritativen Daten einen CNAME, kopiert er ihn nach Answer, setzt QNAME auf den kanonischen Namen und beginnt erneut. An einer Delegation kommen NS-RRs nach Authority; verfügbare Adressen werden aus Glue, autoritativen Daten oder Cache in Additional eingefügt. Vor dem Versand können weitere lokal verfügbare, nützliche RRs hinzukommen.

Eine Nachricht kann als Protokollantwort stimmig und als Beweismenge heterogen sein.

Abschnitte sind Kontext, kein Gütesiegel

RFC 1035 teilt die Rollen auf: Answer beantwortet die Frage, Authority weist zur Autorität, Additional trägt verwandte Information, die nicht streng die Antwort ist. Den Abschnitt aufzubewahren ist notwendig, aber noch keine vollständige Herkunftsbestimmung.

Bei einer Delegation liefert die Elternzone unter Umständen die Adresse eines Nameservers der Kindzone als Glue. Nur so lässt sich die zirkuläre Frage lösen, wie der Server erreicht werden soll, dessen Adresse man erst von ihm erfragen müsste. Nützlichkeit verleiht der Elternzone aber keine Autorität unterhalb des Zonenschnitts, und Glue wird nicht zur Aussage der Kindzone.

RFC 2181 ordnet Quellen ausdrücklich: Zonendatei und Zonentransfer ohne Glue, autoritative Answer-Daten, Authority einer autoritativen Antwort, Glue, nichtautoritative Answer-Daten und Additional haben verschiedene Ränge. Ein frisch autoritativ erhaltenes RRset kann einen älteren Additional-Cacheeintrag ersetzen; der schwächere Eintrag darf nicht allein wegen seiner Anwesenheit gewinnen.

Ohne Rang wäscht ein Cache den Kontext aus. Eine als Zusatz gelernte Adresse erscheint später in Answer und sieht aufgewertet aus. Ihre Verweildauer hat nur die Rest-TTL verändert, nicht ihren Herausgeber.

Ein Alias überschreitet eine Zuständigkeit

RFC 2181 nennt den entscheidenden Sonderfall: In einer autoritativen Antwort auf einen Alias ist nur das den Alias beschreibende RR zwingend autoritativ. Weitere Antwortdaten können aus dem Cache stammen. Benötigt der Client eine autoritative Auskunft zum kanonischen Namen, muss er diesen erneut abfragen.

RFC 6604 bekräftigt, dass die Autorität in einer CNAME- oder DNAME-Kette für jede Antwort verschieden sein kann. AA bleibt am ersten Owner in Answer verankert.

Der Server für shop.example darf also autoritativ auf service.vendor.test verweisen. Eine beigefügte Cacheadresse des Ziels ist praktisch, aber keine autoritative Aussage der Vendor-Zone. Der eigentliche Grenzübertritt ist die nächste Abfrage mit eigenem Server, Zeitpunkt und Beleg.

Das Modell sollte deshalb Kanten speichern: Eingangsname, CNAME- oder DNAME-RRset, Quellzone, Ursprungsantwort, Folgname und Folgeabfrage. Nur die Endadresse zu behalten beschleunigt Anwendungen, verhindert aber spätere Attribution.

Autorität ist keine Authentizität

RFC 6604 stellt klar, dass DNSSEC das AA-Headerbit nicht schützt. TSIG oder SIG(0) können die Transaktion zum Server absichern; DNSSEC validiert RRsets über eine andere Beweiskette.

RFC 4035 unterscheidet je RRset Secure, Insecure, Bogus und Indeterminate. RRSIG, DNSKEY, DS, Vertrauensanker, Negativbeweise und Richtlinien tragen das Ergebnis. AA trägt es nicht.

Auch AD ist kein stärkeres AA. Ein DNSSEC-fähiger Server darf AD nur setzen, wenn er die einschlägigen RRsets in Answer und Authority für authentisch hält. Der Client muss dem rekursiven Server und dem Kanal vertrauen oder selbst validieren. Additional wird durch das Headerkürzel nicht automatisch mitgeprüft.

Damit kann eine Nachricht gleichzeitig korrektes AA für den ersten Namen, einen Secure-CNAME, ein Insecure-Ziel, Glue in Additional und einen ungesicherten Weg zum Vermittler enthalten. Das Datenmodell muss diese Aussagen nebeneinander tragen können.

Was Mockapetris’ Name belegt

Das Internet Hall of Fame schreibt Paul Mockapetris die Erfindung des DNS im Jahr 1983 am Information Sciences Institute der USC zu. RFC 1034 und RFC 1035 nennen ihn als Autor. Das historische öffentliche Porträt der Seite dient als Identitätsgrundlage für die redaktionelle Illustration.

Keine dieser Quellen macht ihn zum Betreiber eines heutigen Servers, zum Eigentümer einer Zone oder zum Entscheider über eine aktuelle Implementierung. Spätere RFCs sind Gemeinschaftsarbeit. Die präzise Würdigung liegt darin, die Grenze der ursprünglichen Architektur zu erhalten: Verteilte Autorität erzeugt mehrere Nachweise, selbst wenn sie in einer Antwort transportiert werden.

RRsets quittieren statt Pakete einfärben

Der Beleg beginnt mit QNAME, QTYPE, QCLASS, Rekursionswunsch, DO/CD, Transaktions-ID und Sendezeit. Er bewahrt Antwortbytes, Endpunkt, Transport, Empfangszeit und Transaktionsauthentisierung.

Danach folgt ein Datensatz pro RRset: Owner, Typ, Klasse, Abschnitt, beobachtete TTL, Zonenschnitt, Bailiwick, bekannte Quelle, Cachezugang und Ablauf. Ist dem Client unbekannt, ob der Server Zone oder Cache nutzte, bleibt diese Unsicherheit offen; AA füllt sie nicht.

Der AA-Bezug wird gesondert notiert: ursprünglicher QNAME, erster Answer-Owner, Antwortserver und Autoritätszone. Jeder Alias und jede Delegation verweist auf eine Folgeabfrage. Eltern-NS, Glue und direkte Kindantwort bleiben verbunden, aber getrennt.

Der DNSSEC-Beleg ergänzt je RRset Status, Signaturen, DS/DNSKEY-Pfad, Vertrauensanker, Zeitpunkt und Fehlerursache. Empfangene AD-Werte bleiben Behauptungen des Upstreams. Schließlich wird festgehalten, welches RRset und welche Cachegeneration eine Anwendung nutzte.

Nun ist eine genaue Aussage möglich: Dieser Server setzte AA für diesen ersten Namen; dieses RRset kam aus diesem Abschnitt; dieser Validator gab ihm diesen Status; die nächste Abfrage belegte die Zuständigkeit des Folgnamens; die Anwendung nutzte dieses Ergebnis. Ein Bit bleibt nützlich, wenn es nicht mehr für die ganze Nachricht sprechen muss.

Quellen