Wskazówki dotyczące podsieci EDNS klienta

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

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