Come è possibile per i server dei nomi root gestire tutte le richieste DNS?

18

Alcuni giorni fa stavo leggendo del DNS e ho imparato come vengono elaborate le richieste. Se navighi su www.example.com, una richiesta andrà ai Root Name Server per vedere chi possiede quell'indirizzo .com, quindi un'altra richiesta andrà a un altro server DNS più locale per vedere chi possiede l'esempio.com indirizzo e così via.

In che modo è tecnicamente possibile che i 13 server dei nomi root possano gestire simultaneamente tutte le richieste fatte dai miliardi di utenti Internet della Terra senza doverlo fare?

domain-name-system nameserver ddos

— Rox
fonte

11

A proposito, il tuo riepilogo del funzionamento del DNS è errato. La domanda posta al server dei nomi di root non è "chi possiede .com?" ma "qual è l'indirizzo IP di www.example.com?" (il server dei nomi root risponde con un riferimento al proprietario di .com). Il server dei nomi root vede l'intera query (che è utile per statistiche, data mining, ecc.).

— Bortzmeyer,

@bortzmeyer Il motivo principale per cui l'intero nome viene inviato ai server root è che non tutti i punti nel nome sono necessariamente un limite di autorità. In pratica, credo che ci sia sempre un limite di autorità appena al di sotto del TLD, ma in linea di principio non è garantito. Quindi ad un certo punto in futuro si potrebbe decidere di introdurre un TLD speciale in cui il secondo livello è gestito dai server di root in modo tale che quando si interrogano i server di root per a.b.c.examplete verrà detto di chi è responsabile c.exampleanziché di chi è responsabile example.

— Kasperd,

51

Sono 13 cluster altamente disponibili di server, non semplicemente 13 server.

Tra le altre cose, agli operatori dei nameserver di root è richiesta una capacità sufficiente per gestire il triplo del normale carico di traffico ( RFC 2870 ). Questo porta a cluster piuttosto grandi.

Tuttavia, server dei nomi root servono solo risposte per i domini di primo livello stesse, cioè com., net., uk., ae., ecc, e nameserver che interrogare la radice può cache questa informazione fino a 48 ore , il che riduce drasticamente il carico nel server dei nomi root. Questo porta a cluster più piccoli.

I nameserver di root si trovano in oltre 130 località fisiche in 53 paesi; con solo 13 nomi di server, questo viene fatto attraverso la magia di anycast IPv4.

I nameserver di root hanno anche un proprio sito Web , che potresti trovare interessante da leggere.

— Michael Hampton
fonte

48 h è il TTL dei record NS alla radice. Ma può essere sostituito dai server dei nomi del TLD stesso. Ad esempio, per .jp, sono solo 24 ore.

— Bortzmeyer,

Bene, noi stiamo parlando di server dei nomi root qui. :)

— Michael Hampton

Oggi RFC 2870 è piuttosto obsoleto. A causa degli attacchi dDoS, un server dei nomi di root deve essere pronto a rispondere molto più del triplo del suo normale traffico.

— Bortzmeyer,

8

53 paesi? è una coincidenza o l'hanno scelta proprio come la porta di query DNS ?? : D

— amyassin

10

Non lo fanno. I nameserver di root devono solo dirti cosa gestiscono i nameserver com. Da allora in poi, non è necessario andare da loro per gestire alcun dominio all'interno com. I nameserver di root non hanno idea di chi sia il proprietario example.com. Sono i nameserver di root , non i nameserver di com .

Ciò che ha detto slimsuperhero è anche vero. Molti nameserver ad alto volume usano anycast per avere un unico indirizzo IP servito da un numero di server in tutto il mondo.

— David Schwartz
fonte

Ma se 1 miliardo di utenti navigasse verso indirizzi .com diversi nello stesso secondo, i server dei nomi di root gestiranno tutte le richieste?

— Rox

3

No. Per prima cosa, gli utenti parlano solo con nameserver ricorsivi (quelli che si connettono ad altri nameserver per ottenere risposte) e i nameserver root non sono ricorsivi (servono solo informazioni locali che già conoscono). Gli utenti parlano con i propri server dei nomi (di solito forniti dal proprio ISP) che devono solo chiedere una volta ai server dei nomi radice i server che gestiscono com.

— David Schwartz

1

@DavidSchwartz è corretto, quindi invece di un miliardo di richieste da un miliardo di utenti riceveranno circa un milione di richieste da un milione di ISP, ognuna delle quali serve un migliaio di utenti.

— Shadur

@Shadur: Ora, i nameserver per comd'altra parte devono subire un pestaggio molto più massiccio.

— David Schwartz

1

E sono abbastanza sicuro che siano ridimensionati e raggruppati in modo appropriato.

— Shadur

6

Ogni server root non è in realtà un server, sono enormi cluster di server. Inoltre, le risposte DNS vengono memorizzate nella cache in modo che non tutte le richieste raggiungano il server principale.

— Gevial
fonte

3

Si noti che si non si utilizzano i server principali. Di solito si utilizza il server DNS fornito dal proprio provider di servizi Internet che di solito può rispondere immediatamente se le informazioni necessarie sono nella loro cache locale. Solo se non memorizzato nella cache, viene richiesto il loro server DNS upstream e solo alla fine viene chiesto al server root (e tale risposta viene quindi memorizzata nella cache)

— Thorbjørn Ravn Andersen
fonte

0

In realtà è il suo indirizzo IP 13 Anycast che si risolve in molti server in tutto il mondo. Puoi guardare il link per trovare quei server se necessario. Tutti questi server sono gestiti dall'autorità interessata.

Il fatto che stiamo ancora utilizzando solo 13 indirizzi IP (e un cluster di server con lo stesso indirizzo IP) è quello di garantire che la dimensione del pacchetto non superi i 512 byte. Allora perché? abbiamo TCP che può andare oltre questa dimensione del pacchetto perché non possiamo usarlo ?. Il fatto è che TCP comporta un sovraccarico molto elevato in quanto include più passaggi e procedure per stabilire una connessione TCP. Per questo motivo, l'intero processo di una query DNS sarà lento.

Cose come il DNS non possono mai essere lente ed è per questo che usiamo ancora lo stesso vecchio sistema.

— Jaison
fonte

La risposta a una query .non si adatta più a 512 byte. Poiché IPv6 è ora una necessità, la risposta è cresciuta a 811 byte. Con EDNS che può essere restituito in un'unica risposta. Tuttavia, le query per .non sono necessarie così spesso che un paio di viaggi di andata e ritorno sono uno spettacolo. È principalmente necessario che i recursori apprendano le ultime modifiche agli indirizzi IP delle radici, che raramente cambiano.

— Kasperd,

@kasperd Non ne sono sicuro. Ho controllato dig + trace per un normale record A o AAAA e tutte le risposte (dai server di livello radice, dai server di livello superiore o nei server dei nomi) sono inferiori a 508-509 byte. Puoi spiegarci qualcosa in più.

— Jaison,

È necessario utilizzare EDNS o TCP per ottenere la risposta completa. Le richieste UDP senza EDNS non possono mai ottenere una risposta superiore a 512 byte.

— Kasperd,