Ich bin etwas verwirrt über den Funktionsumfang von Autoritäts- und zusätzlichen Ressourceneinträgen.
Der Autoritätsbereich scheint mir normalerweise SOA-Einträge (negative Antwort) oder NS-Einträge (die auf autoritative Nameserver verweisen) zu enthalten.
Der zusätzliche Abschnitt scheint mir normalerweise Datensätze zu übersetzen, die sich entweder im Antwortabschnitt (MX) oder im Autoritätsabschnitt (NS) befinden. Deshalb enthält er normalerweise A- und AAAA-Datensätze. Aber ich habe auch gesehen, dass er manchmal OPT-Header enthält (obwohl ich mit DNS-Optionen nicht vertraut bin).
Ich habe RFC1034 und RFC1035 durchgesehen und tatsächlich waren darin keine weiteren Anwendungsfälle enthalten. Gibt es weitere Anwendungsfälle für diese Abschnitte?
Antwort1
Ich würde sagen, das Wichtigste, worüber man nachdenken muss, um die Abschnitte zu verstehen und zu wissen, welche RRs wohin gehören, ist, dass es im Allgemeinen nicht der RR-Typ selbst ist, der vorgibt, in welchen Abschnitt er gehört (zumindest nicht eindeutig), sondern dass der Grund, warum der RR der Antwort hinzugefügt wird, vorgibt, wohin der RR gehört.
Nun sind natürlich nur einige RR-Typen für einige dieser Fälle relevant, es besteht also eine Verbindung, aber ein RR-Typ kann je nach Situation normalerweise in verschiedenen Abschnitten vorhanden sein.
Autoritätsabschnitt
RRs mit Behördeninformationen, sowohl in Verweisungen als auch in Antworten der Behörde.
Zugehörige RR-Typen: SOA(negative Antwort), NS(Verweise, auch wenn in autoritativen Antworten angehängt), DS(Verweise).
Zusätzlich: RRSIG, NSEC(oder Varianten NSEC3, ...)
Antwortabschnitt
Die RRs stellen die direkte Antwort auf die Frage dar
Zugehörige RR-Typen: der angeforderte RR-Typ (einschließlich SOA, NS, DS, usw., wenn Sie diese explizit abfragen) oder CNAMEob der Name ein Alias ist. (Oder was auch immer existiert, wenn ANYangefordert wird.)
Zusätzlich:RRSIG
Zusätzlicher Abschnitt
Ressourcendatensätze, die nicht angefordert wurden, sich aber auf die Daten in der tatsächlichen Antwort beziehen. (Sollten vom Client mit großer Vorsicht verwendet werden.)
Wird auch beim Anhängen von RRs verwendet, die Daten für zusätzliche DNS-Protokollfunktionen wie EDNS, TSIG usw. enthalten.
Zugehörige RR-Typen: normalerweise A/ AAAA(Adressdatensätze, die für die eigentliche Antwort relevant sind)
Zusätzlich: RRSIG
DNS-Protokollerweiterung: OPTfür zusätzliche DNS-Header in EDNS(0), TSIGfür DNS-Nachrichtenauthentifizierung, SIGfür SIG(0)-Variante der Nachrichtenauthentifizierung usw.
RFC1034 und RFC1035 waren die ursprünglichen Haupt-DNS-RFCs, aber das sind Dokumente aus dem Jahr 1987, die offensichtlich nicht die Entwicklung abdecken, die von diesem Zeitpunkt an bis zu dem, was wir heute haben, fortgesetzt wurde. Es gibtvieleRFCs, die auf dieser Grundlage weiter aufgebaut wurden.