chez SFR, les DNS tiers passent
c'est tout ce qui n'est pas DNS qui est bloqué. (de ce que j'ai compris des tests de Vivien)

Oui c'est bien ça.
Mais du coup le protocole DNScrypt doit être bloqué je pense. Il faudra que je teste car je l'utilise sur ma ligne fixe mais pas sur mobile

chez SFR, les DNS tiers passent
c'est tout ce qui n'est pas DNS qui est bloqué. (de ce que j'ai compris des tests de Vivien)

Intéressant cette nuance ! Vu la volumétrie que doit gérer SFR, je doute qu'ils aillent regarder dans le paquet vérifier que ça soit bien un paquet DNS.

Peut-être une limite de taille sur les paquets qui est activée ? Je doute que vos requêtes DNS fassent 1500 octets 

Oui, c'est tout le but du forum, pourvoir discuter de ces choses un peu techniques (et de mon côté d'apprendre des choses). Mais ça fait un moment que je suis tes messages et ton FAI, et je crois pouvoir dire sans me tromper que tu n'es pas un FAI "standard", rien que dans la gestion de ton réseau, dans les investissements fais et dans la satisfaction client qui est affichée sur le forum.

Oui. Moi-même à mes débuts, neutralité du net, on ouvre tout à fond. Mais la réalité du terrain fait que tu es obligé de filtrer/brider, sinon tu as des sollicitations SAV derrière. Mais tu as raison, il faut expliquer, et argumenter sa démarche, et si possible laisser une alternative. Comme le fait de couper les connexions entrantes en IPv6 par exemple, c'est un "mal" nécessaire pour protéger à minima le LAN des particuliers... mais avoir un switch pour désactiver cette protection.

Je serais curieux de connaître la fréquence des DDOS. Comment c'est géré ? Tu reatribu une IP au client et tu bloque l'ancienne ?

Environ 1 attaque par jour.

Il y a 2 parties :
- la détection : chaque routeur qui a des intercos avec l'extérieur (le peering, les transits) renvoie un échantillon de tout le trafic (genre 0.1%) à un serveur qui analyse le nbre de paquets, les flux suspects etc. C'est lui qui détecte et décide s'il y a attaque ou pas. Il me produit un fichier avec tous les flux qu'il a vu pour pouvoir mieux régler mes filtres et servir à des enquêtes judiciaires à postériori.
- le filtrage : là le serveur a une session constante avec les routeurs (comme du peering), et le serveur annonce aux routeurs "hé pour joindre 62.192.xxx.xxx, c'est DTC", et comme les routeurs préfèrent cette "route", ils vont la mettre en top priorité dans la table de routage, et l'abonné est coupé net. L'annonce remonte même en dehors de mon réseau, pour pas que le trafic rentre dans le réseau (donc c'est même bloqué en amont pour garder des ressources sur les intercos pour le reste des abonnés).

Le blocage dure 1min, et aussi longtemps qu'il se fera doucher. Si c'est fini au bout de 2min, il retrouve son accès, l'IP ne change pas.

(je laisse le soin à un modo de scinder si besoin).

Tu peux le voir sur les captures wireshark au début de la discussion, les Packet initiaux wireguard font moins de 200 octets en udp, donc tout petits.
Le filtrage n'est donc pas sur la taille.
Et c'est un peu ça qui m'emmerde, c'est que c'est probablement du DPI que je trouve hautement malhonnête

Ah oui, là c'est chaud par contre 

Ah oui, là c'est chaud par contre 

Je ne suis pas ingénieur réseau, tu pourras peut-être répondre à ma place, mais mis à part du DPI je ne vois pas comment ce trafic peut être filtré.
Si c'est ça, c'est inquiétant parce que ça veut dire que notre trafic est décortiqué et analysé de façon assez précise.
Mais j'ai du mal à imaginer la puissance nécessaire pour analyser un tel volume de trafic que celui de SFR mobile.
Remarquez en Chine ils arrivent bien à faire du DPI sur l'ensemble du trafic chinois

Puisqu'ils sont en train de déployer l'IPv6, peut-être que ça pourrait être une sorte de DNS64 forcé.

Sur la capture de Vivien, on ne voit que la requête A.
Soit aucune requête AAAA n'a été faite (ça dépend du client), soit elle a été envoyée ailleurs.

Que donne une requête AAAA vers un site ipv4-only (ipv4.lafibre.info par exemple) ?

idem dans le TGV avec le Wifi a bord de la SNCF. Testé a l'instant, le port 53 ne sort pas (même en dns).

un test en ligne de commande est possible avec nc (apt install netcat):

nc  -z -v -u 8.8.8.8 53
version Android de netcat: https://play.google.com/store/apps/details?id=com.mtdeer.netpal

SFR n'est pas le seul à faire cela donc. Deja Bytel en faisait aussi.

Le port 53 étant souvent un vecteur d'attaque DDoS c'est surement la raison. Je doute qu'ils DPI quoique ce soit.

En plus de ce que propose hwti, il serait intéressant de voir s'ils modifient aussi les réponses DNS.
par exemple avec:
dig +short thepiratebay.com @8.8.8.8
ainsi que cette commande pour voir quel resolver dns est utilisé :
dig +short TXT whoami.ds.akahelp.net
(pour installer dig: apt install dnsutils)