Iniciativa DNS flag day 2020 pro řešení problémů s fragmentací a podporou TCP

Dnes uspořádá řada velkých DNS služeb a výrobců DNS serverů společnou akci Den vlajky DNS 2020navržený tak, aby se na něj zaměřil rozhodnutí проблем s fragmentací IP při zpracování velkých zpráv DNS. Toto je druhá taková událost, minulý rok „DNS flag day“ byl soustředěný o správném zpracování požadavků EDNS.

Účastníci iniciativy DNS flag day 2020 požadují, aby doporučené velikosti vyrovnávací paměti pro EDNS byly opraveny na 1232 bajtů (velikost MTU 1280 minus 48 bajtů pro hlavičky) překládat zpracování požadavků přes TCP je na serverech nezbytnou funkcí. V RFC 1035 Povinná je označena pouze podpora pro zpracování požadavků přes UDP a TCP je uvedeno jako žádoucí, ale není nutné pro provoz. Nový RFC 7766 и RFC 5966 explicitně uveďte TCP jako požadovanou schopnost pro správné fungování DNS. Iniciativa navrhuje vynutit přechod od zasílání požadavků přes UDP k použití TCP v případech, kdy je zavedená velikost vyrovnávací paměti EDNS nedostatečná.

Navrhované změny odstraní zmatky s volbou velikosti EDNS bufferu a vyřeší problém fragmentace velkých UDP zpráv, jejichž zpracování často vede ke ztrátě paketů a timeoutům na straně klienta. Na straně klienta bude velikost vyrovnávací paměti EDNS konstantní a velké odpovědi budou okamžitě odesílány klientovi přes TCP. Vyhýbání se odesílání velkých zpráv přes UDP také vyřeší problémy s velkými pakety zahazovanými na některých firewallech a umožní blokování útoky o otravě mezipaměti DNS, založené na manipulaci s fragmentovanými UDP pakety (při rozdělení na fragmenty druhý fragment neobsahuje hlavičku s identifikátorem, takže může být zfalšován, k čemuž stačí jen spárovat kontrolní součet).

Ode dneška zúčastnění poskytovatelé DNS včetně CloudFlare, Quad 9, Cisco (OpenDNS) a Google, se bude postupně měnit Velikost vyrovnávací paměti EDNS od 4096 do 1232 bajtů na jejích serverech DNS (změna EDNS bude rozložena do 4–6 týdnů a časem pokryje rostoucí počet požadavků). Odpovědi na požadavky UDP, které se nevejdou do nového limitu, budou odeslány přes TCP. Dodavatelé serverů DNS včetně BIND, Unbound, Knot, NSD a PowerDNS vydají aktualizace, které změní výchozí velikost vyrovnávací paměti EDNS z 4096 bajtů na 1232 bajtů.

V konečném důsledku mohou tyto změny vést k problémům s rozlišením při přístupu k serverům DNS, jejichž odpovědi UDP DNS přesahují 1232 bajtů a nemohou odeslat odpověď TCP. Experiment provedený ve společnosti Google ukázal, že změna velikosti vyrovnávací paměti EDNS nemá prakticky žádný vliv na míru selhání – s vyrovnávací pamětí 4096 bajtů je počet zkrácených požadavků UDP 0.345 % a počet nedosažitelných opakování přes TCP je 0.115 %. S vyrovnávací pamětí 1232 bajtů jsou tato čísla 0.367 % a 0.116 %. Nastavení podpory TCP jako vyžadované funkce DNS způsobí problémy asi u 0.1 % serverů DNS. Je třeba poznamenat, že v moderních podmínkách bez TCP je provoz těchto serverů již nestabilní.

Správci autoritativních serverů DNS by se měli ujistit, že jejich server odpovídá přes TCP na síťovém portu 53 a že tento port TCP není blokován bránou firewall. Renomovaný server DNS by také neměl odesílat odpovědi UDP, které jsou větší než
požadovaná velikost vyrovnávací paměti EDNS. Na samotném serveru by měla být velikost vyrovnávací paměti EDNS nastavena na 1232 bajtů. Resolvery mají přibližně stejné požadavky – povinnou schopnost odpovídat přes TCP, povinnou podporu pro odesílání opakovaných požadavků přes TCP při příjmu zkrácené UDP odpovědi a nastavení EDNS bufferu na 1232 bajtů.

Následující parametry jsou zodpovědné za nastavení velikosti vyrovnávací paměti EDNS na různých serverech DNS:

  • SVÁZAT

    možnosti {
    edns-udp-size 1232;
    max-udp-size 1232;
    };

  • Uzel DNS

    max-udp-payload: 1232

  • Knot Resolver

    net.bufsize(1232)

  • PowerDNS autoritativní

    udp-truncation-threshold=1232

  • Rekurzor PowerDNS

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

  • nevázaný

    edns-buffer-size: 1232

  • NSD

    ipv4-edns-velikost: 1232
    ipv6-edns-velikost: 1232

    Zdroj: opennet.ru

  • Přidat komentář