Încerc să găsesc QPS (Interogare pe secundă) maximă a VM-ului DNS Resolver.
Avem infrastructura noastră găzduită pe Azure, având o VM (bazată pe legare) care acționează ca un rezolutor care interogează DNS nativ Azure (168.63.129.16), precum și DNS local. Nu memorez în cache nicio interogare pe resolver și fiecare înregistrare A are un TTL de 300 de secunde.
eu folosesc dnsperf & respect pentru a declanșa sarcina (doar înregistrări A). Acum, că pregătesc soluții DNS pentru a rezista atacurilor DDOS de până la 100K QPS. Mă confrunt cu probleme precum limitarea ratei de interogare între soluția mea și soluția DNS nativă azure. Ca rezultat, atunci când QPS este crescut, rezolutorul revine SERVFAIL răspunsurile înapoi către client. Cu toate acestea, nu am văzut niciunul SERVFAIL răspunsuri între soluție și DNS bazat pe site.
QPS maxim, am putut vedea în timp ce țintesc Azure DNS este în jur de 2100. Am căutat mult online dacă există o astfel de limitare a ratei făcută de Azure, dar nu am găsit nimic legat. Cumva, cred că VM-ul soluționar a lovit un blocaj, deoarece 2K QPS este foarte scăzut pentru scara infrastructurii Azure.
Câteva lucruri (modificări kernel sysctl), le-am schimbat la sfârșitul meu, ceea ce s-a îmbunătățit puțin, dar nu mult.
Modificări Bind Config ::
recursive-clienți din 1000 -> 30000
UDP tamponează la o valoare mai mare decât 26214400 pentru a opri erorile de buffer::
net.core.rmem_maxnet.core.rmem_default
Gama portului local de la 32768 61000 la 1024 61000 a avea maxim
porturi disponibile pentru DNS::
net.ipv4.ip_local_port_range
diverse modificari::
txqueuelen din 1000 -> 20000
ulimite schimbat la 100000
net.netfilter.nf_conntrack_max schimbat la o valoare mult mai mare
Pe lângă cele de mai sus, am mărit dimensiunea VM de la (1 nucleu, 2 GB RAM) -> (4 nuclee, 8 GB RAM).După creștere, erorile de pachete au dispărut (verificat netstat -s) dar nu s-a îmbunătățit SERVFAIL erori.
Am activat tcpdump pentru a verifica tiparul de SERVFAIL erori. În caz de eșecuri, soluția încearcă să trimită interogarea către Azure DNS de 5 ori (fiecare după 1 secundă), dar nu a auzit nimic de la Azure DNS și, prin urmare, trimite SERVFAIL răspuns înapoi către client. După ce a încărcat pcap dosar pe Wireshark, văd că Azure DNS trimite răspunsul înapoi către rezolutor dar rezolutor trimisese deja SERVFAIL răspuns la client.
De ce conexiunea este închisă înainte de a primi răspunsul? Actual net.netfilter.nf_conntrack_udp_timeout este lăsat neatins să 30 secunde dar rezolutor trimite SERVFAIL după 5 secunde către client.
Mai jos sunt tcpdump busteni în timpul ServFail::
citire din fișierul dns4.pcap, tip link EN10MB (Ethernet)
10.0.0.10.57710 > 10.0.0.11.domain: [udp sum ok] 1612+ A? SZxvvdyDYy.ns.westeurope.xx.yy.zz.net. (66)
10.0.0.11.44513 > 168.63.129.16.domain: [bad udp cksum 0xbecd -> 0x8cfd!] 52637+% [1au] A? SZxvvdyDYy.ns.westeurope.xx.yy.zz.net. ar: . OPT UDPsize=4096 DO (77)
10.0.0.11.32378 > 168.63.129.16.domain: [bad udp cksum 0xbecd -> 0x3950!] 20672+% [1au] A? SZxvvdyDYy.ns.westeurope.xx.yy.zz.net. ar: . OPT UDPsize=512 DO (77)
10.0.0.11.59973 > 168.63.129.16.domain: [bad udp cksum 0xbecd -> 0xe2e5!] 15199+% [1au] A? SZxvvdyDYy.ns.westeurope.xx.yy.zz.net. ar: . OPT UDPsize=512 DO (77)
10.0.0.11.29976 > 168.63.129.16.domain: [bad udp cksum 0xbec2 -> 0x051b!] 47104+ A? SZxvvdyDYy.ns.westeurope.xx.yy.zz.net. (66)
10.0.0.11.43442 > 168.63.129.16.domain: [bad udp cksum 0xbec2 -> 0xe791!] 41199+ A? SZxvvdyDYy.ns.westeurope.xx.yy.zz.net. (66)
10.0.0.11.domain > 10.0.0.10.57710: [bad udp cksum 0x2a89 -> 0x5e30!] 1612 ServFail q: A? SZxvvdyDYy.ns.westeurope.xx.yy.zz.net. 0/0/0 (66)
După cum puteți vedea din linia de jos ServFail este trimis după 5 încercări.
Dacă ați ajuns până aici, trebuie să vă mulțumesc pentru că ați citit această întrebare lungă. Știu că este o întrebare prea mare, dar apreciez dacă aveți câteva indicii pentru mine, deoarece nu reușesc să înțeleg care este blocajul.
Postat inițial pe superutilizator Aici
