Auflösen eines CNAME - wer sucht nach einem A-Datensatz - Resolver oder Server?

Wenn ein Resolver einen CNAME nachschlägt, sendet der Resolver anscheinend zuerst eine A-Eintragsanforderung an den DNS-Server. Soll der DNS-Server herausfinden, dass es sich bei der Anforderung tatsächlich um einen CNAME handelt, oder soll der Resolver die Anforderung erneut versuchen, jedoch für einen CNAME-Typ? Ich frage, weil - und hier ist die Wendung - wir eine "interne" Top-Level-Domain haben, die wir in unserem internen LAN verwenden. Nennen wir sie "Domain1", und der DNS-Server, den ich abfrage, ist der autorisierende Server für "Domain1" (und ist für alles andere rekursiv.) Was mein Host (Centos 6.8) tatsächlich sendet, ist eine Anfrage nach einem A-Datensatz:

16:15:45.837525 IP (tos 0x0, ttl 64, id 36911, offset 0, flags [none], proto UDP (17), length 62)
myhost.domain1.40684 > dnsserver.domain1.domain: 15355+ A? cfengine.domain1. (34)
Reply - a servfail:
16:15:45.837762 IP (tos 0x0, ttl 64, id 49982, offset 0, flags [DF], proto UDP (17), length 62)
dnsserver.domain1.domain > myhost.domain1.40684: 15355 ServFail 0/0/0 (34)

Wenn ich nach einem CNAME-Typ suche, erhalte ich den richtigen CNAME-Datensatz (obwohl A rec nicht als ZUSÄTZLICHE Daten zurückgegeben wird):

cfengine.domain1.   3600    IN  CNAME   helm02.domain2.

Ja, ich weiß, dass es keine gute Praxis ist, autorisierende und rekursive Funktionen in einem einzigen DNS-Server zu kombinieren, aber ich habe keine Kontrolle über dieses DNS-Setup.

Wenn autorisierende und rekursive Funktionen zu einem einzigen Server kombiniert werden und Sie eine gewünschte Rekursionsabfrage für einen CNAME an den Server senden, für den der Server autorisierend ist - soll er überhaupt funktionieren?

Angenommen, es soll funktionieren. Wer ist dafür verantwortlich, dass meine Anfrage tatsächlich für einen CNAME-Datensatz und nicht für einen A-Datensatz gilt? Der DNS-Server oder mein Resolver?

Wenn ein Server für einen bestimmten Namen autorisierend ist und einen CNAMEDatensatz für diesen Namen hat, muss er mit diesem Datensatz auf Abfragen für alle Datensatztypen antworten.

Wenn ein Server eine Rekursion ausführt, nach einem Datensatztyp fragt, der dies nicht ist CNAME, aber eine CNAMEAntwort erhält , sollte er die Abfrage mit dem Namen aus dem CNAMEDatensatz neu starten , die Antwort aus der neu gestarteten Abfrage mit der CNAMEAntwort zusammenführen und die kombinierte Antwort zurückgeben für wen auch immer es die Rekursion machte.

Anders ausgedrückt, der autorisierende Server ist dafür verantwortlich, zu wissen, dass ein Name ein hat, CNAMEund damit auf alle Anfragen zu antworten, und der Rekorder ist dafür verantwortlich, zu bemerken, dass er eine CNAMERückmeldung erhalten hat, wenn er nach etwas anderem fragt, und entsprechend zu handeln. Wenn Sie speziell nach einem Datensatz fragenCNAME , umgehen Sie diese zusätzliche Magie und der Rekorder gibt Ihnen nur die CNAMEAntwort, wie sie ist, ohne zu versuchen, dem Namen zu folgen.

Das SERVFAILsollte verschwinden, wenn Sie diese Abfrage erneut mit versuchen +norecurse. dig geht davon aus, dass standardmäßig eine Rekursion gewünscht wird, und SERVFAIList die richtige Antwort auf die Rückgabe, wenn eine Rekursion angefordert wurde und das Ziel eines Alias ​​nicht aufgelöst werden konnte.

Rekursive Server, die Ihren autorisierenden Server abfragen, sollten die Anforderung nicht mit RD=1gesetztem Flag für die gewünschte Rekursion ( ) stellen. Kurz gesagt, Sie sollten dieses Problem nur in den folgenden zwei Szenarien sehen:

1. Sie führen diese Transaktion von Hand aus und vergessen, die Rekursion zu deaktivieren.
2. Jemand hat eine (schlechte) Implementierung eines rekursiven Nameservers geschrieben, und der Autor hat es versäumt, das gewünschte Rekursionsflag zu deaktivieren, wenn autorisierende Suchvorgänge durchgeführt werden. Ein rekursiver Nameserver sollte autorisierende Server nicht auffordern, in seinem Namen eine Rekursion durchzuführen.