DNS flag day-initiativet 2020 för att lösa problem med fragmentering och stöd för TCP

Idag kommer flera stora DNS-tjänster och tillverkare av DNS-servrar att genomföra ett gemensamt evenemang DNS flag day 2020, som syftar till att fokusera uppmärksamheten på lösningen av problem med IP-fragmentering vid hantering av stora DNS-meddelanden. Detta är det andra liknande evenemanget, förra året var "DNS flag day" inriktad på korrekt hantering av EDNS-förfrågningar.

Deltagarna i DNS flag day-initiativet 2020 uppmanar att fastställa de rekommenderade bufferstorlekarna för EDNS till nivåer på 1232 byte (MTU-storlek på 1280 minus 48 byte för rubriker), och att översätta hanteringen av förfrågningar över TCP till en obligatorisk funktion på servrar. I RFC 1035 är endast stöd för hantering av förfrågningar via UDP obligatoriskt, och TCP anges som önskvärt men icke obligatoriskt för driften. Nya RFC 7766 och RFC 5966 omfattar tydligt TCP som en av de obligatoriska funktionerna som krävs för korrekt DNS-funktion. Inom ramen för det genomförda initiativet föreslås att övergången från att skicka förfrågningar via UDP till att använda TCP tvingas i de fall där den angivna bufferstorleken för EDNS är otillräcklig.

De föreslagna förändringarna kommer att eliminera förvirringen med att välja bufferstorleken för EDNS och lösa problemet med fragmentering av stora UDP-meddelanden, vars hantering ofta leder till paketförlust och tidsgränser på klientsidan. På klientsidan kommer bufferstorleken för EDNS att vara konstant, och stora svar kommer att skickas till klienten via TCP omedelbart. Undantaget för att skicka stora meddelanden via UDP kommer också att lösa problem med avvisning av stora paket på vissa brandväggar och möjliggöra blockering av attacker mot DNS-cacheförgiftning som är baserade på manipulation av fragmenterade UDP-paket (vid fragmentering, inkluderas inte rubriken med identifierare i det andra fragmentet, vilket gör att det kan förfalskas så länge kontrollsumman stämmer).

Från och med idag kommer de DNS-leverantörer som deltar i initiativet, inklusive CloudFlare, Quad 9, Cisco (OpenDNS) och Google, gradvis att förändras storleken på EDNS-bufferten ändras från 4096 till 1232 byte på sina DNS-servrar (ändringen av EDNS kommer att sträcka sig över 4-6 veckor och gradvis omfatta fler och fler förfrågningar). Svar på UDP-förfrågningar som inte passar inom den nya begränsningen kommer att skickas via TCP. Tillverkare av DNS-servrar, inklusive BIND, Unbound, Knot, NSD och PowerDNS kommer att släppa uppdateringar som ändrar den standard EDNS-buffertstorleken från 4096 till 1232 byte.

I slutändan kan de införda ändringarna leda till problem med upplösning när man kontaktar DNS-servrar vars DNS-svar över UDP överstiger 1232 byte och som inte kan skicka svar via TCP. En experiment som utfördes av Google visade att ändringen av EDNS-buffertstorleken praktiskt taget inte påverkar felprocenten — vid en buffert på 4096 byte är andelen avkortade UDP-förfrågningar 0.345 %, medan antalet ouppnåeliga svar via TCP är 0.115 %. Vid en buffert på 1232 byte är dessa siffror 0.367 % och 0.116 %. Övergången till obligatorisk stöd för TCP i DNS-funktioner kommer att orsaka problem vid interaktion med cirka 0.1 % av DNS-servrarna. Det noteras att under moderna förhållanden, utan TCP, redan i sig gör dessa servrars funktion instabil.

Administratörer av auktoritativa DNS-servrar bör säkerställa att deras server svarar via TCP på nätverksport 53 och att denna TCP-port inte blockeras av en brandvägg. En auktoritativ DNS-server ska heller inte skicka UDP-svar vars storlek överskrider
den begärda EDNS-buffertstorleken. På servern själv bör EDNS-buffertstorleken ställas in på 1232 byte. Resolverare ställs inför ungefär samma krav — obligatoriskt möjligheten att svara via TCP, obligatorisk stöd för att skicka omförfrågningar via TCP vid mottagande av avkortat UDP-svar och inställning av EDNS-bufferten till 1232 byte.

Följande parametrar ansvarar för inställningen av EDNS-buffertstorleken på olika DNS-servrar: