DNS flag day 2020-initiativ for at løse problemer med fragmentering og TCP-support

I dag afholder en række store DNS-tjenester og DNS-serverproducenter et fælles arrangement DNS flagdag 2020designet til at fokusere opmærksomheden på beslutningen problemer med IP-fragmentering ved behandling af store DNS-meddelelser. Dette er den anden sådan begivenhed, sidste år "DNS flag day" var fokuseret om korrekt behandling af EDNS-anmodninger.

Deltagere i DNS flag day 2020-initiativet opfordrer til, at anbefalede bufferstørrelser for EDNS fastsættes til 1232 bytes (MTU-størrelse 1280 minus 48 bytes for headere), samt oversætte behandling af anmodninger via TCP er en must-have funktion på servere. I RFC 1035 Kun support til behandling af anmodninger via UDP er markeret som obligatorisk, og TCP er angivet som ønskeligt, men ikke påkrævet for drift. Ny RFC 7766 и RFC 5966 angiv udtrykkeligt TCP som en påkrævet kapacitet for, at DNS kan fungere korrekt. Initiativet foreslår at gennemtvinge overgangen fra at sende anmodninger over UDP til at bruge TCP i tilfælde, hvor den etablerede EDNS-bufferstørrelse er utilstrækkelig.

De foreslåede ændringer vil eliminere forvirring med valg af EDNS-bufferstørrelse og løse problemet med fragmentering af store UDP-meddelelser, hvis behandling ofte fører til pakketab og timeouts på klientsiden. På klientsiden vil EDNS-bufferstørrelsen være konstant, og store svar sendes straks til klienten over TCP. At undgå at sende store meddelelser over UDP vil også løse problemer med store pakker, der slippes på nogle firewalls og tillade blokering angreb til forgiftning af DNS-cachen, baseret på manipulation af fragmenterede UDP-pakker (når det er opdelt i fragmenter, indeholder det andet fragment ikke en header med en identifikator, så den kan forfalskes, for hvilken det kun er nok for kontrolsummen at matche) .

Fra i dag vil deltagende DNS-udbydere, herunder CloudFlare, Quad 9, Cisco (OpenDNS) og Google, vil gradvist ændre sig EDNS bufferstørrelse fra 4096 til 1232 bytes på sine DNS-servere (EDNS-ændringen vil blive spredt over 4-6 uger og vil dække et stigende antal anmodninger over tid). Svar på UDP-anmodninger, der ikke passer ind i den nye grænse, sendes via TCP. DNS-serverleverandører inklusive BIND, Unbound, Knot, NSD og PowerDNS vil frigive opdateringer for at ændre standard EDNS-bufferstørrelsen fra 4096 bytes til 1232 bytes.

I sidste ende kan disse ændringer føre til løsningsproblemer ved adgang til DNS-servere, hvis UDP DNS-svar overstiger 1232 bytes og ikke kan sende et TCP-svar. Et eksperiment udført hos Google viste, at ændring af EDNS-bufferstørrelsen stort set ikke har nogen effekt på fejlraten – med en buffer på 4096 bytes er antallet af trunkerede UDP-anmodninger 0.345 %, og antallet af uopnåelige genforsøg over TCP er 0.115 %. Med en buffer på 1232 bytes er disse tal 0.367 % og 0.116 %. At gøre TCP-understøttelse til en påkrævet DNS-funktion vil forårsage problemer med omkring 0.1 % af DNS-serverne. Det bemærkes, at under moderne forhold, uden TCP, er driften af ​​disse servere allerede ustabil.

Administratorer af autoritative DNS-servere bør sikre, at deres server reagerer via TCP på netværksport 53, og at denne TCP-port ikke er blokeret af en firewall. En velrenommeret DNS-server bør heller ikke sende UDP-svar, der er større end
anmodet EDNS-bufferstørrelse. På selve serveren skal EDNS-bufferstørrelsen indstilles til 1232 bytes. Resolvere har nogenlunde de samme krav - obligatorisk evne til at svare via TCP, obligatorisk support til at sende gentagne anmodninger via TCP ved modtagelse af et trunkeret UDP-svar og indstilling af EDNS-bufferen til 1232 bytes.

Følgende parametre er ansvarlige for indstilling af EDNS-bufferstørrelsen i forskellige DNS-servere: