Wskazówki dotyczące podsieci EDNS klienta

Wstęp

RFC 7871 – podsieć klienta w zapytaniach DNS – określa mechanizm mechanizmów rekurencyjnych, takich jak publiczny serwer DNS Google, do wysyłania częściowych adresów IP klientów do wiarygodnych serwerów nazw DNS. Sieci dystrybucji treści (CDN) i usługi wrażliwe na opóźnienia wykorzystują to, aby zapewnić dokładne odpowiedzi geolokalizacyjne w odpowiedzi na wyszukiwanie nazw z użyciem publicznych resolverów DNS.

Opis RFC zawiera opis funkcji ECS, które muszą zostać potwierdzone przez serwery nazw, ale użytkownicy nie zawsze spełniają te wymagania. Istnieją też problemy z operacją i wdrażaniem ECS, które nie są obsługiwane przez RFC. Mogą one powodować problemy w przypadku resolverów takich jak publiczne serwery DNS, które automatycznie wykrywają obsługę EECS na wiarygodnych serwerach nazw, a także resolverów, które wymagają białej listy ECS, np. OpenDNS.

Te wskazówki mają na celu pomóc wiarygodnym implementatorom i operatorom DNS unikać wielu typowych błędów, które mogą powodować problemy w przypadku ECS.

Ważne: wdrażając ECS dla wiarygodnych serwerów nazw i stref DNS, postępuj zgodnie ze wszystkimi wskazówkami, aby mieć pewność, że Google Public DNS zawsze wysyła dane ECS do serwerów nazw, zwraca prawidłowe odpowiedzi geolokalizacji dla klientów i może rozwiązywać problemy z nazwami w strefach DNS z obsługą ECS. (Niekiedy może to powodować wyświetlanie odpowiedzi SERVFAIL).

Definicje terminów

Do opisywania operacji ECS używamy tych terminów:

• Serwer nazw implementuje (lub obsługuje) ECS, jeśli odpowiada na zapytania ECS z pasującymi opcjami ECS (nawet jeśli opcje ECS zawsze mają globalną długość prefiksu /0).

  Uwaga: odpowiedzi ECS MUSZĄ¹ odpowiadać adresowi ECS rodziny, adresowi i długości prefiksu źródła odpowiednich zapytań. Jeśli tak nie jest, serwer nazw nie poprawnie implementuje ECS, a publiczny DNS Google może nie wysyłać do niego zapytań ECS.

• Strefa jest włączona ECS, jeśli zapytania ECS do serwerów nazw wysyłane z prefiksem źródłowym innym niż zero otrzymują odpowiedzi ECS o zakresie innym niż zero.

Wytyczne dotyczące wiarygodnych serwerów nazw

1. Wszystkie wiarygodne serwery nazw dla strefy z obsługą ECS muszą włączać tę strefę.

   • Nawet jeśli jeden serwer nazw nie wdraża ECS ani włącza go w strefie, szybko staje się źródłem większości danych z pamięci podręcznej. Ponieważ odpowiedzi mają zakres globalny, są używane (do czasu wygaśnięcia TTL) jako odpowiedź na wszystkie zapytania dotyczące tej samej nazwy (niezależnie od podsieci klienta). Odpowiedzi z serwerów, które wdrażają ECS i włączają tę funkcję, są używane tylko w przypadku zapytań od klientów z określonego zakresu, więc prawdopodobieństwo wykorzystania ich przez odpowiedzi z zakresu globalnego jest mniejsze.

2. Autoryzowane serwery nazw wdrażające ECS MUSZĄ² wysyłać odpowiedzi ECS do zapytań ECS w przypadku wszystkich stref obsługiwanych z adresu IP lub nazwy hosta NS, nawet w przypadku stref, które nie są włączone przez ECS.

   • Google Public DNS automatycznie wykrywa obsługę ECS na podstawie adresu IP, a nie nazwy hosta serwera nazw lub strefy DNS, ponieważ liczba adresów jest mniejsza niż liczba nazw hosta serwera nazw i dużo mniejsza niż liczba stref DNS. Jeśli uwierzytelniony serwer nazw nie zawsze wysyła odpowiedzi ECS do zapytań ECS (nawet w strefach, które nie są włączone), ten język może przestać wysyłać zapytania ECS do Google.

3. Wiarygodne serwery nazw, które wdrażają ECS, muszą odpowiadać wszystkie zapytania ECS z odpowiedziami ECS, w tym odpowiedziami negatywnymi i odesłania.

   • Tutaj występują też problemy z automatycznym wykrywaniem obsługi ECS.

   • Negatywne odpowiedzi (NXDOMAIN i NODATA) MUSZĄ³ używać globalnego zakresu /0, by zapewnić lepszą pamięć podręczną i zgodność z RFC 7871.

   • Oprócz NXDOMAIN i NODATA (NOERROR z pustą sekcją odpowiedzi) inne odpowiedzi na błędy dotyczące zapytań ECS (zwłaszcza SERVFAIL i REFUSE) powinny zawierać pasującą opcję ECS z globalnym zakresem /0.

     • Jeśli uwierzytelniony serwer nazw próbuje zrzucić obciążenie z ataku typu DoS, może zwrócić SERVFAIL bez danych ECS. Jeśli to się powtórzy, publiczny publiczny DNS Google przestanie wysyłać zapytania z ECS (co może zmniejszyć liczbę prawidłowych zapytań wysyłanych przez wyszukiwarkę, ale nie będzie miało wpływu na losowe zapytania dotyczące subdomeny). Zmniejszenie liczby prawidłowych żądań podczas ataku typu DoS może poprawić wskaźnik udanych zapytań (ale odpowiedzi mogą być wyświetlane z pamięci podręcznej dla wszystkich klientów).

       Skuteczniejszym sposobem ograniczania obciążenia jest wysyłanie wszystkich odpowiedzi z globalnym zakresem /0, dzięki czemu Google Public DNS będzie nadal wysyłać zapytania ECS. Dzięki temu po zatrzymaniu ataku funkcja Google Public DNS znacznie szybciej zwróci odpowiedzi geolokalizacyjne, ponieważ nie trzeba ponownie wykrywać obsługi ECS po prostu do wysyłania zapytań.

   • Odpowiedzi na odesłania (przekazanie dostępu) muszą też mieć pasujące dane ECS, a powinien⁴ używać zakresu globalnego /0. Pamiętaj, że odpowiedzi na przekazywanie dostępu nigdy nie są przekazywane do klientów, których adresy są wyświetlane w danych ECS, więc wszelkie rekordy geolokalizacji NS, A i AAAA powinny być wybierane przez adres IP klienta resolvera resolver, a nie dane ECS.

4. Wiarygodne serwery nazw, które wdrażają ECS, muszą zawierać pasującą opcję ECS w odpowiedzi na wszystkie typy zapytań otrzymywanych z ECS. Nie wystarcza to do odpowiadania na adresy IPv4 (A) danymi ECS. Odpowiedź na zapytania A, AAAA, PTR, MX lub inne typy zapytań musi mieć pasujące dane ECS lub resolvery mogą pomijać odpowiedzi, co może sfałszować odpowiedź. Google Public DNS może przestać wysyłać zapytania z danymi ECS.

   W szczególności odpowiedzi ECS na zapytania SOA, NS i DS powinny zawsze korzystać z zakresu globalnego /0, aby zapewnić lepszą pamięć podręczną i spójny widok przekazywania dostępu (odpowiedzi geograficzne na zapytania A/AAAA dla nazw hostów serwerów nazw są prawidłowe). Odpowiedzi na każdy typ zapytania (np. TXT, PTR itp.), które nie zmieniają się na podstawie danych ECS, nie powinny używać zakresu równego długości prefiksu źródła. Powinny one używać globalnego zakresu /0, aby zapewnić lepszą pamięć podręczną i zmniejszyć obciążenie zapytania.

5. Wiarygodne serwery nazw zwracające odpowiedzi CNAME z obsługą ECS MUSZĄ⁵ zawierać tylko pierwszy rekord CNAME w łańcuchu, a ostateczny cel łańcucha CNAME powinien mieć włączone ustawienie ECS o tej samej długości prefiksu zakresu. Ze względu na niejednoznaczność w specyfikacji ECS niektóre resolvery rekurencyjne (zwłaszcza Unbound⁶) mogą zwracać odpowiedzi dotyczące zakresu końcowej domeny spoza CNAME (/0, jeśli nie włączono ECS).

6. Dane ECS mogą zawierać adresy IPv6 nawet na serwerach nazw IPv4 (i odwrotnie, ale serwery nazw tylko IPv6 są rzadkie).

   Ważne: najczęstszym powodem, dla którego wiarygodne serwery nazw nie uzyskują danych ECS z publicznego serwera DNS Google, jest brak prawidłowego zakresu protokołu IPv6.

   • Serwery nazw muszą odpowiadać na podstawie prawidłowych danych opcji ECS (zakres /0 jest prawidłowy, ale adres źródłowy i długość prefiksu muszą być takie same).

   • ECS dla strefy można włączyć oddzielnie dla adresów IPv4 i IPv6.

7. Wiarygodne serwery nazw, które zwracają odpowiedzi z obsługą ECS MUSZĄ ⁷ pokrywać się z prefiksami zakresu w odpowiedziach. Na przykład prefiksy pokrywających się zakresów będą wyglądać tak:

   • Zapytanie z prefiksem źródła 198.18.0.0/15: odpowiedź A z prefiksem zakresu 198.0.0.0/8

   • Zapytanie z prefiksem źródła 198.51.100/24: odpowiedź B z prefiksem zakresu 198.51.0.0/16

   Jeśli klient wysyła zapytanie rekurencyjne z obsługą ECS w powyższej kolejności, oba zapytania mogą otrzymać odpowiedź A, bo zakres odpowiedzi A zapisany w pamięci podręcznej zawiera zakres z prefiksem drugiego zapytania. Nawet jeśli zapytania klienta są wykonywane w odwrotnej kolejności i oba zapytania są przekazywane do wiarygodnych serwerów nazw, odpowiedzi na żądanie w pamięci podręcznej mogą wygasnąć w innym czasie. Kolejne zapytania do resolvera rekurencyjnego w pokrywającym się prefiksie 198.51.100/24 mogą otrzymać odpowiedź A lub B.

8. Gdy po raz pierwszy implementujesz obsługę ECS na serwerach nazw, użyj nowych adresów IP dla serwerów nazw, które obsługują te włączone strefy ECS.

   • Gdy wiarygodne serwery nazw, które zaimplementowały ECS, ale zwróciły wyniki z globalnego zakresu, zaczną zwracać odpowiedzi ECS w przypadku włączonej strefy, publiczny serwer DNS zacznie odpowiadać na pytania o geolokalizację do zapytań wraz z wygaśnięciem TTL poprzednich odpowiedzi globalnych.

   • Automatyczne wykrywanie ECS Google publiczne DNS bardzo rzadko próbuje obsługiwać zapytania ECS w przypadku adresu IP (lub nazwy hosta serwera nazw), gdy automatycznie wykryje brak obsługi ECS (limity czasu, zwrócenie FORMERR, BADVERS lub wysłanie odpowiedzi spoza ECS). Nowe implementacje ECS w przypadku tych adresów IP (lub nazw hosta NS) są wykrywane bardzo wolno lub wcale.

9. Upewnij się, że połączenia sieciowe są stabilne i że ograniczenie liczby odpowiedzi jest wystarczająco wysokie, aby serwery nazw nie pomijały zapytań (lub co gorsza, powoduje wystąpienie błędów z brakiem pasującej opcji ECS).

   • W przypadku serwerów nazw implementujących ograniczenie liczby żądań w zapytaniach ECS najlepszą odpowiedzią jest NODATA z ustawionym symbolem obcięcia (TC) zawierającym tylko dopasowaną sekcję pytania i pasującą opcję ECS.

10. Szybko udzielaj odpowiedzi na wszystkie zapytania (najlepiej w ciągu 1 sekundy).

    • Korzystanie z internetowych usług wyszukiwania adresów IP dla zapytań ECS nie będzie działać niezawodne, ponieważ całkowite opóźnienie zapytania DNS i usługi Geo-IP online prawdopodobnie nie przekroczy jednej sekundy. Automatyczne wykrywanie pomocy Google ECS Google publiczne uwzględnia opóźnione odpowiedzi, które wskazuje na słabą lub niekompletną obsługę ECS, i zmniejsza prawdopodobieństwo wysłania przyszłych zapytań do ECS. Jeśli odpowiedź jest opóźniona, przestaje wysyłać zapytania ECS.

RFC 7871 – odniesienia i inne przypisy

¹ 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.

² 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.

³ 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.

⁴ 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.

⁵ 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.

⁶ https://unbound.net/pipermail/unbound-users/2015-maj/003875.html

Zakres ostatniej domeny w łańcuchu rekordu CNAME jest nieszkodliwy, ponieważ jest zwykle wdrażany jako lokalny lokalizator lub narzędzie do przekazywania, gdzie wszystkie klienty są w tej samej podsieci i otrzymują tę samą odpowiedź.

⁷ 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.