Richtlinien für EDNS-Clientsubnetze (EDNS)

Einführung

RFC 7871 – Client-Subnetz in DNS-Abfragen – definiert einen Mechanismus für rekursive Resolver wie Google Public DNS, um unvollständige Client-IP-Adressen an autoritative DNS-Nameserver zu senden. Content Delivery Networks (CDNs) und latenzempfindliche Dienste nutzen diese Option, um genaue Standortantworten bereitzustellen, wenn auf die Namenssuche über öffentliche DNS-Resolver reagiert wird.

Im RFC werden ECS-Features beschrieben, die von autoritativen Nameservern implementiert werden müssen. Implementierungen halten sich jedoch nicht immer an diese Anforderungen. Es gibt auch Probleme bei der Betriebs- und Bereitstellung von ECS, die von RFC nicht behandelt werden und die Probleme für Resolver wie Google Public DNS verursachen können, die die ECS-Unterstützung auf autoritativen Nameservern automatisch erkennen, sowie Resolver, die eine ECS-Zulassungsliste erfordern, wie OpenDNS.

Diese Richtlinien sollen autoritativen DNS-Implementierungen und -Operatoren dabei helfen, viele häufige Fehler zu vermeiden, die zu Problemen bei ECS führen können.

Begriffsdefinition

Wir verwenden die folgenden Begriffe, um ECS-Vorgänge zu beschreiben:

  • Ein Nameserver implementiert (oder unterstützt) ECS, wenn er auf ECS-Abfragen mit ECS-Antworten antwortet, die übereinstimmende ECS-Optionen haben (auch wenn die ECS-Optionen immer eine globale Präfixlänge von /0 haben).

  • Eine Zone ist ECS-aktiviert, wenn ECS-Abfragen an seine Nameserver mit einem Quellpräfix ungleich null ECS-Antworten mit einem Bereich ungleich null empfangen.

Richtlinien für autoritative Nameserver

  1. Alle autoritativen Nameserver für eine ECS-fähige Zone müssen ECS für die Zone aktivieren.

    • Selbst wenn nur ein Nameserver ECS nicht implementiert oder ihn für die Zone nicht aktiviert, wird er schnell zur Quelle der meisten im Cache gespeicherten Daten. Da ihre Antworten globalen Gültigkeitsbereich haben, werden sie (bis zum Ablauf der TTL) als Antwort auf alle Abfragen mit demselben Namen verwendet (unabhängig vom Subnetz des Clients). Antworten von Servern, die ECS implementieren und sie nur aktivieren, werden nur für Abfragen von Clients innerhalb des spezifischen Gültigkeitsbereichs verwendet, sodass sie mit einer geringeren Wahrscheinlichkeit als die Antworten im globalen Geltungsbereich verwendet werden können.

  2. Autoritative Nameserver, die ECS einrichten, MÜSSEN2 ECS-Antworten an ECS-Abfragen für alle Zonen senden, die von einer IP-Adresse oder einem NS-Hostnamen bereitgestellt werden, auch für Zonen, die nicht ECS aktiviert sind.

    • Google Public DNS erkennt die ECS-Unterstützung automatisch anhand der IP-Adresse und nicht anhand des Nameserver-Hostnamens oder der DNS-Zone, da die Anzahl der Adressen kleiner als die Anzahl der Nameserver-Hostnamen und deutlich kleiner als die Anzahl der DNS-Zonen ist. Wenn ein autoritativer Nameserver nicht immer ECS-Antworten an ECS sendet (auch für Zonen, die nicht aktiviert sind), kann es sein, dass das Google Public DNS keine ECS-Abfragen mehr sendet.

  3. Autoritative Nameserver, die ECS implementieren, müssen auf alle ECS-Abfragen mit ECS-Antworten antworten, einschließlich negativer und Verweisantworten.

    • Die gleichen Probleme bei der automatischen Erkennung der ECS-Unterstützung gelten auch hier.

    • Für negative Antworten (NXDOMAIN und NODATA) SHOULD3 wird der globale /0-Bereich verwendet, um das Caching und die Kompatibilität mit RFC 7871 zu verbessern.

    • Neben NXDOMAIN und NODATA (NOERROR mit leerem Antwortbereich) sollten andere Fehlerantworten auf ECS-Abfragen (insbesondere SERVFAIL und REFused) eine übereinstimmende ECS-Option mit dem globalen /0-Bereich enthalten.

      • Wenn ein autoritativer Nameserver versucht, die Last eines DoS-Angriffs zu entlasten, kann er ein SERVFAIL ohne ECS-Daten zurückgeben. Dies führt dazu, dass Google Public DNS wiederholt keine Anfragen mehr an ECS sendet (was die Anzahl der von ihnen gesendeten legitimen Abfragen, die jedoch keine zufälligen Abfragen von Subdomain-Angriffen betreffen würden, reduziert). Die Reduzierung der zulässige Anzahl von Abfragen während eines DoS-Angriffs kann die Erfolgsquote für legitime Abfragen verbessern oder verbessern. Antworten können jedoch für alle Clients aus dem Cache bereitgestellt werden.

        Ein effektiverer Load-Sheding-Ansatz besteht darin, alle Antworten mit dem globalen /0-Bereich zu senden, damit das Google Public DNS weiterhin ECS-Abfragen sendet. So kann Google Public DNS nach dem Ende des Angriffs noch viel geografische Antworten zurückgeben, da die ECS-Unterstützung nicht neu erkannt werden muss, sondern nur noch nach Ablauf der globalen Gültigkeitsdauers-TTLs noch einmal abgefragt werden muss.

    • Antwortantworten (Delegation) müssen auch übereinstimmende ECS-Daten haben und SHOULD4 müssen einen globalen /0-Bereich haben. Beachten Sie, dass Delegierungsantworten nie an die Clients weitergeleitet werden, deren Adressen in ECS-Daten angezeigt werden. Daher sollten alle georeferenzierten NS-, A- oder AAAA-Einträge durch die Client-IP-Adresse von resolver's ausgewählt werden, nicht für ECS-Daten.

  4. Autoritative Nameserver, die ECS implementieren, müssen in den Antworten auf alle Abfragetypen, die mit einer ECS-Option empfangen werden, eine passende ECS-Option enthalten. Es ist nicht gut genug, um auf IPv4-Adressenanfragen (A) mit ECS-Daten zu antworten. Antworten auf A-, AAAA-, PTR-, MX- oder alle anderen Abfragetypen müssen übereinstimmende ECS-Daten oder Resolver enthalten, um die Antwort als möglicherweise gefälschte Antwort zu verwerfen, und das Google Public DNS kann das Senden von Abfragen mit ECS-Daten beenden.

    ECS-Antworten auf SOA-, NS- und DS-Abfragen sollten immer den globalen /0-Bereich verwenden, um ein besseres Caching und eine konsistente Delegierung zu ermöglichen. Antworten auf geografische A/AAAA-Abfragen für Nameserver-Hostnamen sind zulässig. Antworten auf alle Abfragetypen (z. B. TXT, PTR usw.), die sich nicht auf der Grundlage von ECS-Daten ändern, sollten keinen Bereich verwenden, der der Länge des Quellpräfixes entspricht. Für ein besseres Caching und eine geringere Abfragelast sollten sie einen globalen /0-Bereich verwenden.

  5. Autoritative Nameserver, die ECS-fähige CNAME-Antworten zurückgeben, sollten5 nur den ersten CNAME-Eintrag in der Kette enthalten und das endgültige Ziel der CNAME-Kette sollte ECS-fähig sein und dieselbe Länge des Bereichspräfixes haben. Aufgrund von Unklarheiten in der ECS-Spezifikation geben einige rekursive Resolver (insbesondere Unbound6) möglicherweise eine Antwort mit dem Bereich der endgültigen Nicht-CNAME-Domain zurück (/0, wenn sie nicht ECS-fähig ist).

  6. ECS-Daten können auch für Nur-IPv4-Nameserver IPv6-Adressen enthalten (und umgekehrt, wenn nur IPv6-Nameserver verwendet werden).

    • Nameserver müssen mit gültigen ECS-Optionsdaten antworten. (Der Bereich /0 ist in Ordnung, aber die Quelladresse und die Präfixlänge müssen übereinstimmen.)

    • ECS für eine Zone kann separat für IPv4- und IPv6-Adressen aktiviert werden.

  7. Autoritative Nameserver, die ECS-fähige Antworten zurückgeben, dürfen keine7 Bereichspräfixe in ihren Antworten überschneiden. Beispiele für sich überschneidende Bereichspräfixe:

    • Abfrage mit Quellpräfix 198.18.0.0/15: Antwort A mit Bereichspräfix 198.0.0.0/8

    • Abfrage mit Quellpräfix 198.51.100/24: Antwort B mit Bereichspräfix 198.51.0.0/16

    Wenn ein Client einen ECS-fähigen rekursiven Resolver in der oben genannten Reihenfolge abfragt, können beide Abfragen Antwort A erhalten, da der Bereich der im Cache gespeicherten Antwort A den Präfixbereich der zweiten Abfrage enthält. Auch wenn die Clientabfragen in umgekehrter Reihenfolge ausgeführt werden und beide Abfragen an autoritative Nameserver weitergeleitet werden, können im Cache gespeicherte Antworten zu unterschiedlichen Zeiten ablaufen. Nachfolgende Abfragen an den rekursiven Resolver im überlappenden Präfix 198.51.100/24 könnten entweder Antwort A oder B erhalten.

  8. Wenn Sie die ECS-Unterstützung zum ersten Mal auf Nameservern implementieren, verwenden Sie neue IP-Adressen für Nameserver, die diese aktivierten ECS-Zonen bereitstellen.

    • Wenn autoritative Nameserver, bei denen ECS implementiert wurde, aber Ergebnisse im globalen Bereich zurückgegeben haben, für eine Zone aktivierte ECS-Antworten zurückgeben, startet Google Public DNS die Rückgabe geografischer Antworten auf Abfragen, sobald die TTLs der vorherigen Antworten im globalen Bereich ablaufen.

    • Die automatische Erkennung der ECS-Unterstützung von Google Public DNS führt nur in seltenen Fällen dazu, dass ECS-Abfragen nach einer IP-Adresse (oder einem Nameserver-Hostnamen) gesendet werden, wenn eine automatische Erkennung der ECS-Unterstützung vorliegt (Zeitüberschreitungen, Rückgabe von FORMERR-, BADVERS- oder Senden von Nicht-ECS-Antworten). Neue ECS-Implementierungen für diese IP-Adressen (oder NS-Hostnamen) werden sehr langsam oder überhaupt nicht automatisch erkannt.

  9. Achten Sie darauf, dass die Netzwerkverbindungen zuverlässig sind und dass die Begrenzung der Antwortrate so hoch eingestellt ist, dass Nameserver keine Abfragen unterbrechen (oder schlimmer noch, wenn Fehler auftreten, wenn keine übereinstimmende ECS-Option vorhanden ist).

    • Für Nameserver, die eine Beschränkung der Antwortrate in ECS-Abfragen implementieren, ist NODATA die beste Antwort, wenn das Flag für die Kürzung (TC) festgelegt ist, das nur einen passenden Frageabschnitt und eine übereinstimmende ECS-Option enthält.

  10. Senden Sie zeitnahe Antworten auf alle Anfragen (idealerweise innerhalb einer Sekunde).

    • Die Verwendung von Online-Geo-IP-Lookup-Diensten für ECS-Abfragen funktioniert nicht zuverlässig, da die kumulative Latenz der DNS-Abfrage und des Online-Geo-IP-Dienstes wahrscheinlich nicht innerhalb einer Sekunde liegen wird. Die automatische Erkennung des ECS von Google Public DNS berücksichtigt verzögerte Antworten als Hinweis auf einen schlechten oder unvollständigen ECS-Support und verringert die Wahrscheinlichkeit, dass zukünftige Abfragen mit ECS gesendet werden. Wenn genügend Antworten verzögert werden, werden keine ECS-Abfragen mehr gesendet.

RFC 7871-Referenzen und andere Fußnoten

1 https://tools.ietf.org/html/rfc7871#page-12

FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS in the response MUST match those in the query. Echoing back these values helps to mitigate certain attack vectors, as described in Section 11.

2 https://tools.ietf.org/html/rfc7871#section-7.2.1

An Authoritative Nameserver that implements this protocol and receives an ECS option MUST include an ECS option in its response to indicate that it SHOULD be cached accordingly, regardless of whether the client information was needed to formulate an answer.

3 https://tools.ietf.org/html/rfc7871#section-7.4

It is RECOMMENDED that no specific behavior regarding negative answers be relied upon, but that Authoritative Nameservers should conservatively expect that Intermediate Nameservers will treat all negative answers as /0; therefore, they SHOULD set SCOPE PREFIX-LENGTH accordingly.

4 https://tools.ietf.org/html/rfc7871#section-7.4

The delegations case is a bit easier to tease out. In operational practice, if an authoritative server is using address information to provide customized delegations, it is the resolver that will be using the answer for its next iterative query. Addresses in the Additional section SHOULD therefore ignore ECS data, and the Authoritative Nameserver SHOULD return a zero SCOPE PREFIX-LENGTH on delegations.

5 https://tools.ietf.org/html/rfc7871#page-12

For the specific case of a Canonical Name (CNAME) chain, the Authoritative Nameserver SHOULD only place the initial CNAME record in the Answer section, to have it cached unambiguously and appropriately. Most modern Recursive Resolvers restart the query with the CNAME, so the remainder of the chain is typically ignored anyway.

6 https://unbound.net/pipermail/unbound-users/2015-Mai/003875.html

Die Verwendung der endgültigen Domain in einer CNAME-Kette ist in Unbound harmlos, da sie normalerweise als lokaler Stub oder Weiterleitungs-Resolver bereitgestellt wird, bei dem sich alle Clients im selben Subnetz befinden und dieselbe Antwort erhalten würden.

7 https://tools.ietf.org/html/rfc7871#page-13

Authoritative Nameservers might have situations where one Tailored Response is appropriate for a relatively broad address range, such as an IPv4 /20, except for some exceptions, such as a few /24 ranges within that /20. Because it can't be guaranteed that queries for all longer prefix lengths would arrive before one that would be answered by the shorter prefix length, an Authoritative Nameserver MUST NOT overlap prefixes.

When the Authoritative Nameserver has a longer prefix length Tailored Response within a shorter prefix length Tailored Response, then implementations can either:

  1. Deaggregate the shorter prefix response into multiple longer prefix responses, or

  2. Alert the operator that the order of queries will determine which answers get cached, and either warn and continue or treat this as an error and refuse to load the configuration.

...

When deaggregating to correct the overlap, prefix lengths should be optimized to use the minimum necessary to cover the address space, in order to reduce the overhead that results from having multiple copies of the same answer. As a trivial example, if the Tailored Response for 1.2.0/20 is A but there is one exception of 1.2.3/24 for B, then the Authoritative Nameserver would need to provide Tailored Responses for 1.2.0/23, 1.2.2/24, 1.2.4/22, and 1.2.8/21 all pointing to A, and 1.2.3/24 to B.