Linee guida per le subnet client EDNS (ECS)

Introduzione

RFC 7871 (Client Subnet in Query DNS): definisce un meccanismo per i resolver ricorrenti come Google Public DNS per inviare informazioni parziali di indirizzi IP client ai server dei nomi DNS autorevoli. i servizi CDN (Content Delivery Network) e i servizi sensibili alla latenza utilizzano queste informazioni per fornire risposte accurate geolocalizzate quando rispondono alle ricerche di nomi effettuate tramite resolver DNS pubblici.

La RFC descrive le funzionalità ECS che i server dei nomi autorevoli devono implementare, ma gli sviluppatori non seguono sempre questi requisiti. Esistono anche problemi operativi e di deployment ECS che RFC non risolve che possono causare problemi per resolver come Google Public DNS che rilevano automaticamente il supporto ECS in server dei nomi autorevoli, nonché resolver che richiedono l'autorizzazione ECS, come OpenDNS.

Lo scopo di queste linee guida è aiutare gli implementatori e gli operatori DNS autoritativi a evitare molti errori comuni che possono causare problemi a ECS.

Definizioni dei Termini

Per descrivere le operazioni ECS utilizziamo i seguenti termini:

  • Un server dei nomi implementa (o supporta) ECS se risponde alle query ECS con risposte ECS che hanno opzioni ECS corrispondenti (anche se le opzioni ECS hanno sempre una lunghezza del prefisso dell'ambito globale /0).

  • Una zona è attivata da ECS se le query ECS ai suoi server dei nomi inviate con un prefisso di origine diverso da zero ricevono risposte ECS con un ambito diverso da zero.

Linee guida per i server dei nomi autoritativi

  1. Tutti i server dei nomi autorevoli per una zona abilitata per ECS devono attivare ECS per la zona.

    • Anche se un solo server dei nomi non implementa ECS o l'abilita per la zona, diventa rapidamente l'origine della maggior parte dei dati memorizzati nella cache. Poiché le sue risposte hanno ambito globale vengono utilizzate (fino alla scadenza del TTL) come risposta a tutte le query per lo stesso nome (indipendentemente dalla subnet client). Le risposte dei server che implementano ECS e le attivano vengono utilizzate solo per le query dai client nell'ambito specifico, quindi è molto meno probabile che vengano utilizzate rispetto alle risposte dell'ambito globale.

  2. I server dei nomi autoritativi che implementano ECS DEVONO2 inviare risposte ECS alle query ECS per tutte le zone gestite da un indirizzo IP o nome host NS, anche per le zone non CS abilitate per ECS.

    • Google Public DNS rileva automaticamente il supporto ECS in base all'indirizzo IP anziché al nome host del server dei nomi o alla zona DNS perché il numero di indirizzi è inferiore al numero di nomi host del server dei nomi e molto inferiore al numero di zone DNS. Se un server dei nomi autorevole non invia sempre le risposte ECS alle query ECS (anche per le zone non abilitate per ECS), Google Public DNS potrebbe interrompere l'invio di query ECS.

  3. I server dei nomi autoritativi che implementano ECS devono rispondere a tutte le query ECS con risposte ECS, incluse quelle con risposta negativa e di referral.

    • Anche in questo caso si applicano gli stessi problemi relativi al rilevamento automatico del supporto ECS.

    • Le risposte negative (NXDOMAIN e NODATA) DOVREBBE3 utilizzano l'ambito globale /0 per migliorare la memorizzazione nella cache e la compatibilità con RFC 7871.

    • Oltre a NXDOMAIN e NODATA (NOERROR con sezione di risposta vuota), le altre risposte di errore alle query ECS (in particolare SERVFAIL e REFUSE) devono includere un'opzione ECS corrispondente con ambito /0 globale.

      • Se un server dei nomi autorevole sta tentando di eliminare il carico da un attacco DoS, può restituire un SERVFAIL senza dati ECS; in questo modo ripetutamente le istanze DNS pubbliche di Google non inviano più query con ECS (il che potrebbe ridurre il numero di query legittime inviate, ma non le query di attacco dei sottodomini casuali). La riduzione del carico di query legittime durante un attacco DoS può o meno migliorare la percentuale di successo delle query legittime (anche se le risposte possono essere pubblicate dalla cache per tutti i client).

        Un approccio più efficace per la perdita di carico consiste nell'inviare tutte le risposte con ambito /0 globale in modo che Google Public DNS continui a inviare query ECS. Questo consente a Google Public DNS di restituire le risposte con geolocalizzazione molto immediatamente dopo l'arresto dell'attacco, in quanto non ha bisogno di rilevare di nuovo il supporto ECS, ma semplicemente per eseguire nuovamente la query una volta scaduti i TTL a livello globale dell'ambito.

    • Le risposte dei referral (delega) devono anche avere dati ECS corrispondenti e DOVREBBE4 utilizzare un ambito /0 globale. Tieni presente che le risposte di delega non vengono mai inoltrate ai client i cui indirizzi sono visualizzati nei dati ECS; pertanto, i record NS, A o AAAA geolocalizzati devono essere selezionati dall'indirizzo IP del client resolver, non dai dati ECS.

  4. I server dei nomi autorevoli che implementano ECS devono includere un'opzione ECS corrispondente nelle risposte a tutti i tipi di query ricevuti con un'opzione ECS. Non c'è abbastanza tempo per rispondere a query dell'indirizzo IPv4 (A) con dati ECS; le risposte ad A, AAAA, PTR, MX o qualsiasi altro tipo di query devono avere dati ECS corrispondenti oppure i resolver potrebbero eliminare la risposta come una possibile risposta contraffatta e Google Public DNS potrebbe interrompere l'invio di query con dati ECS.

    In particolare, le risposte ECS alle query SOA, NS e DS devono sempre utilizzare l'ambito globale /0 per una migliore memorizzazione nella cache e una visualizzazione coerente della delega (le risposte geolocalizzate alle query A/AAAA per i nomi host dei server dei nomi sono valide). Le risposte a qualsiasi tipo di query (ad esempio TXT, PTR ecc.) che non cambiano in base ai dati ECS non devono utilizzare un ambito uguale alla lunghezza del prefisso di origine, ma devono utilizzare un ambito /0 globale per migliorare la memorizzazione nella cache e ridurre il carico delle query.

  5. I server dei nomi autorevoli che restituiscono risposte CNAME abilitate per ECS SHOULD5 includono solo il primo CNAME nella catena e il target finale della catena CNAME deve essere abilitato per ECS alla stessa lunghezza del prefisso dell'ambito. A causa dell'ambiguità nella specifica ECS, alcuni resolver ricorrenti (in particolare Non associato6) possono restituire una risposta con l'ambito del dominio finale non CNAME (/0 se non è abilitato ECS).

  6. I dati ECS possono contenere indirizzi IPv6 anche per i server dei nomi solo IPv4 (e viceversa), sebbene i server dei nomi solo IPv6 siano rari).

    • I server dei nomi devono rispondere con dati dell'opzione ECS validi (l'ambito /0 è consentito, ma la lunghezza dell'indirizzo di origine e del prefisso deve corrispondere).

    • La funzionalità ECS di una zona può essere attivata separatamente per gli indirizzi IPv4 e IPv6.

  7. I server dei nomi autoritativi che restituiscono risposte abilitate per ECS NON DEVONO7 sovrapporre i prefissi dell'ambito nelle loro risposte. Ecco un esempio di prefissi dell'ambito sovrapposti:

    • Query con prefisso di origine 198.18.0.0/15: risposta A con prefisso di ambito 198.0.0.0/8

    • Query con prefisso di origine 198.51.100/24: risposta B con prefisso dell'ambito 198.51.0.0/16

    Se un client esegue una query su un resolver ricorrente abilitato per ECS nell'ordine sopra riportato, entrambe le query potrebbero ricevere la risposta A, perché l'ambito della risposta A memorizzata nella cache include l'ambito del prefisso della seconda query. Anche se le query client vengono eseguite nell'ordine opposto ed entrambe le query vengono inoltrate a server dei nomi autorevoli, le risposte memorizzate nella cache possono scadere in momenti diversi; le query successive al resolver ricorrente nel prefisso sovrapposto 198.51.100/24 potrebbero ottenere la risposta A o B.

  8. Quando implementi il supporto ECS per la prima volta sui server dei nomi, utilizza nuovi indirizzi IP per i server dei nomi che servono queste zone abilitate di ECS.

    • Quando i server dei nomi autorevoli che hanno implementato ECS ma hanno restituito risultati di ambito globali iniziano a restituire risposte abilitate di ECS per una zona, Google Public DNS inizia a restituire risposte geolocalizzate alle query non appena i TTL delle precedenti risposte di ambito globali scadono.

    • Il rilevamento automatico di Google Public DNS del supporto ECS tenta molto raramente di eseguire query ECS per un indirizzo IP (o il nome host del server dei nomi) quando rileva automaticamente la mancanza di supporto ECS (timeout, restituzione di FORMERR, BADVERS o invio di risposte non ECS). Le nuove implementazioni ECS su questi indirizzi IP (o nomi host NS) vengono rilevate automaticamente molto lentamente o non vengono rilevate affatto.

  9. Assicurati che le connessioni di rete siano affidabili e che qualsiasi limitazione della frequenza di risposta sia impostata su un valore sufficientemente elevato da evitare che i server dei nomi trasmettano le query (o, peggio, rispondere con errori privi di un'opzione ECS corrispondente).

    • Per i server dei nomi che implementano la limitazione della frequenza di risposta nelle query ECS, la risposta migliore è NODATA con il flag di troncamento (TC) impostato, contenente solo una sezione di domanda corrispondente e un'opzione ECS corrispondente.

  10. Invia risposte tempestive a tutte le query (preferibilmente entro 1 secondo).

    • L'utilizzo dei servizi di ricerca Geo-IP online per le query ECS non funzionerà in modo affidabile, poiché è improbabile che la latenza cumulativa della query DNS e del servizio Geo-IP online non superi un secondo. Il rilevamento automatico di Google Public DNS dell'assistenza ECS considera le risposte ritardate come un'indicazione dell'assistenza ECS scadente o incompleta e riduce la probabilità che le query future vengano inviate con ECS. Se le risposte sono in ritardo, l'invio di query ECS viene interrotto.

Riferimenti a RFC 7871 e altre note a piè di pagina

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-maggio/003875.html

L'utilizzo dell'ambito del dominio finale in una catena CNAME è innocuo in Unbound, poiché di solito viene eseguito il deployment come stub locale o resolver di forwarding, in cui tutti i client si trovano nella stessa subnet e ricevono la stessa risposta.

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.