Idag kommer ett antal stora DNS-tjänster och DNS-servertillverkare att hålla ett gemensamt event utformad för att fokusera uppmärksamheten på med IP-fragmentering vid behandling av stora DNS-meddelanden. Detta är det andra evenemanget av detta slag, förra året "DNS flaggdag" om korrekt behandling av EDNS-förfrågningar.
Deltagare i DNS flaggdag 2020-initiativet kräver att rekommenderade buffertstorlekar för EDNS ska fixeras till 1232 byte (MTU-storlek 1280 minus 48 byte för rubriker), samt bearbetning av förfrågningar via TCP är en måstefunktion på servrar. I Endast stöd för bearbetning av förfrågningar via UDP är markerat som obligatoriskt, och TCP är listat som önskvärt, men inte nödvändigt för drift. Ny и Ange uttryckligen TCP som en nödvändig förmåga för att DNS ska fungera korrekt. Initiativet föreslår att tvinga fram övergången från att skicka förfrågningar över UDP till att använda TCP i de fall den fastställda EDNS-buffertstorleken är otillräcklig.
De föreslagna ändringarna kommer att eliminera förvirring med val av EDNS-buffertstorlek och lösa problemet med fragmentering av stora UDP-meddelanden, vars bearbetning ofta leder till paketförlust och timeout på klientsidan. På klientsidan kommer EDNS-buffertstorleken att vara konstant och stora svar skickas omedelbart till klienten över TCP. Att undvika att skicka stora meddelanden över UDP kommer också att lösa problem med att stora paket tappas på vissa brandväggar och tillåta blockering för förgiftning av DNS-cachen, baserat på manipulation av fragmenterade UDP-paket (när det delas upp i fragment innehåller det andra fragmentet inte en rubrik med en identifierare, så det kan förfalskas, för vilket det bara räcker för att kontrollsumman ska matcha) .
Från och med idag kommer deltagande DNS-leverantörer inklusive CloudFlare, Quad 9, Cisco (OpenDNS) och Google, EDNS-buffertstorlek från 4096 till 1232 byte på dess DNS-servrar (EDNS-ändringen kommer att spridas över 4-6 veckor och kommer att täcka ett ökande antal förfrågningar över tiden). Svar på UDP-förfrågningar som inte passar in i den nya gränsen kommer att skickas via TCP. DNS-serverleverantörer inklusive BIND, Unbound, Knot, NSD och PowerDNS kommer att släppa uppdateringar för att ändra standardstorleken för EDNS-buffert från 4096 byte till 1232 byte.
I slutändan kan dessa ändringar leda till lösningsproblem vid åtkomst till DNS-servrar vars UDP DNS-svar överstiger 1232 byte och inte kan skicka ett TCP-svar. Ett experiment utfört på Google visade att en ändring av EDNS-buffertstorleken praktiskt taget inte har någon effekt på felfrekvensen - med en buffert på 4096 byte är antalet trunkerade UDP-förfrågningar 0.345 % och antalet oåtkomliga återförsök över TCP är 0.115 %. Med en buffert på 1232 byte är dessa siffror 0.367 % och 0.116 %. Att göra TCP-stöd till en obligatorisk DNS-funktion kommer att orsaka problem med cirka 0.1 % av DNS-servrarna. Det noteras att under moderna förhållanden, utan TCP, är driften av dessa servrar redan instabil.
Administratörer av auktoritativa DNS-servrar bör se till att deras server svarar via TCP på nätverksport 53 och att denna TCP-port inte blockeras av en brandvägg. En ansedd DNS-server ska inte heller skicka UDP-svar som är större än
begärd EDNS-buffertstorlek. På själva servern bör EDNS-buffertstorleken ställas in på 1232 byte. Upplösare har ungefär samma krav - obligatorisk förmåga att svara via TCP, obligatoriskt stöd för att skicka upprepade förfrågningar via TCP vid mottagning av ett trunkerat UDP-svar och inställning av EDNS-bufferten till 1232 byte.
Följande parametrar är ansvariga för att ställa in EDNS-buffertstorleken i olika DNS-servrar:
alternativ {
edns-udp-storlek 1232;
max-udp-storlek 1232;
};
max-udp-nyttolast: 1232
net.bufsize(1232)
udp-truncation-threshold=1232
edns-outgoing-bufsize=1232
udp-truncation-threshold=1232
edns-buffertstorlek: 1232
ipv4-edns-storlek: 1232
ipv6-edns-storlek: 1232
Källa: opennet.ru