Attaque DDoS et Ce qu'il y a dans un (C)Name ?

Source

Attaque DDoS de ce weekend et ce qu’il y a dans un (C)Name ?

Votre configuration DNS peut avoir un grand effet sur les performances et la résilience DDoS.

Tôt dans la matinée de samedi, nous avons été alertés par Rackspace qu'une attaque principale de DDoS frappait notre équilibreur principal de charge dans leur centre de données de Chicago.

L'attaque DDoS était une attaque volumétrique massive basée principalement sur UDP envoyant plus de 40GB/s de trafic soutenu et écrasant le commutateur réseau devant l'équilibreur.

Heureusement, la grande majorité des sites Netlify ont continué à fonctionner sans interruption de service car notre système a détecté automatiquement l'attaque et a commencé à acheminer le trafic loin du centre de données de Rackspace à Chicago.

Cependant, un petit nombre de sites ont été affectés et en baisse par rapport à ce chiffre. Ils différaient du reste par la façon dont leur DNS était configuré et il s'agissait principalement de sites qui utilisaient le domaine racine comme leur domaine canonique, plutôt que de préfixer leur site avec www.

Dès que nous avons détecté le problème, nous avons essayé d'identifier tous les sites affectés par l'attaque DDoS et envoyé des instructions sur la manière d'atténuer ça en modifiant un enregistrement DNS et en dirigeant vers les documents Netlify qui recommandent une configuration C-Name car cela empêche les serveurs de tomber face à ce type d'attaque.

WWW ou pas de WWW

Notre site pour Netlify est hébergé sur www.netlify.com, plutôt que netlify.com

Nous appelons netlify.com le domaineapex ou le domaine root (racine).

Certains pensent que ce n'est qu'une différence cosmétique et produisent des sites Web entiers pour argumenter contre le préfixe www. Toutefois, la suppression de www de votre domaine principal du site peut avoir des conséquences désastreuses en raison de la façon dont les enregistrements DNS fonctionnent.

Enregistrements DNS

DNS est le répertoire téléphonique Internet qui indique aux navigateurs (et tout autre système connecté) comment relier un nom de domaine spécifique à une adresse IP d'un serveur sur lesquels ils peuvent ouvrir une connexion.

Pour les sites Web, il existe aujourd'hui trois types d'enregistrements pertinents :

  • Enregistrement A
    Un enregistrement A renvoie une adresse IPv4 d'un serveur
  • Enregistrement AAAA
    Identique à un enregistrement A, mais renvoie une adresse IPv6
  • Enregistrement CNAME
    Renvoie un autre nom de domaine que le navigateur doit rechercher

Lorsque vous configurez un domaine personnalisé pour qu'il pointe vers un site Netlify, nous vous recommandons toujours d'utiliser un enregistrement CNAME pointant sur <votresite>.netlify.com (où <votresite> dépend du nom de votre site Netlify).

Disons que vous avez configuré www.exemple.com pour renvoyer un CNAME pointant versexemple.netlify.com.

Lorsqu'un utilisateur visite votre site, son navigateur recherche l'enregistrement DNS de www.exemple.com, il reçoit un CNAME lui demandant de chercher exemple.netlify.com. Lorsqu'il consulte exemple.netlify.com, il se connecte à notre directeur de trafic, qui renvoie un enregistrement A avec une adresse IP de serveur provenant de notre pool de noeuds CDN actuellement disponibles qui est géographiquement celui le plus proche de l'utilisateur final.

Le truc nouveau à ce sujet est que si notre système détecte que notre équilibreur de charge principal est frappé par une attaque DDoS de grande ampleur et reste lent ou insensible, nous allons tout simplement dérouter cela sur le niveau DNS. Puisque nous mettons en cache le contenu de nos nœuds périphériques dans le monde entier, les utilisateurs finaux expérimentent grâce à cela des temps de chargement de pages extrêmement rapides.

Le problème avec les domaines Apex

Tout ça c'est génial, mais disons que vous avez acheté le no-www Kool-Aid et que vous voulez que votre site vive directement sur exemple.com.

Vous pourriez penser configurer simplement un enregistrement CNAME pour le domaine apex et que ça soit fait avec ça (certains de nos concurrents recommandent cela naïvement). Cela pourrait cependant casser gravement les choses pour vous.

Le problème avec les enregistrements CNAME est que la spécification DNS ne permet pas d'autres enregistrements DNS sur un nom qui a déjà un enregistrement CNAME.

Lorsque vous avez un nom spécifique pour votre site Web comme www ouapp ou tout autre sous-domaine, ce n'est pas un problème. Néanmoins, ceci est différent pour le domaine apex (racine).

Si vous souhaitez recevoir des courriels sur votre domaine, vous devez définir des enregistrements MX dans le domaine apex. Avec un CNAME, aucun autre enregistrement ne peut être défini.

Vous voulez valider votre domaine pour les outils de webmasters ? Ou pour la validation DNS requise pour certains certificats SSL validés par le domaine ? Désormais, vous devrez rajouter un enregistrement TXT au domaine apex. Si vous avez déjà un CNAME, encore une fois, ce n'est pas autorisé.

Enregistrements A, Interruptions de Service et attaques DDoS

Même si votre site vit sur www.exemple.com au lieu de example.com, vous voudrez quand même un moyen de pointer exemple.com sur nos serveurs afin que nous puissions servir une redirection 301 de exemple.com vers www.exemple.com lorsqu'un utilisateur visite le domaine apex.

Parce que la mise en place d'un enregistrement CNAME sur le domaine apex casse le courrier électronique et provoque des ravages sur les enregistrements TXT, la seule option restante est actuellement un enregistrement A (à l'avenir, les enregistrements AAAA seront aussi une option).

Parce qu'un enregistrement A doit pointer vers une adresse IP brute, nous publions à cette fin l'adresse IP de notre équilibreur de charge principal.

Le problème est qu'un enregistrement A ne nous permet pas d'insérer une direction de trafic entre la recherche DNS de l'utilisateur final et notre infrastructure. Nous n'avons donc aucun moyen d'acheminer les utilisateurs vers le nœud CDN le plus proche, et si, pour une raison quelconque, notre équilibreur de charge principal ne répond pas, nous n'avons aucun moyen de dérouter le trafic provenant directement des enregistrements A.

Pour cette raison, nous recommandons vivement **que vous hébergiez toujours votre site principal ou votre application sur www ou tout autre sous-domaine (app.example.com est tout aussi bien). De cette façon, vous pouvez utiliser un enregistrement CNAME pour l'URL du site canonique. Vous profiterez pleinement de notre infrastructure distribuée à l'échelle mondiale et nous pouvons automatiquement dérouter toute panne localisée.

Le domaine racine sur exemple.com fonctionnera toujours, mais redirigera simplement vers www.exemple.com. Avec Netlify cette redirection se produit directement sur les noeuds de bord CDN et est extrêmement rapide.

Aplatissement du CNAME, ANAME ou Enregistrements ALIAS

Certains hôtes DNS ont prêté attention à la foule du no-www et mis en œuvre une solution de contournement.

DNSimple propose les enregistrements ALIAS, DNS Made Easy supporte les enregistrement ANAME et Cloudflare soutient l'Aplatissement CNAME.

Aucune de ces fournisseurs ne fait partie de la spécification DNS, mais ils trouvent des solutions de contournements pour résoudre les limitations de CNAMEs.

Lorsque vous définissez un ALIAS record pour exemple.com pointant vers exemple.netlify.com, alors DNSimple effectue la recherche CNAME au lieu de la déléguer au navigateur.

Normalement, le navigateur devrait recevoir un enregistrement CNAME, suivre ça vers exemple.netlify.com, pour ensuite recevoir l'adresse IP du serveur disponible le plus proche.

Avec un enregistrement ALIAS, DNSimple vérifie exemple.netlify.com et renvoie un enregistrement A avec une adresse IP directement au navigateur.

Il y a deux avantages :

  1. Vous avez en fait le bénéfice d'un CNAME pour votre domaine apex
    Nous pouvons toujours parcourir les pannes et faire une certaine direction de trafic géographique
  2. Les utilisateurs finaux enregistrent une recherche DNS supplémentaire
    Au lieu de chercher d'abord l'enregistrement CNAME, puis rechercher l'adresse IP finale, le navigateur obtient immédiatement une adresse IP.

Cependant, il y a aussi un inconvénient important:

  1. La précision des recherches géographiques que peut subir Netlify

Nous effectuons maintenant notre recherche basée sur l'IP du serveur DNS plutôt que sur l'IP de l'utilisateur final, et pour des raisons de performance, l'hôte DNS effectuera une mise en cache des recherches IP qui peuvent réduire la précision.

La configuration idéale

La configuration idéale que nous recommandons est d'utiliser www ou tout autre sous-domaine que le domaine canonique pour votre site Web, mais toujours utiliser un hôte DNS qui prend en charge une certaine forme de CNAME sur le domaine apex.

De cette façon, vous avez tout l'avantage de notre direction de trafic DNS globale sur votre site principal, et nous pouvons également parcourir les pannes lors de la redirection du domaine apex vers le domainewww.

J'espère que cela a été instructif !

Rejoignez la conversation sur Hacker News →