{"id":36194,"date":"2019-10-31T22:10:13","date_gmt":"2019-10-31T19:10:13","guid":{"rendered":"https:\/\/prohoster.info\/blog\/reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020\/"},"modified":"2019-10-31T22:10:13","modified_gmt":"2019-10-31T19:10:13","slug":"reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/news\/reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020","title":{"rendered":"Wydanie PowerDNS Recursor 4.2 i inicjatywa DNS flag day 2020","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Po p\u00f3\u0142tora roku prac rozwojowych zaprezentowano<\/a><\/noindex> premiera serwera DNS z pami\u0119ci\u0105 podr\u0119czn\u0105 PowerDNS Recursor 4.2<\/a><\/noindex>, odpowiedzialnego za rekurencyjne przekszta\u0142canie nazw. PowerDNS Recursor zbudowany jest na tej samej bazie kodowej co PowerDNS Authoritative Server, ale serwery DNS rekurencyjne i autorytatywne PowerDNS rozwijane s\u0105 w ramach r\u00f3\u017cnych cykli rozwoju i wydawane w formie oddzielnych produkt\u00f3w. Kod projektu rozpowszechniany<\/a><\/noindex> na licencji GPLv2. <\/p>\n

W nowej wersji usuni\u0119to wszystkie uwagi zwi\u0105zane z obs\u0142ug\u0105 pakiet\u00f3w DNS z flagami EDNS. W starych wersjach PowerDNS Recursor do 2016 roku ignorowano pakiety z nieobs\u0142ugiwanymi flagami EDNS, nie wysy\u0142aj\u0105c odpowiedzi w starym formacie, odrzucaj\u0105c flagi EDNS, jak wymaga specyfikacja. Wcze\u015bniej takie niestandardowe zachowanie by\u0142o wspierane w BIND w formie obej\u015bcia, ale w ramach przeprowadzonej<\/a><\/noindex> w lutym inicjatywy DNS flag day<\/a><\/noindex>, deweloperzy serwer\u00f3w DNS podj\u0119li decyzj\u0119 o zaprzestaniu korzystania z tego obej\u015bcia. <\/p>\n

W PowerDNS g\u0142\u00f3wne problemy z obs\u0142ug\u0105 pakiet\u00f3w EDNS zosta\u0142y rozwi\u0105zane ju\u017c w 2017 roku w wersji 4.1, a w wydanym w 2016 roku wydaniu 4.0 wyst\u0119powa\u0142y pojedyncze niezgodno\u015bci, pojawiaj\u0105ce si\u0119 przy okre\u015blonych okoliczno\u015bciach, kt\u00f3re generalnie nie mia\u0142y wp\u0142ywu na normalne dzia\u0142anie. W PowerDNS Recursor 4.2, podobnie jak w BIND 9.14<\/a><\/noindex>, usuni\u0119to obej\u015bcia wspieraj\u0105ce autorytatywne serwery, kt\u00f3re nieprawid\u0142owo odpowiada\u0142y na zapytania z flagami EDNS. Do tej pory, je\u015bli po wys\u0142aniu zapytania z flagami EDNS przez okre\u015blony czas nie otrzymano odpowiedzi, serwer DNS uwa\u017ca\u0142, \u017ce rozszerzone flagi nie s\u0105 wspierane i wysy\u0142a\u0142 ponowne zapytanie bez flag\u00f3w EDNS. Od teraz takie zachowanie zosta\u0142o wy\u0142\u0105czone, poniewa\u017c obecno\u015b\u0107 tego typu kodu prowadzi\u0142a do zwi\u0119kszenia op\u00f3\u017anie\u0144 z powodu ponownego wysy\u0142ania pakiet\u00f3w, zwi\u0119kszenia obci\u0105\u017cenia sieci i niejednoznaczno\u015bci w przypadku braku odpowiedzi z powodu awarii sieci, a tak\u017ce utrudnia\u0142a wdra\u017canie funkcji opartych na EDNS, takich jak stosowanie ciasteczek DNS w celu ochrony przed atakami DDoS. <\/p>\n

W nast\u0119pnym roku postanowiono zorganizowa\u0107 wydarzenie Dzie\u0144 flagi DNS 2020<\/a><\/noindex>, maj\u0105ce na celu zwr\u00f3cenie uwagi na rozwi\u0105zanie<\/a><\/noindex> problemach<\/a><\/noindex> z fragmentacj\u0105 IP przy obs\u0142udze wiadomo\u015bci DNS o du\u017cych rozmiarach. W ramach inicjatywy jest planowany<\/a><\/noindex> zarekomendowa\u0107 rozmiary bufor\u00f3w dla EDNS na poziomie do 1200 bajt\u00f3w, a tak\u017ce do wprowadzenia<\/a><\/noindex> obs\u0142ug\u0119 zapyta\u0144 przez TCP w kategorii obowi\u0105zkowo wspieranych na serwerach. Obecnie wymagana jest obs\u0142uga zapyta\u0144 przez UDP, a TCP jest po\u017c\u0105dane, ale nieobowi\u0105zkowe do dzia\u0142ania (standard przewiduje mo\u017cliwo\u015b\u0107 wy\u0142\u0105czenia TCP). Proponuje si\u0119 usuni\u0119cie z standardu opcji wy\u0142\u0105czenia TCP i ujednolicenie przej\u015bcia od wysy\u0142ania zapyta\u0144 przez UDP do stosowania TCP w przypadkach, gdy ustalony rozmiar bufora EDNS jest niewystarczaj\u0105cy.<\/p>\n

Proponowane w ramach inicjatywy zmiany rozwi\u0105\u017c\u0105 problemy z wyborem rozmiaru bufora EDNS oraz rozwi\u0105\u017c\u0105 kwesti\u0119 fragmentacji du\u017cych komunikat\u00f3w UDP, kt\u00f3rej przetwarzanie cz\u0119sto prowadzi do utraty pakiet\u00f3w i przekrocze\u0144 czasu na stronie klienta. Po stronie klienta rozmiar bufora EDNS b\u0119dzie sta\u0142y, a du\u017ce odpowiedzi b\u0119d\u0105 od razu wysy\u0142ane do klienta przez TCP. Wykluczenie wysy\u0142ania du\u017cych komunikat\u00f3w przez UDP pozwoli r\u00f3wnie\u017c na blokowanie atak<\/a><\/noindex> atak\u00f3w na pami\u0119\u0107 podr\u0119czn\u0105 DNS opartych na manipulacji fragmentowanymi pakietami UDP (przy podziale na fragmenty, drugi fragment nie zawiera nag\u0142\u00f3wka z identyfikatorem, dlatego mo\u017ce by\u0107 fa\u0142szowany, co wystarczy, aby pasowa\u0142a suma kontrolna).<\/p>\n

W PowerDNS Recursor 4.2 uwzgl\u0119dniono problemy z du\u017cymi pakietami UDP i dokonano przej\u015bcia na wykorzystanie rozmiaru bufora EDNS (edns-outgoing-bufsize) w 1232 bajty, zamiast wcze\u015bniej stosowanego limitu 1680 bajt\u00f3w, co powinno znacz\u0105co zmniejszy\u0107 prawdopodobie\u0144stwo utraty pakiet\u00f3w UDP. Warto\u015b\u0107 1232 zosta\u0142a wybrana, poniewa\u017c jest to maksimum, przy kt\u00f3rym rozmiar odpowiedzi DNS z uwzgl\u0119dnieniem IPv6 mie\u015bci si\u0119 w minimalnej warto\u015bci MTU (1280). Do 1232 r\u00f3wnie\u017c zmniejszono warto\u015b\u0107 parametru truncation-threshold, odpowiedzialnego za obcinanie odpowiedzi dla klienta.<\/p>\n

Inne zmiany w PowerDNS Recursor 4.2:<\/p>\n