A DNS flag day 2020 kezdeményezés a fragmentációs problémák és a TCP támogatás megoldására

Ma számos nagy DNS-szolgáltató és DNS-szerver gyártó közös eseményt tart DNS flag day 2020, amely a figyelmet a megoldásra problémákra az IP-fragmentációval kapcsolatban a nagy méretű DNS-üzenetek feldolgozásakor. Ez a második hasonló esemény, tavaly a 'DNS flag day' a helyes EDNS-kérelmek feldolgozására összpontosított. A DNS flag day 2020 kezdeményezés résztvevői arra kérik, hogy rögzítsék az EDNS-hez ajánlott pufferméreteket 1232 byte-ra (az MTU 1280 minusz 48 byte a fejlécekhez), és

tegyék kötelezővé a TCP-n keresztüli kérelmek feldolgozását a szerverek számára. Az RFC 1035 csak az UDP-kérelmek feldolgozásának támogatását jelöli kötelezőnek, míg a TCP-t kívánatosnak, de nem kötelezőnek tekinti a működéshez. Az új RFC 7766 RFC 5966 és kifejezetten a TCP-t az DNS helyes működéséhez szükséges kötelező funkciók közé sorolják. A kezdeményezés keretein belül azt javasolják, hogy kényszerítsék a UDP-n küldött kérelmekről a TCP használatára való áttérést, ha az EDNS puffermérete nem elegendő. A javasolt változások megszüntetik a zűrzavart az EDNS pufferméretének megválasztásával kapcsolatban, és megoldják a nagy UDP-üzenetek fragmentálásának problémáit, amelyek sok esetben csomagvesztéshez és időtúllépéshez vezetnek az ügyfél oldalán. Az ügyfélnél az EDNS pufferméret állandó lesz, és a nagy válaszok azonnal TCP-n keresztül kerülnek elküldésre az ügyfélnek. A nagy üzenetek UDP-n való küldésének kizárása szintén megoldja a nagy csomagok egyes tűzfalakon történő eldobásával kapcsolatos problémákat, és lehetővé teszi a DNS-gyorsítótár-töltés támadások blokkolását, amelyek fragmentált UDP-csomagok manipulációján alapulnak (a fragmentációnál a második fragmentum nem tartalmazza az azonosítót, így hamisítható, elég, ha a checksum egyezik).

A kezdeményezésben részt vevő DNS-szolgáltatók, beleértve a CloudFlaret, Quad 9-et, a Cisco-t (OpenDNS) és a Google-t, kezdve a mai naptól fokozatosan váltanak U1.1.9.6. A támadók a hitelesítő adatok billentyűzeten való beírását a billentyűk megnyomásának hangjának elemzésével figyelték meg. по отравлению кэша DNS, основанные на манипуляции фрагментированными UDP-пакетами (при разбиении на фрагменты, второй фрагмент не включает заголовок с идентификатором, поэтому может быть подделан для чего достаточно только чтобы совпадала контрольная сумма).

A DNS-kezdeményezés résztvevői mára közös eseményt tartanak, amelyen a Cloudflare, Quad 9, Cisco (OpenDNS) és Google fokozatosan váltanak át Az EDNS pufferméret csökkentése 4096 bájról 1232 bájtra a DNS-kiszolgálóikon (az EDNS módosítása 4-6 hét alatt történik, és idővel egyre több lekérdezést érint). A UDP lekérdezések válasza, amelyek nem felelnek meg az új korlátozásnak, TCP-n keresztül kerülnek elküldésre. A DNS-kiszolgáló gyártók, beleértve a BIND, Unbound, Knot, NSD és PowerDNS-t, frissítéseket bocsátanak ki az EDNS pufferméretének alapértelmezett csökkentéséről 4096 bájról 1232 bájtra.

A végrehajtott változások végső soron problémákat okozhatnak a DNS-kiszolgálókkal való feloldáskor, amelyek UDP-n kapott DNS-válaszai meghaladják a 1232 bájtot, és nem tudják TCP-n keresztül megküldeni a választ. A Google által végzett kísérlet azt mutatta, hogy az EDNS pufferméretének megváltoztatása gyakorlatilag nem befolyásolja a hibaszintet - 4096 bájtos pufferméret mellett az lerövidített UDP lekérdezések aránya 0,345%, míg a TCP-nál elérhetetlen új válaszok aránya 0,115%. 1232 bájtos puffernél ezek az arányok 0,367% és 0,116%. A TCP kötelezővé tétele a DNS képességek között problémákat okoz körülbelül 0,1% DNS-kiszolgálóval való interakciókor. Megjegyezték, hogy a modern körülmények között a TCP nélkül ezeknek a szervereknek az üzemelése amúgy is instabil.

Az authoritative DNS-kiszolgálók adminisztrátorainak biztosítaniuk kell, hogy kiszolgálójuk TCP-n válaszol a 53-as hálózati porton, és hogy ez a TCP-port ne legyen blokkolva az tűzfal által. Az authoritative DNS-kiszolgálónak nem szabad UDP-válaszokat küldenie, amelyek mérete meghaladja
a kért EDNS pufferméretet. Maga a kiszolgáló EDNS pufferméretét 1232 bájtra kell beállítani. A resolvereknek hasonló követelményeknek kell megfelelniük - kötelező a TCP-n keresztüli válaszadás lehetősége, kötelező az UDP-n kapott lerövidített válaszok esetén a TCP-n keresztüli újrakérések küldésének lehetősége, valamint az EDNS pufferméretének 1232 bájtra állítása.

Az EDNS pufferméretének beállításáért a különböző DNS-kiszolgálókon a következő paraméterek felelnek:

  • BIND

    options {
    edns-udp-size 1232;
    max-udp-size 1232;
    };

  • Knot DNS

    max-udp-payload: 1232

  • Knot Resolver

    net.bufsize(1232)

  • PowerDNS Authoritative

    udp-truncation-threshold=1232

  • PowerDNS Recursor

    edns-outgoing-bufsize=1232
    udp-truncation-threshold=1232

  • Unbound

    edns-buffer-size: 1232

  • NSD

    ipv4-edns-size: 1232
    ipv6-edns-size: 1232

    Forrás: opennet.ru

  • Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster