├── 2019 ├── index-cs.md ├── index-de.md ├── index-es.md ├── index-pt-br.md ├── index-ru.md ├── index-zh-CN.md └── index.md ├── 2020 ├── index-es.md ├── index-fr.md ├── index-ja.md ├── index-zh-CN.md └── index.md ├── CNAME ├── README.md ├── _config.yml ├── _data ├── 2019_checker.yml ├── 2019_supporters.yml ├── 2020_checker.yml └── 2020_supporters.yml ├── _includes ├── 2019_checker.html ├── 2019_languages.html ├── 2019_supporters.html ├── 2020_checker.html ├── 2020_cli_checker.html ├── 2020_languages.html ├── 2020_supporters.html ├── footer.html └── header.html ├── _layouts └── default.html ├── assets └── css │ └── style.scss ├── css └── bootstrap.min.css ├── flags ├── cs.svg ├── de.svg ├── en.svg ├── es.svg ├── fr.svg ├── ja.svg ├── pt-br.svg ├── ru.svg └── zh-CN.svg ├── images ├── AlibabaCloud.png ├── CoreDNS_Colour_Horizontal.png ├── DNS_Flag.svg ├── Infoblox-logo-with-tag.png ├── Twitter_Social_Icon_Rounded_Square_Color.svg ├── bluecat.png ├── cisco.svg ├── cleanbrowsing.png ├── cloudflare.png ├── cznic.svg ├── facebook.svg ├── google.svg ├── home.svg ├── isc.png ├── nlnetlabs.svg ├── powerdns.svg ├── quad9.png ├── space-available.png └── whalebone.png ├── index.md ├── js ├── bootstrap.min.js ├── client-tcp-checker.js ├── domain-checker.js ├── jquery-3.4.1.min.js ├── popper.min.js ├── supporters-randomiser.js └── tcp-checker.js ├── robots.txt └── signs ├── compatible.svg ├── dead.svg ├── high_latency.svg └── ok.svg /2019/index-cs.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 2019 3 | lang: cs 4 | redirect_from: 5 | - /2019/cs/ 6 | flagdayyear: 2019 7 | --- 8 | 9 | {% include 2019_languages.html %} 10 | 11 | **Toto je archivní verze stránky popisující akci skončenou v únoru 2019. Aktuální informace podstatné pro dnešek naleznete na hlavní stránce [dnsflagday.net](https://dnsflagday.net/).** 12 | 13 | Co se připravuje? 14 | ================= 15 | Současný systém [DNS] je z pomalý a potýká se s technickými problémy způsobenými nedodržováním standardů vydaných již před dvaceti lety. 16 | 17 | Aby celosvětové DNS bylo i nadále udržitelné je nezbytné provést změny a ukončit podporu nestandardních implemendací. Tímto krokem dojde ke zlepšení efektivity systému a bude umožněno nasadit novou funkcionalitu jako je např. lepší ochrana před [DDoS] útoky. 18 | 19 | Z výše uvedených důvodů po **1. únoru 2019** [níže uvedení výrobci](#supporters) ukončí podporu nestandardních implementací DNS. Tato změna ovlivní jen domény používající software, který nedodržuje standardy DNS. 20 | 21 | Pro více informací klikněte na skupinu, do které spadáte: 22 | 23 | - [Jsem uživatel Internetu, nemám svou vlastní doménu](#users) 24 | - [Jsem držitel domény](#domain-holders) 25 | - [Jsem správce DNS](#dns-admins) 26 | - [Zajímám se o DNS z odborného hlediska (vývoj DNS softwaru, výzkum, atd.)](#experts) 27 | 28 | 29 | 30 | 31 | Jsem uživatel Internetu 32 | ======================= 33 | Pokud nemáte vlastní doménu, není třeba se strachovat. Vás se změna týká pouze nepřímo a není nutné podnikat žádné další kroky. Děkujeme za váš zájem o [DNS]! 34 | 35 | 36 | 37 | 38 | Jsem držitel domény 39 | =================== 40 | Jste-li držitel domény, zkontrolujte, zda je vaše doména připravena na změny v systému DNS pomocí následujícího formuláře. Výsledek testu vám v případě potřeby zároveň sdělí doporučený postup nápravy. 41 | 42 | {% include 2019_checker.html lang=site.data.2019_checker.cs %} 43 | 44 | Pokud máte více domén hostovaných na stejné sadě serverů, stačí otestovat pouze jednu z nich. Další informace naleznete v části [technické detaily testů](#test-details). 45 | 46 | 47 | 48 | Jsem správce DNS 49 | ================ 50 | Dopady plánované změny na klientskou stranu DNS popisuje následující kapitola [o DNS resolverech](#resolver-ops). Malé procento autoritativních serverů může vyžadovat změny, které jsou [popsány níže](#auth-ops). Pro zájemce o hlubší porozumění uvádíme další [technické detaily testů](#test-details) a [nástroje pro experty](#experts). 51 | 52 | 53 | 54 | Správci DNS resolverů 55 | --------------------- 56 | V krátkém období po 1. únoru 2019 budou vydány nové verze DNS resolverů, které již nebudou obcházet problémy nestandarních implementací. Proto se autoritativní servery, které nedodržují starší standard DNS z roku 1987 ([RFC1035]) ani novější standard [EDNS] z roku 1999 ([RFC2671], [RFC6891]) stanou nedostupnými. Zároveň stejnou změnu nasadí také [poskytovatelé veřejných DNS resolverů, kteří jsou uvedení níže](#supporters), takže tato změna ovlivní uživatele Internetu bez ohledu na rychlost aktualizace software resolverů. 57 | 58 | Důsledkem plánované změny se domény hostované na vadných autoritativních serverech stanou nedostupné. Pokud v období po 1. únoru 2019 budete řešit problémy s nedostupností domén, doporučujeme vám zkontrolovat postiženou domény pomocí [webového formuláře výše](#domain-holders). Pokud test domény opakovaně selhává, potom se nejedná o chybu na straně vašeho resolveru a oprava musí být provedena na straně autoritativního serveru. 59 | 60 | Dále uvádíme verze DNS resolverů, které již nebudou obcházet problémy nestandarních implementací: 61 | 62 | * BIND 9.13.3 (vývojová verze) a 9.14.0 (produkční) 63 | * Knot Resolver ve všech současných verzích již implementuje striktní chování 64 | * PowerDNS Recursor 4.2.0 65 | * Unbound 1.9.0 66 | 67 | 68 | 69 | 70 | Správci DNS serverů 71 | ------------------- 72 | Po 1. únoru 2019 [poskytovatelé veřejných DNS resolverů, kteří jsou uvedení níže](#supporters) během krátkého období ukončí podporu autoritativních serverů, jež nedodržují starší standard DNS z roku 1987 ([RFC1035]) ani novější standard [EDNS] z roku 1999 ([RFC2671], [RFC6891]). Domény hostované na serverech, které nedodržují standardy se tak pro významnou část uživatelů Internetu stanou nedostupnými. 73 | 74 | Pro minimalizaci problémů vám doporučujeme použít následující postup: 75 | 1. Otestujte své autoritativní servery pomocí [formuláře uvedeného výše](#domain-holders). Stačí otestovat libovolnou DNS zónu hostovanou na vašich DNS serverech. (Testované vlastnosti serverů nezávisí na obsahu zóny, takže není potřeba testovat všechny zóny jednotlivě, stačí pokrýt všechny autoritativní servery.) 76 | 1. Výsledek testu může být ovlivněn dočasným problémem v síti. Pokud je detekován problém, zkuste zopakovat test. 77 | 1. Pokud testy selhávají, aktualizujte váš DNS software na poslední stabilní verzi a zopakujte test. Pokud testy selhávají i po aktualizaci DNS softwaru, doporučujeme vám zkontrolovat konfiguraci firewallu. 78 | 1. **Firewally nesmí zahazovat DNS pakety** obsahující rozšíření [EDNS], včetně dosud neznámých rozšíření splňující standard EDNS. 79 | 80 | Články jednotlivých výrobců k tomuto tématu naleznete zde: 81 | * [Akamai](https://community.akamai.com/customers/s/article/CloudSecurityDNSFlagDayandAkamai20190115151216?language=en_US) 82 | * [Citrix](https://support.citrix.com/article/CTX241493) 83 | * [BlueCat](https://www.bluecatnetworks.com/blog/dns-flag-day-is-coming-and-bluecat-is-ready/) 84 | * [efficient iP](http://www.efficientip.com/dns-flag-day-notes/) 85 | * [F5 BIG-IP](https://support.f5.com/csp/article/K07808381?sf206085287=1) 86 | * [Google](https://groups.google.com/d/msg/public-dns-announce/-qaRKDV9InA/CsX-2fJpBAAJ) 87 | * [Infoblox](https://community.infoblox.com/t5/Community-Blog/DNS-Flag-Day/ba-p/15843?es_p=8449211) 88 | * [Microsoft Azure](https://azure.microsoft.com/en-us/updates/azure-dns-flag-day/), [Microsoft DNS](https://support.microsoft.com/en-sg/help/4489468/windows-server-domain-name-system-dns-flag-day-compliance) 89 | * [Pulse Secure](https://kb.pulsesecure.net/articles/Pulse_Secure_Article/KB43996) 90 | * Juniper SRX ve výchozím nastavení zahazují EDNS pakety. Řešením je buď upgrade na polední verzi, nebo vypnutí funkce "DNS doctoring" příkazem `# set security alg dns doctoring none`. 91 | 92 | Pokud jste provedli upgrade DNS softwaru a problém přetrvává i po aplikaci postupů uvedených výše, prosím kontaktujte výrobce firewallu a požadujte opravu. 93 | 94 | 95 | 96 | Podrobnosti o testování 97 | ----------------------- 98 | Vaše doména může nebo nemusí obsahovat předponu `www`, např. doména může být `www.nic.cz` nebo pouze `nic.cz`. Pokud si nejste jistí, doporučujeme vám otestovat obě možnosti. Pro jména, která nejsou tzv. DNS zóny, bude testovací formulář upozorňovat, že se nejedná o zónu. V takovém případě lze konkrétní jméno ignorovat a otestovat pouze druhé z dvojice. 99 | 100 | 101 | ### Skenování velkého počtu domén 102 | 103 | Testovací [formulář uvedený výše](#domain-holders) na pozadí používá server s nástrojem [ednscomp](https://ednscomp.isc.org/ednscomp), který nemá velkou kapacitu. Pokud potřebujete otestovat velké množství domén, použijte prosím [nástroje odkazované níže](#tools). Pokud budete nadmíru zatěžovat server automatizovanými dotazy, budeme nuceni omezit počet dotazů nebo vám službu odepřít. 104 | 105 | ### Podrobné výsledky testů 106 | 107 | Testovací [formulář uvedený výše](#domain-holders) na pozadí provádí technické testy pomocí nástroje [ednscomp](https://ednscomp.isc.org/ednscomp) a z dílčích výsledků počítá souhrnné hodnocení. 108 | 109 | DNS servery lze také otestovat přímo pomocí nástroje [ednscomp](https://ednscomp.isc.org/ednscomp), který zobrazuje podrobnou technickou zprávu. Do pole `zone name` zadejte jméno jakékoliv zóny hostované na vašich DNS serverech a klikněte na tlačítko `Submit`. 110 | 111 | Celkový výsledek zobrazený nástrojem [ednscomp](https://ednscomp.isc.org/ednscomp) by měla být zpráva `All Ok` (zelenou barvou). 112 | 113 | ### Minimální funkční konfigurace 114 | 115 | Pro minimální konfiguraci, která ještě bude v roce 2019 fungovat, nevypisuje nástroj [ednscomp](https://ednscomp.isc.org/ednscomp) výsledek `timeout` v žádném z testů pro původní DNS ani v testech pro rozšíření EDNS verze 0. Vezměte prosím na vědomí, že takováto minimální konfigurace stále neodpovídá standardům a dříve nebo později bude způsobovat potíže. Z tohoto důvodu **doporučujeme najednou opravit vaše DNS tak, aby všechny testy skončily výsledkem `ok`**. Vyhnete se tak problémům v budoucnu. 116 | 117 | Pokud bude zjištěn problém, nástroj ednscomp vám zobrazí vysvětlení pro každý test. Problémy jsou typicky způsobeny: 118 | * zastaralým nebo nekvalitním DNS softwarem 119 | * chybnou konfigurací firewallu 120 | 121 | **Firewally nesmí zahazovat DNS pakety** obsahující rozšíření [EDNS], včetně dosud neznámých rozšíření splňující standard EDNS. Moderní DNS software používá rozšíření jako např. [DNS cookies](https://tools.ietf.org/html/rfc7873) pro ochranu proti [DDoS] útokům. Firewally, které zahazují DNS pakety s rozšířeními ve skutečnosti zhoršují situaci pro všechny uživatele, včetně zhoršování DDoS útoků a zpomalování DNS provozu. 122 | 123 | Další technické podrobnosti jsou uvedeny v [následující kapitole](#experts). 124 | 125 | 126 | 127 | 128 | Zajímám se o DNS z odborného hlediska 129 | ===================================== 130 | 131 | Vývojáři DNS softwaru 132 | --------------------- 133 | Hlavní změna spočívá v tom, že DNS software od výše uvedených výrobců bude nově interpretovat timeout (vypršení časového limitu požadavku) jako příznak problému na síti nebo vzdáleném serveru. Počínaje 1. únorem 2019 DNS timeout **nezpůsobí vypnutí EDNS**. 134 | 135 | Důsledkem je, že DNS servery které **vůbec neodpovídají na EDNS dotazy** se stanou zcela nedostupnými. 136 | 137 | Prosím otestujte svou implementaci DNS pomocí nástroje [ednscomp](https://ednscomp.isc.org/ednscomp) a ujistěte se, že správně zpracováváte rozšíření EDNS. Zdrojový kód testovacího nástroje je také [k dispozici](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing). 138 | 139 | Zdůrazňujeme, že rozšíření [EDNS] stále není povinné. Pokud se rozhodnete nepodporovat EDNS, vše bude fungovat pokud se váš software bude řídit podle [EDNS standardu sekce 7](https://tools.ietf.org/html/rfc6891#section-7). 140 | 141 | Jinak řečeno, software, který správně implementuje původní standard [RFC1035] z roku 1987 nevyžaduje změny. Opravy vyžaduje pouze software, který nedodržuje standardy. 142 | 143 | 144 | Výzkumníci 145 | ---------- 146 | Další zdroje pro výzkumníky, operátory TLD atd.: 147 | 148 | * [Statistiky podpory EDNS](https://ednscomp.isc.org/) vygenerované pomocí [sady EDNS testů](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing) vytvořené sdružením ISC. 149 | * [Prezentace](#presentations) níže 150 | * [Nástroje](#tools) pro skenování velkého počtu domén atd. 151 | 152 | 153 | 154 | 155 | Prezentace 156 | ========== 157 | 158 | Obecné 159 | ------ 160 | * Bude vaše doména fungovat i v roce 2019? - CSNOG1: [abstrakt](https://csnog.eu/event/1/contributions/33/), [prezentace](https://csnog.eu/event/1/contributions/33/attachments/9/31/Petr_Spacek_01.pdf), [video](https://youtu.be/KQO48HbY6o0) 161 | * LOADAYS 2018: [abstrakt](http://loadays.org/pages/dnsupdate.html), [prezentace](http://loadays.org/files/plexis-edns-workaround-removal-loadays-2018.pdf), [video](https://www.youtube.com/watch?v=OXbbH0ORmSY) 162 | 163 | Technické 164 | --------- 165 | * DNS-OARC 29: A tale of five ccTLDs [abstract](https://indico.dns-oarc.net/event/29/contributions/662/), [slides](https://indico.dns-oarc.net/event/29/contributions/662/attachments/634/1063/EDNS_Flag_Day_-_OARC29.pdf), [video](https://youtu.be/rneu1lnJmUI?list=PLCAxS3rufJ1cOBd1D4K4QJFmLcSypixh3&t=2010) 166 | * DNS-OARC 29: Estimating impact of the (E)DNS flag day [abstract](https://indico.dns-oarc.net/event/29/contributions/644/), [slides](https://indico.dns-oarc.net/event/29/contributions/644/attachments/632/1018/edns.pdf), [video](https://youtu.be/rneu1lnJmUI?list=PLCAxS3rufJ1cOBd1D4K4QJFmLcSypixh3&t=3001) 167 | * DNS-OARC 28: First announcement [abstract](https://indico.dns-oarc.net/event/28/contributions/515/), [slides](https://indico.dns-oarc.net/event/28/contributions/515/attachments/490/799/Removing_EDNS_Workarounds.pdf), [video](https://www.youtube.com/watch?v=9YYH8JFH_bY&feature=youtu.be&t=5198) 168 | 169 | 170 | 171 | 172 | Nástroje 173 | ======== 174 | 175 | * [ISC EDNS Compliance tester](https://ednscomp.isc.org/), [zdrojový kód](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing) pro testování všech aspektů implementace EDNS 176 | * [EDNS zone scanner](https://gitlab.labs.nic.cz/knot/edns-zone-scanner/) pro kontrolu velkého množství zón a vyhodnocení dopadů změny (CZ.NIC) 177 | * [Testování EDNS kompatibility pomocí nástroje dig](https://kb.isc.org/docs/edns-compatibility-dig-queries) 178 | * [DNSViz](http://dnsviz.net/) 179 | 180 | Před interpretací dat si prosím přečtěte metodologii uvedenou u konkrétního zdroje. S dotazy se neváhejte obrátit na autory nástrojů pomocí odkazů uvedených výše. 181 | 182 | 183 | Kontakty 184 | ======== 185 | 186 | * Připomínky k tomuto webu prosím směřujte do [dnsflagday repozitáře](https://github.com/dns-violations/dnsflagday/issues) na Githubu 187 | * Komentáře k výsledkům testů z toho webu nebo přímo [nástroje ednscomp](https://ednscomp.isc.org/ednscomp) prosím hlaste do [DNS Compliance Testing](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing) projektu v Gitlabu ISC 188 | 189 | 190 | 191 | Akci podporují 192 | ============== 193 | {% include 2019_supporters.html %} 194 | 195 | Literatura 196 | ========== 197 | * [Minimal EDNS compliance requirements](https://datatracker.ietf.org/doc/draft-spacek-edns-camel-diet/) 198 | * [“The DNS Camel”, or, the rise in DNS complexity](https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/) 199 | 200 | [DDoS]: https://cs.wikipedia.org/wiki/Denial_of_service#Distributed_DoS 201 | [DNS]: https://cs.wikipedia.org/wiki/Domain_Name_System 202 | [RFC1035]: https://tools.ietf.org/html/rfc1035 203 | [EDNS]: https://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS 204 | [RFC2671]: https://tools.ietf.org/html/rfc2671 205 | [RFC6891]: https://tools.ietf.org/html/rfc6891 206 | -------------------------------------------------------------------------------- /2019/index-de.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 2019 3 | lang: de 4 | redirect_from: 5 | - /2019/de/ 6 | flagdayyear: 2019 7 | --- 8 | 9 | {% include 2019_languages.html %} 10 | 11 | **Dies ist die Archivversion der Seite, die die im Februar 2019 abgeschlossene Veranstaltung beschreibt. Für heute relevante Informationen finden Sie auf der Hauptseite [dnsflagday.net](https://dnsflagday.net/).** 12 | 13 | Wir haben keine vollständige deutsche Übersetzung; bitte lesen Sie [diesen Artikel von golem.de](https://www.golem.de/news/dns-flag-day-keine-ruecksicht-mehr-auf-fehlerhafte-dns-server-1901-138905.html). 14 | 15 | Prüfen Sie Ihre Domain hier: 16 | {% include 2019_checker.html lang=site.data.2019_checker.en %} 17 | 18 | Weitere Informationen finden Sie [in der englischen Version](index.html). 19 | -------------------------------------------------------------------------------- /2019/index-pt-br.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 2019 3 | lang: pt-BR 4 | redirect_from: 5 | - /2019/pt-br/ 6 | flagdayyear: 2019 7 | --- 8 | 9 | {% include 2019_languages.html %} 10 | 11 | **Esta é a versão do arquivo da página que descreve o evento concluído em fevereiro de 2019. Informações relevantes para hoje podem ser encontradas na página principal [dnsflagday.net](https://dnsflagday.net/).** 12 | 13 | **Esta tradução está aguardando atualização, por favor veja a [versão em inglês](/2019/en/) para as últimas informações.** 14 | 15 | 16 | O que está acontecendo? 17 | ======================= 18 | Os sistemas de [DNS](https://pt.wikipedia.org/wiki/Domain_Name_System) atuais sofrem demoras desnecessárias e dificuldades para lançar novas funcionalidades. Para remediar esses problemas, [desenvolvedores](#apoiadores) e grandes [provedores](#apoiadores) públicos de DNS irão remover certas modificações (workarounds) no dia **1 de Fevereiro de 2019**. 19 | 20 | Essa mudança impacta apenas sites que operam software que não esteja seguindo os padrões publicados. Você será impactado? 21 | 22 | Donos de Domínios 23 | ================= 24 | Por favor verifique se seu domínio será impactado: 25 | {% include 2019_checker.html lang=site.data.2019_checker.ptbr %} 26 | 27 | Administradores de DNS 28 | ====================== 29 | Para começar a entender como está sua conformidade com o EDNS, recomendamos que você utilize o formulário acima que irá produzir um relatório simplificado para o domínio inteiro. 30 | 31 | É também possível testar seus servidores de DNS diretamente utilizando a ferramenta [ednscomp](https://ednscomp.isc.org/ednscomp) que mostra um relatório técnico detalhado. Coloque o nome da zona hospedada nos seus servidores de DNS no campo `zone name` e clique no botão `Submit`. 32 | 33 | O resultado dos testes de [ednscomp](https://ednscomp.isc.org/ednscomp) deve ser uma mensagem em verde dizendo `All Ok`. 34 | 35 | Para ter o mínimo necessário para que seu domínio continue funcionando após o 2019 DNS flag day, nenhum teste de DNS e EDNS versão 0 deve ter o resultado `timeout` na ferramenta [ednscomp](https://ednscomp.isc.org/ednscomp). É importante ressaltar que ter apenas o mínimo necessário poderá causar outros problemas cedo ou tarde. Por essa razão **nós recomendados que garanta que todos os testes EDNS estejam `ok`** em vez de fazer apenas as correções mínimas, se não você poderá ter novos problemas em um futuro próximo. 36 | 37 | Se forem encontrados problemas, a ferramenta ednscomp irá mostrar uma explicação para cada teste que falhou. Falhas nesses testes são tipicamente causadas por: 38 | * software de DNS com problemas 39 | * configuração de firewall com problemas 40 | 41 | Para corrigir esses problemas, por favor atualize seu software de DNS para a última versão estável disponível e execute os testes novamente. Se os testes ainda assim falharem, por favor verifique a configuração do seu firewall. 42 | 43 | **Firewalls não devem bloquear pacotes de DNS com extensões EDNS**, incluindo extensões desconhecidas. Softwares de DNS modernos podem implementar novas extensões (ex. [DNS cookies](https://tools.ietf.org/html/rfc7873) para proteger contra ataques DoS). Firewalls que bloqueiam pacotes de DNS com essas extensões apenas pioram a situação para todo mundo, fazendo com que ataques de DoS sejam piores e a latência do tráfego de DNS seja mais alta. 44 | 45 | Desenvolvedores de software de DNS 46 | ================================== 47 | A maior mudança será que sistemas de DNS dos desenvolvedores acima irão interpretar timeouts como um sinal de problemas na rede ou no servidor. Começando no dia 1 de Fevereiro de 2019, não haverá **nenhuma tentativa de desabilitar EDNS** caso uma solicitação de DNS gere um timeout. 48 | 49 | Isso significa que todos os servidores de DNS que **não responderem às solicitações EDNS** serão tratados como *inativos*. 50 | 51 | Por favor teste sua implementação usando a ferramenta [ednscomp](https://ednscomp.isc.org/ednscomp) para garantir que você está tratando requisições EDNS adequadamente. O código fonte dessa ferramenta está disponível [aqui](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing). 52 | 53 | É importante pontuar que o suporte a EDNS ainda não é obrigatório. Se você decidir não suportar EDNS, não haverá nenhum problema desde que seu software responda à solicitações de acordo com a [seção 7 do padrão EDNS](https://tools.ietf.org/html/rfc6891#section-7). 54 | 55 | Pesquisadores 56 | ============= 57 | Pesquisadores e outros envolvidos, tais como operadores de TLD, podem se interessar pelos documentos abaixo: 58 | * [Estatísticas de conformidade EDNS](https://ednscomp.isc.org/) geradas pela [suíte de testes de conformidade EDNS](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing) do ISC 59 | * [EDNS zone scanner](https://gitlab.labs.nic.cz/knot/edns-zone-scanner/) por CZ.NIC que permite avaliar o impacto real do DNS flag day 60 | 61 | Por favor leia as respectivas metodologias antes de interpretar os dados. Em qualquer caso, não hesite em entrar em contato com os autores das ferramentas usando os links acima. 62 | 63 | Apresentações 64 | ============= 65 | 66 | * DNS-OARC 28: [abstract](https://indico.dns-oarc.net/event/28/contributions/515/), [slides](https://indico.dns-oarc.net/event/28/contributions/515/attachments/490/799/Removing_EDNS_Workarounds.pdf), [video](https://www.youtube.com/watch?v=9YYH8JFH_bY&feature=youtu.be&t=5198) 67 | * LOADAYS 2018: [abstract](http://loadays.org/pages/dnsupdate.html), [slides](http://loadays.org/files/plexis-edns-workaround-removal-loadays-2018.pdf), [video](https://www.youtube.com/watch?v=OXbbH0ORmSY) 68 | * RIPE 76: [slides](https://ripe76.ripe.net/presentations/159-edns.pdf), [video](https://ripe76.ripe.net/archives/video/161) 69 | * DNS-OARC 29: [abstract](https://indico.dns-oarc.net/event/29/contributions/662/), [slides](https://indico.dns-oarc.net/event/29/contributions/662/attachments/634/1063/EDNS_Flag_Day_-_OARC29.pdf) 70 | 71 | Ferramentas 72 | =========== 73 | 74 | * [ISC EDNS Compliance tester](https://ednscomp.isc.org/), [source code](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing) 75 | * [DNSViz](http://dnsviz.net/) 76 | 77 | Contatos 78 | ======== 79 | 80 | * Comentários sobre este site podem ser adicionados no [repositório do dnsflagday](https://github.com/dns-violations/dnsflagday/issues) no Github 81 | * Comentários sobre os resultados de testes gerados por esse site ou pela [ferramenta ednscomp](https://ednscomp.isc.org/ednscomp) deve ser feitos no site do projeto [DNS Compliance Testing](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing). 82 | 83 | Apoiadores 84 | ========== 85 | {% include 2019_supporters.html %} 86 | 87 | Leitura Adicional 88 | ================= 89 | * [Minimal EDNS compliance requirements](https://datatracker.ietf.org/doc/draft-spacek-edns-camel-diet/) 90 | * [“The DNS Camel”, or, the rise in DNS complexity](https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/) 91 | -------------------------------------------------------------------------------- /2019/index-ru.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 2019 3 | lang: ru 4 | redirect_from: 5 | - /2019/ru/ 6 | flagdayyear: 2019 7 | --- 8 | 9 | {% include 2019_languages.html %} 10 | 11 | **Это архивная версия страницы с описанием события, завершившегося в феврале 2019 года. Информация, актуальная на сегодняшний день, доступна на главной странице [dnsflagday.net](https://dnsflagday.net/).** 12 | 13 | **Этот перевод ожидает обновления, пожалуйста, смотрите [английскую версию](/2019/en/) для последней информации.** 14 | 15 | Что происходит? 16 | ================== 17 | Текущий [DNS](https://ru.wikipedia.org/wiki/DNS) излишне медленный и страдает от невозможности развертывания новых функций. Чтобы исправить эти проблемы, [производители программного обеспечения DNS](#supporters) а также большие [общедоступные DNS-провайдеры](#supporters) собираются убрать определенные обходные пути 1 февраля 2019 года. 18 | 19 | Это изменение касается только сайтов, на которых установлено программное обеспечение, не соответствующее опубликованным стандартам. Вы затронуты? 20 | 21 | Владельцам доменов 22 | ============= 23 | Пожалуйста, проверьте затронут ли ваш домен: 24 | {% include 2019_checker.html lang=site.data.2019_checker.ru %} 25 | 26 | Операторам DNS-резольвера 27 | ====================== 28 | 29 | 1 февраля 2019(или около), основные поставщики средств распознавания с открытым исходным кодом будут выпускать обновления, которые реализуют более строгую обработку EDNS. В частности, следующие версии вводят это изменение: 30 | 31 | * BIND 9.13.3 (development) и 9.14.0 (production) 32 | * Knot Resolver уже внедрил более строгую обработку EDNS во всех текущих версиях 33 | * PowerDNS Recursor 4.2.0 34 | * Unbound 1.9.0 35 | 36 | Также [общественные DNS провайдеры перечисленные ниже](#supporters) отключат обходные пути. 37 | 38 | Операторам DNS серверов 39 | ==================== 40 | Для ознакомления с соответствием EDNS мы рекомендуем использовать форму выше, которая дает упрощенный результат для всего домена. 41 | 42 | Также возможно протестировать ваши DNS-серверы напрямую, используя инструмент [ednscomp](https://ednscomp.isc.org/ednscomp) который отображает подробный технический отчет. Просто введите название зоны, размещенной на ваших DNS-серверах, в поле `zone name` и нажмите кнопку `Submit`. 43 | 44 | Итоговый результат тестов [ednscomp](https://ednscomp.isc.org/ednscomp) желательно должнен быть зеленым сообщением `All Ok`. 45 | 46 | Минимальная рабочая настройка, которая позволит вашему домену выжить в 2019 DNS flag day - отсутствие результата `timeout` в любом из простых тестов DNS и EDNS версии 0, реализованных в инстурменте [ednscomp](https://ednscomp.isc.org/ednscomp). Обратите внимание, что эта минимальная настройка все еще не соответствует стандартам и рано или поздно вызовет другие проблемы. По этой причине **мы настоятельно рекомендуем вам получить полное соответствие EDNS (все тесты `ok`)** вместо того, чтобы выполнять минимальную очистку, иначе вам придется столкнуться с новыми проблемами позже. 47 | 48 | Если есть проблема, инструмент ednscomp отображает объяснение каждого неудачного теста. Сбои в этих тестах обычно вызваны: 49 | 50 | * неправильным программным обеспечением DNS 51 | * неправильной конфигурацией брандмауэра 52 | 53 | Чтобы устранить проблемы, обновите программное обеспечение DNS до последних стабильных версий и повторите тестирование. Если тесты по-прежнему не проходят даже после обновления DNS, проверьте конфигурацию брандмауэра. 54 | 55 | **Межсетевые экраны не должны отбрасывать пакеты DNS** с расширениями EDNS, включая неизвестные расширения. Современное программное обеспечение DNS может развертывать новые расширения (например [DNS cookies](https://tools.ietf.org/html/rfc7873) для защиты от DoS атак). Брандмауэры, которые отбрасывают пакеты DNS с такими расширениями, ухудшают ситуацию для всех, в том числе обостряют атаки DoS и увеличивают задержку трафика DNS. 56 | 57 | Подсказки продавца: 58 | 59 | * Более старые версии Juniper SRX по умолчанию отбрасывают пакеты EDNS. Обходной путь - отключить лечение DNS с помощью `# set security alg dns doctoring none`. Обновление до последних версий для поддержки EDNS. 60 | * [Akamai](https://community.akamai.com/customers/s/article/CloudSecurityDNSFlagDayandAkamai20190115151216?language=en_US) 61 | * [BlueCat](https://www.bluecatnetworks.com/blog/dns-flag-day-is-coming-and-bluecat-is-ready/) 62 | * [Citrix](https://support.citrix.com/article/CTX241493) 63 | * [efficient iP](http://www.efficientip.com/dns-flag-day-notes/) 64 | * [F5 BIG-IP](https://support.f5.com/csp/article/K07808381?sf206085287=1) 65 | * [Google](https://groups.google.com/d/msg/public-dns-announce/-qaRKDV9InA/CsX-2fJpBAAJ) 66 | * [Infoblox](https://community.infoblox.com/t5/Community-Blog/DNS-Flag-Day/ba-p/15843?es_p=8449211) 67 | * [Microsoft Azure](https://azure.microsoft.com/en-us/updates/azure-dns-flag-day/), [Microsoft DNS](https://support.microsoft.com/en-sg/help/4489468/windows-server-domain-name-system-dns-flag-day-compliance) 68 | * [Pulse Secure](https://kb.pulsesecure.net/articles/Pulse_Secure_Article/KB43996) 69 | 70 | Разработчикам DNS ПО 71 | ======================= 72 | Основное изменение заключается в том, что программное обеспечение DNS от вышеперечисленных поставщиков будет интерпретировать тайм-ауты как признак проблемы сети или сервера. С 1 февраля 2019 **нет попытки отключить EDNS** как реакцию на тайм-аут DNS-запроса. 73 | 74 | Это фактически означает, что все DNS-серверы, которые **вообще не отвечают на запросы EDNS** будут рассматриваться как *мертвые*. 75 | 76 | Пожалуйста, проверьте ваши реализации, используя инструмент [ednscomp](https://ednscomp.isc.org/ednscomp) чтобы убедиться, что вы правильно обрабатываете EDNS. Исходный код инструмента также [доступен](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing). 77 | 78 | Важно отметить, что EDNS все еще не является обязательным. Если вы решите не поддерживать EDNS, это нормально, если ваше программное обеспечение отвечает в соответствии с [EDNS раздел стандарта 7](https://tools.ietf.org/html/rfc6891#section-7). 79 | 80 | Исследователям 81 | =========== 82 | Исследователи и другие стороны, такие как операторы TLD, могут быть заинтересованы в: 83 | 84 | * [Статистика соответствия EDNS](https://ednscomp.isc.org/) сгенерированная [набором тестов на соответствие EDNS](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing) от ISC 85 | * [Сканер зон EDNS](https://gitlab.labs.nic.cz/knot/edns-zone-scanner/) от CZ.NIC цель которого - оценить реальное влияние DNS flag day 86 | 87 | Пожалуйста, прочтите соответствующие методологии, прежде чем интерпретировать данные. В любом случае, не стесняйтесь обращаться к авторам инструментов, используя ссылки GitLab выше. 88 | 89 | Презентации 90 | ============= 91 | 92 | * DNS-OARC 28: [реферат](https://indico.dns-oarc.net/event/28/contributions/515/), [слайды](https://indico.dns-oarc.net/event/28/contributions/515/attachments/490/799/Removing_EDNS_Workarounds.pdf), [видео](https://www.youtube.com/watch?v=9YYH8JFH_bY&feature=youtu.be&t=5198) 93 | * LOADAYS 2018: [реферат](http://loadays.org/pages/dnsupdate.html), [слайды](http://loadays.org/files/plexis-edns-workaround-removal-loadays-2018.pdf), [видео](https://www.youtube.com/watch?v=OXbbH0ORmSY) 94 | * RIPE 76: [слайды](https://ripe76.ripe.net/presentations/159-edns.pdf), [видео](https://ripe76.ripe.net/archives/video/161) 95 | * DNS-OARC 29: [реферат](https://indico.dns-oarc.net/event/29/contributions/662/), [слайды](https://indico.dns-oarc.net/event/29/contributions/662/attachments/634/1063/EDNS_Flag_Day_-_OARC29.pdf) 96 | 97 | Инструменты 98 | ===== 99 | 100 | * [Тестер соответствия ISC EDNS](https://ednscomp.isc.org/), [исходный код](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing) 101 | * [DNSViz](http://dnsviz.net/) 102 | 103 | Контакты 104 | ======== 105 | 106 | * Пожалуйста, оставьте комментарии в [репозитории dnsflagday](https://github.com/dns-violations/dnsflagday/issues) на GitHub 107 | * Комментарии относительно результатов испытаний, сгенерированных этой сетью или непосредственно [инструмент тестирования ednscomp](https://ednscomp.isc.org/ednscomp) принадлежащий проекту [тестирования на соответствие DNS](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing) на ISC GitLab 108 | 109 | Сторонники 110 | ========== 111 | {% include 2019_supporters.html %} 112 | 113 | Дополнительное чтение 114 | ================== 115 | * [Минимальные требования соответствия EDNS](https://datatracker.ietf.org/doc/draft-spacek-edns-camel-diet/) 116 | * [“DNS верблюд”, или, рост сложности DNS](https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/) 117 | -------------------------------------------------------------------------------- /2019/index-zh-CN.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 2019 3 | lang: zh-CN 4 | redirect_from: 5 | - /2019/zh-CN/ 6 | flagdayyear: 2019 7 | --- 8 | 9 | {% include 2019_languages.html %} 10 | 11 | **这是描述2019年期间发生的事件的页面的存档版本。最新信息可在第[dnsflagday.net/](https://dnsflagday.net/)页找到。** 12 | 13 | **此翻译正在等待更新，[请参阅英文版以获取最新信息](/2019/en/)。** 14 | 15 | 16 | 发生了什么事？ 17 | ================== 18 | 当前 [DNS](https://zh.wikipedia.org/wiki/%E5%9F%9F%E5%90%8D%E7%B3%BB%E7%BB%9F) 缓慢的速度是不必要的，并且 DNS 无法部署新功能。为了解决这些问题，[DNS 软件供应商](#支持者)以及大型[公共 DNS 提供商](#支持者)将在2019年2月1日删除某些变通方案。 19 | 20 | 这一更改仅影响运行不符合已发布标准的软件的网站。您受影响了吗？ 21 | 22 | 域名所有者 23 | ============= 24 | 请检查您的域名是否受到影响： 25 | {% include 2019_checker.html lang=site.data.2019_checker.zh-CN %} 26 | 27 | DNS 解析器运营商 28 | ====================== 29 | 30 | 在2019年2月1日左右，主要的开源解析器供应商将发布实施更严格的 EDNS 处理的更新。 具体而言，以下版本引入了此更改： 31 | 32 | * BIND 9.13.3 (development) 和 9.14.0 (production) 33 | * Knot Resolver 已经在当前版本中实施了更严格的 EDNS 处理 34 | * PowerDNS Recursor 4.2.0 35 | * Unbound 1.9.0 36 | 37 | 此外，[下面列出的公共 DNS 提供商](#支持者) 将会禁用变通方案。 38 | 39 | DNS 服务器运营商 40 | ==================== 41 | 为了使 EDNS 合规，我们建议您利用上面的表单，为整个域生成简化的结果。 42 | 43 | 也可以直接使用工具 [ednscomp](https://ednscomp.isc.org/ednscomp) 测试 DNS 服务器，该工具会显示详细的技术报告。只需您在 `Zone Name` 字段输入 DNS 服务器上所承载的域名并单击 `Submit` 按钮。 44 | 45 | [ednscomp](https://ednscomp.isc.org/ednscomp) 最好的测试总结结果是一条绿色的信息 `一切正常/All Ok`。 46 | 47 | 允许您的域名在 2019 DNS flag day 后继续运行的最低工作设置是在 [ednscomp](https://ednscomp.isc.org/ednscomp) 工具的测试中，所有普通 DNS 以及 EDNS0 不包含 `超时/timeout` 的测试结果。请注意, 此最低设置仍不符合标准, 迟早会导致其他问题。出于这个原因，**我们强烈建议您完全遵守 EDNS 标准（所有测试都 `正常/ok`）**，而不是仅进行极少的整顿工作，否则您将不得不在以后面临新的问题。 48 | 49 | 如果出现问题，ednscomp 工具将会显示每个为何失败的测试的说明。这些失败的测试通常是因为： 50 | 51 | * 损坏的 DNS 软件 52 | * 损坏的防火墙配置 53 | 54 | 要解决问题，请将您的 DNS 软件升级到最新的稳定版本，然后再次测试。如果即使在升级了 DNS 之后仍然测试失败，请检查您的防火墙配置。 55 | 56 | **防火墙不得丢弃 DNS 数据包**，无论是具有 EDNS 扩展的数据包，还是包含未知扩展的数据包。现代 DNS 软件可能会部署新的扩展（例如 [DNS cookies](https://tools.ietf.org/html/rfc7873)，用以防止 DoS 攻击）。丢弃具有此类扩展的 DNS 数据包的防火墙会使每个人的情况变得更加糟糕，包括恶化的 DoS 攻击以及导致更高的 DNS 流量延迟。 57 | 58 | 供应商的提示： 59 | 60 | * 较早版本的 Juniper SRX 默认会丢弃 EDNS 数据包 —— 解决方法是通过 `# set security alg dns doctoring none` 关闭 DNS doctoring。升级到最新版本以获得 EDNS 支持。 61 | * [Akamai](https://community.akamai.com/customers/s/article/CloudSecurityDNSFlagDayandAkamai20190115151216?language=zh_CN) 62 | * [BlueCat](https://www.bluecatnetworks.com/blog/dns-flag-day-is-coming-and-bluecat-is-ready/) 63 | * [Citrix](https://support.citrix.com/article/CTX241493) 64 | * [efficient iP](http://www.efficientip.com/dns-flag-day-notes/) 65 | * [F5 BIG-IP](https://support.f5.com/csp/article/K07808381?sf206085287=1) 66 | * [Google](https://groups.google.com/d/msg/public-dns-announce/-qaRKDV9InA/CsX-2fJpBAAJ) 67 | * [Infoblox](https://community.infoblox.com/t5/Community-Blog/DNS-Flag-Day/ba-p/15843?es_p=8449211) 68 | * [Microsoft Azure](https://azure.microsoft.com/en-us/updates/azure-dns-flag-day/), [Microsoft DNS](https://support.microsoft.com/en-sg/help/4489468/windows-server-domain-name-system-dns-flag-day-compliance) 69 | * [Pulse Secure](https://kb.pulsesecure.net/articles/Pulse_Secure_Article/KB43996) 70 | 71 | DNS 软件开发人员 72 | ======================= 73 | 主要变化是来自上述供应商的 DNS 软件会将超时解释为网络问题或服务器问题的标志。从2019年2月1日开始，将**不会尝试禁用 EDNS** 作为对 DNS 查询超时的反应。 74 | 75 | 这实际上意味着**所有对 EDNS 查询完全没有响应**的 DNS 服务器将被视为*死机*。 76 | 77 | 请使用 [ednscomp](https://ednscomp.isc.org/ednscomp) 工具测试您的实现方式，以确保正确处理 EDNS。该工具的源代码也是[可以获得的](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing)。 78 | 79 | 值得注意的是，EDNS 仍然不是强制性的。如果您决定不支持EDNS，只要您的软件根据 [EDNS 标准第七章节](https://tools.ietf.org/html/rfc6891#section-7) 进行回应即可。 80 | 81 | 研究人员 82 | =========== 83 | 研究人员和 TLD 运营商等其他方可能会对此感兴趣： 84 | 85 | * 由 [EDNS 合规性测试套件](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing)生成的 [EDNS 合规性统计](https://ednscomp.isc.org/) by ISC 86 | * [EDNS 区域扫描仪](https://gitlab.labs.nic.cz/knot/edns-zone-scanner/) by CZ.NIC，旨在评估 DNS flag day 的实际影响 87 | 88 | 在解释数据之前，请阅读各自的解析方法。无论如何，请不要犹豫，立即使用上面的 GitLab 链接与工具作者联系。 89 | 90 | 演讲 91 | ============= 92 | 93 | * DNS-OARC 28: [摘要](https://indico.dns-oarc.net/event/28/contributions/515/), [幻灯片](https://indico.dns-oarc.net/event/28/contributions/515/attachments/490/799/Removing_EDNS_Workarounds.pdf), [视频](https://www.youtube.com/watch?v=9YYH8JFH_bY&feature=youtu.be&t=5198) 94 | * LOADAYS 2018: [摘要](http://loadays.org/pages/dnsupdate.html), [幻灯片](http://loadays.org/files/plexis-edns-workaround-removal-loadays-2018.pdf), [视频](https://www.youtube.com/watch?v=OXbbH0ORmSY) 95 | * RIPE 76: [幻灯片](https://ripe76.ripe.net/presentations/159-edns.pdf), [视频](https://ripe76.ripe.net/archives/video/161) 96 | * DNS-OARC 29: [摘要](https://indico.dns-oarc.net/event/29/contributions/662/), [幻灯片](https://indico.dns-oarc.net/event/29/contributions/662/attachments/634/1063/EDNS_Flag_Day_-_OARC29.pdf) 97 | 98 | 工具 99 | ===== 100 | 101 | * [ISC EDNS 合规性测试器](https://ednscomp.isc.org/)，[源代码](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing) 102 | * [DNSViz](http://dnsviz.net/) 103 | 104 | 联系 105 | ======== 106 | 107 | * 请在 GitHub 上的 [dnsflagday repo](https://github.com/dns-violations/dnsflagday/issues) 中提交关于此网站的评论 108 | * 有关此站点生成的测试结果或由 [ednscomp 测试工具](https://ednscomp.isc.org/ednscomp)直接生成的测试结果的注释属于 ISC GitLab 中的 [DNS 合规性测试](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing)项目 109 | 110 | 支持者 111 | ========== 112 | {% include 2019_supporters.html %} 113 | 114 | 扩展阅读 115 | ================== 116 | * [最低的 EDNS 合规性要求](https://datatracker.ietf.org/doc/draft-spacek-edns-camel-diet/) 117 | * [“The DNS Camel”, or, the rise in DNS complexity](https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/) 118 | -------------------------------------------------------------------------------- /2019/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 2019 3 | lang: en-US 4 | redirect_from: 5 | - /2019/en/ 6 | flagdayyear: 2019 7 | --- 8 | 9 | {% include 2019_languages.html %} 10 | 11 | **This is archive version of page describing event which ended in February 2019. Information relevant for today can be found on main page [dnsflagday.net](https://dnsflagday.net/).** 12 | 13 | What is happening? 14 | ================== 15 | 16 | The current [DNS](https://en.wikipedia.org/wiki/Domain_Name_System) is unnecessarily slow and inefficient because of efforts to accommodate a few DNS systems that are not in compliance with DNS standards established two decades ago. 17 | 18 | To ensure further sustainability of the system it is time to end these accommodations and remediate the non-compliant systems. This change will make most DNS operations slightly more efficient, and also allow operators to deploy new functionality, including new mechanisms to protect against [DDoS] attacks. 19 | 20 | DNS software and service providers [listed on this site](#supporters) have agreed to coordinate removing accommodations for non-compliant DNS implementations from their software or services, on or around **February 1st 2019**. This change will affect only sites operating non-compliant software. 21 | 22 | For more information select the group you belong to: 23 | 24 | - [I'm an Internet user, without my own domain](#users) 25 | - [I'm a domain holder](#domain-holders) 26 | - [I'm a DNS administrator](#dns-admins) 27 | - [I'm a DNS expert (DNS software developer, research, etc.)](#experts) 28 | 29 | 30 | 31 | 32 | I'm an Internet user 33 | ================= 34 | There is no reason to worry if you are an Internet user without your own domain name. This change is affecting you only indirectly and you do not need to take any other steps. Thank you for your interest in [DNS]! 35 | 36 | 37 | 38 | 39 | I'm a domain holder 40 | ================= 41 | If you are a domain holder, please use the form below to check if your domain is ready for the planned change. Your test result will include advice on any further steps that may be necessary. 42 | 43 | {% include 2019_checker.html lang=site.data.2019_checker.en %} 44 | 45 | Please note it is only necessary to validate one zone if you have multiple zones on the same server or cluster of servers. See [technical details of tests](#test-details) for more information. 46 | 47 | 48 | 49 | I'm a DNS administrator 50 | ===================== 51 | The impact of the scheduled change to the client side of DNS is described in the section for [DNS resolver operators](#resolver-ops). A small percentage of authoritative servers might require changes [described below](#auth-ops). Further down we list [technical details of tests](#test-details) and [tools for experts](#experts). 52 | 53 | 54 | 55 | DNS resolver operators 56 | ---------------------- 57 | On or around Feb 1st, 2019, major open source resolver vendors will release updates that will stop accommodating non-standard responses. This change will affect authoritative servers which do not comply either with the original DNS standard from 1987 ([RFC1035]) or the newer [EDNS] standards from 1999 ([RFC2671] and [RFC6891]). Major [public DNS resolver operators listed below](#supporters) are also removing accommodations so this change will also impact Internet users and providers who use these public DNS services. 58 | 59 | Sites hosted on incompatible authoritative servers may become unreachable through updated resolvers. The [web form above](#domain-holders) diagnostic tool may be helpful while investigating problems with a particular domain. Domains which repeatedly fail the test above have problems with either their DNS software or their firewall configuration and cannot be fixed by DNS resolver operators. 60 | 61 | The following versions of DNS resolvers will not accommodate [EDNS] non-compliant responses: 62 | 63 | * BIND 9.13.3 (development) and 9.14.0 (production) 64 | * Knot Resolver has already implemented stricter EDNS handling in all current versions 65 | * PowerDNS Recursor 4.2.0 66 | * Unbound 1.9.0 67 | 68 | 69 | 70 | 71 | DNS server operators 72 | -------------------- 73 | After February 1st 2019 major [public DNS resolver operators listed below](#supporters) will disable work arounds for standards non-compliance. This change will affect domains hosted on authoritative servers which do not comply either with original DNS standard from 1987 ([RFC1035]) or the newer [EDNS] standards from 1999 ([RFC2671] and [RFC6891]). Non-compliant domains may become unreachable through these services. 74 | 75 | We advise you to take the following preparatory steps to avoid operational problems: 76 | 1. Test your authoritative servers using [test form above](#domain-holders). It is sufficient to test a single DNS zone hosted on a particular set of authoritative servers. (If any single zone on the server passes the test, that is sufficient, because the test is not dependant on the content of the zone.) 77 | 1. Random network instability can affect test results. Part of the problem is in interpreting timeouts, which can be caused by unresponsive DNS software, a firewall blocking the response, or packet loss on the Internet. If a problem is reported please retry the test. 78 | 1. If the tested domain fails the test, please update your DNS software to the latest stable version and repeat the test. If the tests are failing even after the DNS software update please check your firewall configuration. 79 | 1. **Firewalls must not drop DNS packets** with [EDNS] extensions, including unknown extensions which follow the standards. 80 | 81 | Relevant information from vendors can be found here: 82 | * [Akamai](https://community.akamai.com/customers/s/article/CloudSecurityDNSFlagDayandAkamai20190115151216?language=en_US) 83 | * [Citrix](https://support.citrix.com/article/CTX241493) 84 | * [BlueCat](https://www.bluecatnetworks.com/blog/dns-flag-day-is-coming-and-bluecat-is-ready/) 85 | * [efficient iP](http://www.efficientip.com/dns-flag-day-notes/) 86 | * [F5 BIG-IP](https://support.f5.com/csp/article/K07808381?sf206085287=1) 87 | * [Google](https://groups.google.com/d/msg/public-dns-announce/-qaRKDV9InA/CsX-2fJpBAAJ) 88 | * Juniper: Older versions of the Juniper SRX will drop EDNS packets by default. The workaround is to disable DNS doctoring via `# set security alg dns doctoring none`. Upgrade to latest versions for EDNS support. 89 | * [Infoblox](https://community.infoblox.com/t5/Community-Blog/DNS-Flag-Day/ba-p/15843?es_p=8449211) 90 | * [Microsoft Azure](https://azure.microsoft.com/en-us/updates/azure-dns-flag-day/), [Microsoft DNS](https://support.microsoft.com/en-sg/help/4489468/windows-server-domain-name-system-dns-flag-day-compliance) 91 | * [Pulse Secure](https://kb.pulsesecure.net/articles/Pulse_Secure_Article/KB43996) 92 | 93 | If the problem persists after DNS software and firewall updates please contact your firewall vendor and request fixes. 94 | 95 | 96 | 97 | 98 | Test details 99 | ------------ 100 | Your domain name may include `www`, e.g. `www.domainname.com`; or it may not, e.g. `domainname.com`. If you are not sure, we suggest that you test both. Names that are not DNS zones will report that this was the most likely reason for the test failure; this is not a cause for concern. 101 | 102 | 103 | 104 | 105 | ### Mass scanning 106 | 107 | The [test form above](#domain-holders) uses hosted [ednscomp](https://ednscomp.isc.org/ednscomp), which is a low-capacity service for ad-hoc checks only. If you need to send bulk queries, you must use [tools linked below](#tools) to run your own test instances. Please do not attempt to automate queries using this web site, an excessive use will be rate-limited or blocked. 108 | 109 | ### Obtaining detailed test results 110 | 111 | The [test form above](#domain-holders) uses [ednscomp](https://ednscomp.isc.org/ednscomp) for individual technical tests, and these partial results are summarized into an aggregate result by the web application. 112 | 113 | It is also possible to test your DNS servers directly using the tool [ednscomp](https://ednscomp.isc.org/ednscomp) which displays a more detailed technical report. Simply enter the name of a zone hosted on your DNS servers into the `zone name` field and click the `Submit` button. 114 | 115 | The summary result of [ednscomp](https://ednscomp.isc.org/ednscomp) tests should ideally be a green message `All Ok`. 116 | 117 | ### Minimal working configuration 118 | 119 | The minimal working setup which will allow your domain to survive 2019 DNS flag day must not have a `timeout` result in any of the plain DNS and EDNS version 0 tests implemented in the [ednscomp](https://ednscomp.isc.org/ednscomp) tool. Failures of the EDNS(1) tests will not cause any immediate problem. 120 | 121 | Please note that this minimal compliance is still not full compliance and will cause other issues sooner or later. For this reason **we strongly recommend you to work towards full EDNS compliance (all tests `ok`)** instead of doing just the minimum. 122 | 123 | If there is a problem, the ednscomp tool displays an explanation for each failed test. Failures in these tests are typically caused by: 124 | 125 | * broken DNS software 126 | * broken firewall configuration 127 | 128 | **Firewalls must not drop DNS packets** with EDNS extensions, including unknown extensions. Modern DNS software may deploy new extensions (e.g. [DNS cookies](https://tools.ietf.org/html/rfc7873) to protect from DoS attacks). Firewalls which drop DNS packets with such extensions are making the situation worse for everyone, including worsening DoS attacks and inducing higher latency for DNS traffic. 129 | 130 | 131 | 132 | 133 | I'm a DNS expert 134 | ============== 135 | 136 | DNS software developers 137 | ----------------------- 138 | The main change is that DNS software from vendors named above will interpret timeouts as sign of a network or server problem. Starting February 1st, 2019 there will be **no attempt to disable EDNS** in reaction to a DNS query timeout. 139 | 140 | This effectively means that all DNS servers which **do not respond at all to EDNS queries** are going to be treated as *dead*. 141 | 142 | Please test your implementations using the [ednscomp](https://ednscomp.isc.org/ednscomp) tool to make sure that you handle EDNS properly. Source code for the tool [is available](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing) as well. 143 | 144 | It is important to note that EDNS is still not mandatory. If you decide not to support EDNS it is okay as long as your software replies according to [EDNS standard section 7](https://tools.ietf.org/html/rfc6891#section-7). 145 | 146 | In other words, software which correctly implements the original DNS standard [RFC1035] from 1987 does not require any changes. Only non-compliant software has to be fixed. 147 | 148 | 149 | 150 | 151 | Researchers 152 | ----------- 153 | Researchers and other parties such as TLD operators might be interested in: 154 | 155 | * [EDNS compliance statistics](https://ednscomp.isc.org/) generated by [EDNS compliance test suite](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing) by ISC 156 | * [Presentations](#presentations) below 157 | * [Tools](#tools) for mass scanning etc. 158 | 159 | 160 | 161 | 162 | Presentations 163 | ============= 164 | 165 | General audience 166 | ---------------- 167 | * RIPE 77: Will your DNS break in 2019? [slides](https://ripe77.ripe.net/presentations/7-flagday.pdf), [video](https://ripe77.ripe.net/archives/video/2233/) 168 | * LOADAYS 2018: Is Your DNS Server Up-To-Date [abstract](http://loadays.org/pages/dnsupdate.html), [slides](http://loadays.org/files/plexis-edns-workaround-removal-loadays-2018.pdf), [video](https://www.youtube.com/watch?v=OXbbH0ORmSY) 169 | * UKNOF 2019: DNS Flag Day and Beyond [presentation](https://indico.uknof.org.uk/event/44/contributions/580/) 170 | 171 | Technical 172 | --------- 173 | * DNS-OARC 29: A tale of five ccTLDs [abstract](https://indico.dns-oarc.net/event/29/contributions/662/), [slides](https://indico.dns-oarc.net/event/29/contributions/662/attachments/634/1063/EDNS_Flag_Day_-_OARC29.pdf), [video](https://youtu.be/rneu1lnJmUI?list=PLCAxS3rufJ1cOBd1D4K4QJFmLcSypixh3&t=2010) 174 | * DNS-OARC 29: Estimating impact of the (E)DNS flag day [abstract](https://indico.dns-oarc.net/event/29/contributions/644/), [slides](https://indico.dns-oarc.net/event/29/contributions/644/attachments/632/1018/edns.pdf), [video](https://youtu.be/rneu1lnJmUI?list=PLCAxS3rufJ1cOBd1D4K4QJFmLcSypixh3&t=3001) 175 | * DNS-OARC 28: First announcement [abstract](https://indico.dns-oarc.net/event/28/contributions/515/), [slides](https://indico.dns-oarc.net/event/28/contributions/515/attachments/490/799/Removing_EDNS_Workarounds.pdf), [video](https://www.youtube.com/watch?v=9YYH8JFH_bY&feature=youtu.be&t=5198) 176 | 177 | 178 | 179 | 180 | Tools 181 | ===== 182 | 183 | Researchers and other parties such as large DNS operators might be interested in: 184 | 185 | * [ISC EDNS Compliance tester](https://ednscomp.isc.org/), [source code](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing) for testing all aspects of EDNS compliance 186 | * [EDNS zone scanner](https://gitlab.labs.nic.cz/knot/edns-zone-scanner/tree/master) for mass scanning and evaluation of real-world impact of the DNS flag day by CZ.NIC 187 | * [Testing EDNS Compatibility with dig](https://kb.isc.org/docs/edns-compatibility-dig-queries) 188 | * [DNSViz](http://dnsviz.net/) 189 | 190 | Please read the respective methodologies before interpreting the data. In any case, do not hesitate to reach out to tool authors using links above. 191 | 192 | 193 | Contacts 194 | ======== 195 | 196 | * Please file comments regarding this web in [dnsflagday repo](https://github.com/dns-violations/dnsflagday/issues) on GitHub 197 | * Comments regarding test results generated by this web or directly by [ednscomp test tool](https://ednscomp.isc.org/ednscomp) belong to [DNS Compliance Testing](https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing) project in ISC GitLab 198 | 199 | Supporters 200 | ========== 201 | {% include 2019_supporters.html %} 202 | 203 | Additional reading 204 | ================== 205 | * [Minimal EDNS compliance requirements](https://datatracker.ietf.org/doc/draft-spacek-edns-camel-diet/) 206 | * [“The DNS Camel”, or, the rise in DNS complexity](https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/) 207 | 208 | [DDoS]: https://en.wikipedia.org/wiki/Denial-of-service_attack#Distributed_DoS_attack 209 | [DNS]: https://en.wikipedia.org/wiki/Domain_Name_System 210 | [RFC1035]: https://tools.ietf.org/html/rfc1035 211 | [EDNS]: https://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS 212 | [RFC2671]: https://tools.ietf.org/html/rfc2671 213 | [RFC6891]: https://tools.ietf.org/html/rfc6891 214 | -------------------------------------------------------------------------------- /2020/index-ja.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 2020 3 | lang: ja-JP 4 | redirect_from: 5 | - /ja/ 6 | - /2020/ja/ 7 | flagdayyear: 2020 8 | --- 9 | 10 | {% include 2020_languages.html %} 11 | 12 | 13 | 14 | 内容 15 | ==== 16 | - [次回予告](#%E6%AC%A1%E5%9B%9E%E4%BA%88%E5%91%8A) 17 | - [DNS Flag Day 2020](#dns-flag-day-2020) 18 | - [対応: 権威DNSサーバーのオペレーター](#%E5%AF%BE%E5%BF%9C-%E6%A8%A9%E5%A8%81dns%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%81%AE%E3%82%AA%E3%83%9A%E3%83%AC%E3%83%BC%E3%82%BF%E3%83%BC) 19 | - [対応: フルサービスリゾルバーのオペレーター](#%E5%AF%BE%E5%BF%9C-%E3%83%95%E3%83%AB%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%83%AA%E3%82%BE%E3%83%AB%E3%83%90%E3%83%BC%E3%81%AE%E3%82%AA%E3%83%9A%E3%83%AC%E3%83%BC%E3%82%BF%E3%83%BC) 20 | - [対応: DNS ソフトウェア製品のベンダー](#%E5%AF%BE%E5%BF%9C-dns-%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E8%A3%BD%E5%93%81%E3%81%AE%E3%83%99%E3%83%B3%E3%83%80%E3%83%BC) 21 | - [テスト方法](#%E3%83%86%E3%82%B9%E3%83%88%E6%96%B9%E6%B3%95) 22 | - [誰が行っているの?](#%E8%AA%B0%E3%81%8C%E8%A1%8C%E3%81%A3%E3%81%A6%E3%81%84%E3%82%8B%E3%81%AE) 23 | - [最新情報を得る](#%E6%9C%80%E6%96%B0%E6%83%85%E5%A0%B1%E3%82%92%E5%BE%97%E3%82%8B) 24 | - [協力者](#%E5%8D%94%E5%8A%9B%E8%80%85) 25 | - [FAQ](#faq) 26 | - [過去の DNS Flag Day](#%E9%81%8E%E5%8E%BB%E3%81%AE-dns-flag-day) 27 | 28 | 次回予告 29 | ======== 30 | 31 | 次回の DNS Flag Day は、 2020 年 10 月 1 日に予定されています。 32 | その内容は、 IP パケットのフラグメンテーション (fragmentation) が引き起こす、 33 | 運用上のまたはセキュリティの問題に特化したものになる予定です。 34 | 35 | 問題点、 2020 年 10 月 1 日に予定されている技術的な変更、そして予定日の前にあなたのシステムをテストする方法の全般的な説明が本ページに掲載されています。 36 | 37 | 計画に関する重要な変更については [dns-announce メーリングリスト](https://lists.dns-oarc.net/mailman/listinfo/dns-announce) (英語) を購読する、 38 | または [Twitter の @dnsflagday](https://www.twitter.com/dnsflagday) (英語) をフォローすることで受け取ることができます。 39 | 40 | 確定した日付 41 | ============ 42 | 43 | **2020 年 10 月 1 日** 44 | 45 | DNS Flag Day 2020 46 | ================= 47 | 48 | DNS コミュニティは、相互運用性を持続させ、性能に影響を与える問題を解消するために議論を行っています。 49 | これは業界のメーリングリストや、 [DNS-OARC 30](https://www.dns-oarc.net/oarc30) のパネルディスカッション 50 | ([セッションの録画](https://youtu.be/mH_elg9EUWw?t=680) (英語) と 51 | [発表資料](https://indico.dns-oarc.net/event/31/contributions/678/attachments/673/1102/dns_flag_day_panel.pdf) (英語)) 52 | といったカンファレンスで行われています。 53 | 54 | DNS Flag Day 2020 の計画に関する提案は、 2019 年 10 月に 55 | [RIPE78](https://ripe78.ripe.net) にて CZ.NIC の Petr Špaček 氏と ISC の Ondřej Surý 氏から行われました。 56 | ([セッションの録画](https://ripe78.ripe.net/archives/video/28) (英語) と 57 | [発表資料](https://ripe78.ripe.net/presentations/53-plenary.pdf) (英語)) 58 | この年は、 IP フラグメンテーションが引き起こす問題にフォーカスします。 59 | 60 | IP フラグメンテーションは、現在のインターネットでは正しく動作するか信頼できないものです。 61 | また、 UDP で 大きなサイズの DNS メッセージが送信された際に、転送の失敗を引き起こす原因になりえます。 62 | たとえ IP フラグメンテーションが正しく動作したとしても、セキュリティの面では不十分でしょう。 63 | なぜなら、フラグメントされた DNS メッセージの *一部* を偽装することは理論的に可能であり、 64 | 受信側で簡単にそれを検知する方法はないからです。 65 | - Bonica R. et al, "[IP Fragmentation Considered Fragile](https://tools.ietf.org/html/draft-bonica-intarea-frag-fragile)", Work in Progress, July 2018 66 | - Huston G., "[IPv6, Large UDP Packets and the DNS](https://www.potaroo.net/ispcol/2017-08/xtn-hdrs.html)", August 2017 67 | - Fujiwara K., "[Measures against cache poisoning attacks using IP fragmentation in DNS](https://indico.dns-oarc.net/event/31/contributions/692/)", May 2019 68 | - Fujiwara K. et al, "[Avoid IP fragmentation in DNS](https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation)", September 2019 69 | 70 | 最近、 Axel Koolhaas 氏 と Tjeerd Slokker 氏 によって発表された論文とプレゼンテーション 71 | [Defragmenting DNS - Determining the optimal maximum UDP response size for DNS 72 | ](https://indico.dns-oarc.net/event/36/contributions/776/) では、 NLnet Labs と共同で 73 | RIPE Atlas のプローブを利用して現実世界のデータが調査されました。 74 | その結果として、 IPv4 と IPv6 で、またシナリオ (訳注: スタブリゾルバーとフルサービスリゾルバー) 75 | によって異なる値が提案されています。 76 | 環境に応じた値に設定することは、環境を把握している運用者にとっては現実的なことですので、 77 | DNS ソフトウェアのデフォルト値としては、最小で安全なサイズである **1232** を反映するべきでしょう。 78 | 79 | これらの問題を解決するには、下記の全てを行う必要があります。 80 | a) UDP で送信する DNS メッセージについて、一般的なネットワークリンクでフラグメンテーションが起きないようなサイズに制限するようサーバーを設定する 81 | b) DNS 応答のサイズが大きく、前述の制限したバッファーサイズを超えてしまう場合には、 DNS サーバーで UDP から TCP に切り替えられるようにする 82 | 83 | メッセージサイズに関する検討 84 | ---------------------------- 85 | 86 | IP フラグメンテーションを避けつつ TCP をなるべく使わないような DNS メッセージサイズの最適値は、 87 | ネットワークのエンドポイント同士をつなぐ物理的なリンクの最大転送単位 (Maximum Transmission Unit: MTU) に依存するでしょう。 88 | 残念なことに、 DNS サーバーソフトウェアの実装者がその情報にアクセスできる標準的な仕組みはまだありません。 89 | 標準的な仕組みが提供されるようになるまでは、 90 | EDNS バッファーサイズが現在の一般的なネットワークリンクでフラグメンテーションを引き起こさないよう十分に小さなサイズに 91 | _デフォルトで_ 設定されていることを推奨します。 92 | 93 | 1232 バイトの EDNS バッファーサイズは、現在のほぼすべてのネットワークにおいてフラグメンテーションを回避することができます。 94 | この値は IPv6 の仕様で必須とされている 1280 バイトの MTU 値に基づいていて、さらに IPv6 ヘッダーと UDP ヘッダーのために 95 | 48 バイトを引いた値です。そして、前述の調査結果にも基づいています。 96 | 97 | この推奨値は、より良い情報が得られない場合の _デフォルトの_ 値に関するものであることに留意してください。 98 | 運用者の方は、管理しているネットワークがより大きなデータフレームをサポートしていて、 99 | IP フラグメンテーションのリスクがないことが確実であれば、より大きな値を設定しても構いません。 100 | DNS サーバーのベンダーは、カーネルから MTU に関するより良い情報を得られる場合には、 101 | より大きな(または、より小さな)パケットサイズを使っても構いません。 102 | 103 | 対応: 権威DNSサーバーのオペレーター 104 | ----------------------------------- 105 | 106 | 権威DNSサーバーの運用者の方は、サーバーが TCP (53 番ポート) での DNS 問い合わせにも応答できるようにすることで、 107 | 対応することができます。 TCP/53 をブロックする製品もありますので、 _ファイアウォールも忘れずに確認してください_ 。 108 | 109 | 加えて、 EDNS バッファーサイズをフラグメンテーションを引き起こさないサイズにネゴシエートするように、 110 | サーバーを設定することも行うべきです。 111 | ここでの推奨値は 1232 バイトです。 112 | 113 | _権威DNSサーバーは、問い合わせで指定された EDNS バッファーサイズを超える大きさで応答 114 | **してはいけません**!_ 115 | 116 | お持ちのドメインを下記に入力して "テスト!" をクリックすることで、サーバーを確認することができます。 117 | このテストは [ISC の EDNS Compliance Tester](https://ednscomp.isc.org/) 118 | を内部で使っていて、それに含まれる `edns512udp` テストが成功するかを確認しています。 119 | 加えて、他のテストで一般的に標準規格に準拠していることを確認しています。 120 | 121 | {% include 2020_checker.html lang=site.data.2020_checker.ja %} 122 | 123 | 対応: フルサービスリゾルバーのオペレーター 124 | ------------------------------------------ 125 | 126 | フルサービスリゾルバー (キャッシュ DNS サーバー) 側でも、権威 DNS サーバーで求められていることと同じです。 127 | TCP (53 番ポート) での DNS 問い合わせにも応答すること、そしてフラグメンテーションされないように 128 | EDNS バッファーサイズとして 1232 バイトを設定してください。 129 | TCP の DNS に問題がないよう、ファイアウォールも忘れずに確認してください。 130 | 131 | そして、これが最も大切なことですが、 132 | _フルサービスリゾルバーが切り詰められた UDP 応答 (TC=1 がセットされたもの) を受け取った場合、 133 | TCP で再度問い合わせを行わなければ **なりません**_! 134 | 135 | **最新情報!** このチェッカーは、お使いのブラウザー・システム・ ISP のフルサービスリゾルバーをテストします。 136 | テスト用の権威 DNS サーバーに直接問い合わせるフルサービスリゾルバーが TCP をサポートしている時にだけ名前解決できる 137 | URL の画像を読み込むことで確認します。 138 | 詳細は、このチェッカーが利用している [Check My DNS](https://cmdns.dev.dns-oarc.net) (英語) をご覧ください。 139 | 140 | {% include 2020_cli_checker.html lang=site.data.2020_checker.ja %} 141 | 142 | 対応: DNS ソフトウェア製品のベンダー 143 | ------------------------------------ 144 | 145 | DNS ソフトウェア製品のベンダーとしては、 *標準規格に準拠する* ことが重要です。 146 | また、一般的なネットワークリンクでフラグメンテーションされないような EDNS バッファーサイズのデフォルト値 147 | (1232 バイト) を設定することも重要です。 148 | 149 | 関連する標準規格は 150 | [RFC 7766](https://tools.ietf.org/html/rfc7766) 、 151 | [RFC 6891 section 6.2.3.](https://tools.ietf.org/html/rfc6891#section-6.2.3) 、そして 152 | [RFC 6891 section 6.2.4.](https://tools.ietf.org/html/rfc6891#section-6.2.4) などがあります。 153 | 154 | この試みの動機については、 155 | [IETF のインターネットドラフト intarea-frag-fragile section 6.1](https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-10#section-6.1) と 156 | [IETF のインターネットドラフト iab-protocol-maintenance](https://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/) 157 | にて解説されています。 158 | 159 | テスト方法 160 | ---------- 161 | 162 | ドメインの管理者の方、または権威 DNS サーバーの管理者の方は、 163 | ドメインをテストする Web ベースのツールが公開されています。 164 | [対応: 権威DNSサーバーのオペレーター](#%E5%AF%BE%E5%BF%9C-%E6%A8%A9%E5%A8%81dns%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%81%AE%E3%82%AA%E3%83%9A%E3%83%AC%E3%83%BC%E3%82%BF%E3%83%BC) を参照してください。 165 | 166 | クライアントやフルサービスリゾルバーの運用者のための Web ベースのテストツールは、 167 | [対応: フルサービスリゾルバーのオペレーター](#%E5%AF%BE%E5%BF%9C-%E3%83%95%E3%83%AB%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%83%AA%E3%82%BE%E3%83%AB%E3%83%90%E3%83%BC%E3%81%AE%E3%82%AA%E3%83%9A%E3%83%AC%E3%83%BC%E3%82%BF%E3%83%BC) を参照してください。 168 | 169 | 他の方法として、コンソールで下記のコマンドを入力することでもテストできます: 170 | 171 | ```shell 172 | $ dig +tcp @auth_IP yourdomain.example. 173 | $ dig +tcp @resolver_IP yourdomain.example. 174 | $ dig @resolver_IP test.knot-resolver.cz. TXT 175 | ``` 176 | 177 | 上記の DNS 問い合わせはすべて成功するはずです。 178 | また `+tcp` というオプションなしでコマンドを実行したときと同じ応答が返ってくるはずです。 179 | 180 | DNS サービスの提供者の方は、権威 DNS サーバーやフルサービスリゾルバーを下記のように 181 | EDNS バッファーサイズのデフォルト値を変更してテストすることができます: 182 | 183 | - BIND 184 | ``` 185 | options { 186 | edns-udp-size 1232; 187 | max-udp-size 1232; 188 | }; 189 | ``` 190 | 191 | - Knot DNS 192 | ``` 193 | server: 194 | max-udp-payload: 1232 195 | ``` 196 | 197 | - Knot Resolver 198 | ``` 199 | net.bufsize(1232) 200 | ``` 201 | 202 | - PowerDNS Authoritative 203 | ``` 204 | udp-truncation-threshold=1232 205 | ``` 206 | 207 | - PowerDNS Recursor 208 | ``` 209 | edns-outgoing-bufsize=1232 210 | udp-truncation-threshold=1232 211 | ``` 212 | 213 | - Unbound 214 | ``` 215 | server: 216 | edns-buffer-size: 1232 217 | ``` 218 | 219 | - NSD 220 | ``` 221 | server: 222 | ipv4-edns-size: 1232 223 | ipv6-edns-size: 1232 224 | ``` 225 | 226 | 変更前に何の問題もなくサービスできていれば、上記の設定変更を適用しても影響はありません。 227 | TCP で応答していない場合には、一部の問い合わせが失敗するようになるでしょう。 228 | 229 | 誰が行っているの? 230 | ================= 231 | 232 | DNS Flag Day の試みは、 DNS のソフトウェアやサービスの提供者からなるコミュニティによって主導されています。 233 | また、 [The DNS Operations, Analysis, and Research Center (DNS-OARC)](https://www.dns-oarc.net/) からサポートを受けています。 234 | 前述のコミュニティのほとんどは DNS-OARC のメンバーでもあります。 235 | 236 | DNS Flag Day に関する技術的な質問については、 237 | [dns-operations メーリングリスト](https://lists.dns-oarc.net/mailman/listinfo/dns-operations) (英語) 238 | を購読してください。 239 | 240 | 最新情報を得る 241 | ============== 242 | 243 | 報道関係のお問い合わせについては、 media (at) dns-oarc.net にご連絡ください (英語) 。 244 | 件名に "DNS Flag Day" を含めてください。 245 | 246 | - Web: 247 | - Twitter: 248 | - Announcements: 249 | - Discussion: 250 | 251 | 協力者 252 | ====== 253 | 254 | {% include 2020_supporters.html %} 255 | 256 | FAQ 257 | === 258 | 259 | - 質問: [RFC 7766](https://tools.ietf.org/html/rfc7766) が長すぎて読めません。 260 | 261 | 回答: 一言で: DNS は TCP でも動作 **すべきです**! 262 | 263 | - 質問: UDP での DNS はもう使われないのですか? 264 | 265 | 回答: いいえ。 UDP での DNS 問い合わせは、スケーラビリティがあること、要求されるリソース量が少ないこと、 266 | 耐障害性の観点から、引き続き主流のままでしょう。 267 | 268 | - 質問: 2020 年 10 月 1 日に、全てが動かなくなるのですか? 269 | 270 | 回答: いいえ! 最新の計測調査では、影響を受けるサイトの数は [ほんの一握り](https://github.com/dns-violations/dnsflagday/issues/139#issuecomment-673489183) (英語) です。 271 | DNS Flag Day 2020 の当日に、 DNS ソフトウェア製品のベンダーは新しいリリースの際に、 272 | UDP でのメッセージサイズのデフォルト値を 1232 バイトとするようにデフォルトの挙動を変更するでしょう。 273 | そのような新しい製品が普及すると、 1232 バイトよりも大きな DNS 応答を返すものの TCP での 274 | DNS に応答しないサイトについては、名前解決に失敗するでしょう。 275 | そのようなサイトは現時点でも信頼できないことに留意してください。 276 | 277 | - 質問: なぜ TCP サポートが重要なのですか? 278 | 279 | 回答: TCP をブロックしていたり、 TCP のサポートに誤りがあったりすると、 280 | 名前解決に失敗し、アプリケーションのレベルでタイムアウトが起こるでしょう。 281 | 282 | さらに、通常 TCP は経路MTU探索 (Path MTU Discovery) を実装しています。 283 | これにより、 TCP セグメントのフラグメンテーションを回避するようになっています。 284 | また、 TCP により DNS 応答を偽装するのが困難になります。 285 | 286 | TCP のサポートは最初期の標準規格から推奨されていました。 287 | しかしながら、実装者によっては TCP を任意であるとみなしていました。 288 | 2010 年 8 月に公開された 289 | [RFC 5966](https://tools.ietf.org/html/rfc5966) によって、インターネットにおける 290 | DNS の標準規格に準拠するには TCP のサポートが必須であることが明確化されました。 291 | 292 | - 質問: なぜ TCP だけ使うようにしないのですか? 293 | 294 | 回答: UDP の DNS は、 IP フラグメンテーションが必要ないくらい小さなパケットに適しています。 295 | インターネット上でやりとりされる DNS メッセージの多くはそのような小さなサイズであり、 296 | 現在でも UDP が使われています。 297 | DNS の全てを TCP に移行するとなると、多くの DNS サービスに負荷がかかる可能性があります。 298 | 原理的には DNS で TCP だけ使うことは実現可能でしょうが、 UDP よりも遅くなります。 299 | 少なくとも 4 倍ほど遅くなるという研究結果 300 | (Baptiste Jonglez 氏による 301 | [RIPE76 でのプレゼンテーション](https://ripe76.ripe.net/archives/video/63/) (英語)) 302 | もあります。 303 | これに加えて、 DNS サーバーが同時に処理できる接続数に制限が加わってしまう可能性もあります。 304 | 305 | - 質問: 将来的に、もっと大きなパケットサイズを使いたくなった場合はどうするのですか? 306 | 307 | 回答: 我々のゴールは、現在の一般的なネットワークリンクで問題なく動くように EDNS バッファーサイズの 308 | _デフォルト_ を選ぶことで、 IP フラグメンテーションの問題を回避することです。 309 | これは、どの DNS の仕様に対しても恒久的な変更を加えるものではありません。 310 | デフォルト値は、より良い情報が得られるようになった時点でいつでもローカルで変更可能です。 311 | カーネルから MTU に関する情報を取得する標準的な方法が利用可能になれば、 312 | それを使うようにすることもできます。 313 | 314 | - 質問: 今回の DNS Flag Day に対応するためには、ソフトウェアを更新する必要があるのでしょうか? 315 | 316 | 回答: ほとんどの場合、ソフトウェアの更新は必要ありません。 317 | 発行されている標準規格に準拠している DNS ソフトウェア製品については、 318 | 更新することなく動き続けるでしょう。 319 | メジャーな OSS の DNS ソフトウェア製品でサポートされているバージョンであれば、 320 | 現在も、そして将来も問題ないでしょう。 321 | それらの製品については、デフォルト値が古い値のまま更新されていなかったとしても、 322 | EDNS バッファーサイズの推奨値を使うよう設定することができます。 323 | 324 | - 質問: DNS での TCP サポートは、本当に必須なのですか? 325 | 326 | 回答: はい、必須です。 [RFC 1035](https://tools.ietf.org/html/rfc1035) の 327 | Section 4.2 Transport にて、 UDP と TCP は同等に扱うと明示的に記載されています。 328 | さらに、 [RFC 7766](https://tools.ietf.org/html/rfc7766) では 329 | DNS での TCP サポートを必須として、 DNS ソフトウェア製品のベンダーに要求しています。 330 | DNS サービスを TCP の 53 番ポートで受け付けるかどうかは各オペレーターの 331 | 裁量の範囲です。しかしながら、 TCP をサポートしていない場合には、 332 | クライアントの EDNS バッファーサイズを超える応答に関して、名前解決が 333 | 失敗することになるでしょう。 334 | 335 | - 質問: DNS Flag Day 2020 の協力者になりたいのですが、何をしたらいいですか? 336 | 337 | 回答: ありがとうございます! 338 | [プルリクエスト](https://github.com/dns-violations/dnsflagday/pulls) 339 | を送って名前や画像、 URL を DNS Flag Day 2020 の協力者として 340 | `_data/2020_supporters.yml` に追加することができます。 341 | プルリクエストの代わりに、 [Issue](https://github.com/dns-violations/dnsflagday/issues/new) 342 | を作成して同じ情報を送っていただくこともできます。 343 | 344 | 過去の DNS Flag Day 345 | =================== 346 | 347 | 過去に行われた DNS Flag Day のリストは下記の通りです: 348 | - [2019 EDNS workarounds](/2019/) 349 | 350 | [2019 DNS Flag Day](/2019/) は成功裏に終わりました。 351 | 名前解決に時間がかかるなどの世界中のインターネット利用者に影響を及ぼす問題に対して、 352 | インターネットコミュニティの参加者は連携して解決に当たりました。 353 | インターネットをより良くするために協調して尽力した全てのオペレーターに対して謝意を表します。 354 | 355 | 過去に行われた、または将来行われる予定の DNS Flag Day の概要はこの動画などで確認できます。 356 | [https://youtu.be/mH_elg9EUWw?t=649](https://youtu.be/mH_elg9EUWw?t=649) (英語) 357 | -------------------------------------------------------------------------------- /2020/index-zh-CN.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 2020 3 | lang: zh-CN 4 | redirect_from: 5 | - /zh-CN/ 6 | - /2020/zh-CN/ 7 | flagdayyear: 2020 8 | --- 9 | 10 | {% include 2020_languages.html %} 11 | 12 | 13 | 14 | 感谢！ 15 | ========== 16 | 17 | 2019年DNS Flag Day是一个非常成功的活动。互联网社区共同努力解决了一系列带给全球互联网用户 18 | 延迟和其他故障的问题。我们要感谢所有合作的运营者，是他们帮助互联网变得更好。 19 | 20 | DNS Flag Day过去的总结和未来计划请参考： https://youtu.be/mH_elg9EUWw?t=649. 21 | 22 | 目录 23 | ======== 24 | - [下一步的计划？](#下一步的计划) 25 | - [DNS Flag Day 2020](#dns-flag-day-2020) 26 | - [注: 在开展的工作](#注-在开展的工作) 27 | - [行动: 权威DNS运营者](#行动-权威DNS运营者) 28 | - [行动: 递归DNS运营者](#行动-递归DNS运营者) 29 | - [行动: DNS软件供应商](#行动-DNS软件供应商) 30 | - [如何测试?](#如何测试) 31 | - [以前的 flag days](#以前的-flag-days) 32 | - [谁在推动 DNS flag day?](#谁在推动-dns-flag-day) 33 | - [联系我们](#联系我们) 34 | - [支持者](#支持者) 35 | - [常见问题](#常见问题) 36 | 37 | 下一步的计划？ 38 | ============ 39 | 40 | 下一步的DNS flag day的计划正在制定中. 它将聚焦由IP报文分片导致的DNS的运营和安全的问题。 41 | 42 | 为了获得及时的信息推送，请订阅 [dns-announce邮件列表](https://lists.dns-oarc.net/mailman/listinfo/dns-announce) 43 | 或者关注 [Twitter账号 @dnsflagday](https://www.twitter.com/dnsflagday) 44 | 45 | 46 | DNS Flag Day 2020 47 | ================= 48 | 49 | DNS社群一直在行业邮件列表和会议中讨论DNS持续的互操作性与系统性能问题，例如 50 | [DNS-OARC 30](https://www.dns-oarc.net/oarc30)， 专题讨论会 ([video](https://youtu.be/mH_elg9EUWw?t=680), 51 | [slides](https://indico.dns-oarc.net/event/31/contributions/678/attachments/673/1102/dns_flag_day_panel.pdf)). 52 | 53 | 2020 DNS Flag Day计划建议稿在[RIPE78](https://ripe78.ripe.net) 会议期间由 CZ.NIC的Petr Špaček, 和ISC的Ondřej Surý发布 54 | ([video](https://ripe78.ripe.net/archives/video/28)，[slides](https://ripe78.ripe.net/presentations/53-plenary.pdf)). 55 | 这一次我们要聚焦在DNS报文的IP分片问题上。 56 | 57 | IP分片是一个当前互联网存在的问题，尤其是当DNS应答消息比较大的时候。 即使IP分片工作正常，它对DNS来说也可能不够安全。 58 | 59 | 请参考： 60 | - Bonica R. et al, "[IP Fragmentation Considered Fragile](https://tools.ietf.org/html/draft-bonica-intarea-frag-fragile)", Work in Progress, July 2018 61 | - Huston G., "[IPv6, Large UDP Packets and the DNS](https://www.potaroo.net/ispcol/2017-08/xtn-hdrs.html)", August 2017 62 | - Fujiwara K., "[Measures against cache poisoning attacks using IP fragmentation in DNS](https://indico.dns-oarc.net/event/31/contributions/692/)", May 2019 63 | 64 | 这些问题的解决方法是通过设置一个固定的EDNS buffer size (缓冲区大小)，使其不会导致IP层分片。 65 | 当有DNS大包超过这个缓冲区大小的时候，DNS将会从UDP模式切换到TCP传输（通过设置应答包的TC位） 66 | 67 | 68 | 注: 在开展的工作 69 | ---------------------- 70 | 71 | 这个网站和2020 DNS Flag Day的一些工作还在开展中（尚未确定）。 72 | - 2020 DNS Flag Day 的准确时间还没有确定 73 | 74 | 然而，技术需求已经足够清晰，运营者和开发者可以开始准备测试和改动他们的系统。 75 | 76 | 如果你对此有评论或建议，请参加[dns-operations](https://lists.dns-oarc.net/mailman/listinfo/dns-operations) 邮件列表的讨论. 77 | 78 | 行动: 权威DNS运营者 79 | ----------------------------------- 80 | 81 | 对于权威侧来说，需要你帮助做的是应答DNS over TCP的查询（53端口）。同时检查你的防火墙！ 82 | 83 | 你也应该使用一个固定的EDNS 缓冲区大小，那样就不会造成分片。这里建议采用大概1232字节，但是这个取值仍然在讨论中。 84 | 85 | 最后，权威DNS服务器**不可以**发送超过查询报文中请求的EDNS 缓冲区大小的报文! 86 | 87 | 现在你可以测试检查你的域名了！通过在下面输入你的域名，然后按Test! 这个测试使用了[ISC的EDNS合规性测试器](https://ednscomp.isc.org/)，它会从所有通用合规性测试例中选择`edns512tcp` 来测试。 88 | 89 | {% include 2020_checker.html lang=site.data.2020_checker.cn %} 90 | 91 | 行动: 递归DNS运营者 92 | ------------------------------ 93 | 94 | 对递归解析测来说，或多或少与权威的要求类似，即能够通过TCP(53端口)应答DNS查询，用固定的EDNS 缓冲区大小 (大概1232字节)从而避免IP分片。记得要检查你的防火墙。 95 | 96 | 最重要的是，递归解析服务器**必须**要通过TCP重复查询，如果他们收到一个被截断的UDP应答报文（TC被设置为1）！ 97 | 98 | **NEW!** This checker will test your browser, system and ISPs resolver by 99 | loading an image on a specific URL that can only be looked up if there is 100 | support for TCP at the last resolver querying the authority. For more 101 | information go to [Check My DNS](https://cmdns.dev.dns-oarc.net) which this 102 | checker uses. 103 | 104 | {% include 2020_cli_checker.html lang=site.data.2020_checker.cn %} 105 | 106 | 行动: DNS软件供应商 107 | ---------------------------- 108 | 109 | 对DNS软件供应商重要的一点就是要**符合标准**，采用 **EDNS 缓冲区大小默认值** （~ 1232字节），这样就不会造成分片。 110 | 111 | 相关重要的标准主要是[RFC 7766](https://tools.ietf.org/html/rfc7766), 112 | [RFC 6891 section 6.2.3.](https://tools.ietf.org/html/rfc6891#section-6.2.3) 113 | 和 [RFC 6891 section 6.2.4.](https://tools.ietf.org/html/rfc6891#section-6.2.4). 114 | 115 | 这一改动的动机记录在[IETF草案 intarea-frag-fragile section 6.1](https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-10#section-6.1) 和 [IETF草案 iab-protocol-maintenance](https://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/). 116 | 117 | 如何测试？ 118 | ------------ 119 | 120 | 如果你是一个域名的所有者，或者是权威DNS服务器运营者，你可以用我们基于网页的测试工具来检查一个域名，你可以在[“行动: 权威DNS运营者”](#行动-权威DNS运营者) 中找到。 121 | 122 | 我也在开发针对客户端和DNS递归运营者的一套基于网页的测试工具。一旦准备好，你就可以在这个页面找到它。 123 | 124 | 你也可以通过下面的CLI命令行来测试： 125 | 126 | ```shell 127 | $ dig +tcp @auth_IP yourdomain.example. 128 | $ dig +tcp @resolver_IP yourdomain.example. 129 | $ dig @resolver_IP test.knot-resolver.cz. TXT 130 | ``` 131 | 无论是否使用‘+tcp’选项,所有的DNS查询必须是成功的。如果你是一项业务的提供商，你也可以通过允许DNS支持TCP，以及改变下面默认的EDNS 缓冲区大小的配置来测试你的权威和递归服务。 132 | 133 | - BIND 134 | ``` 135 | options { 136 | edns-udp-size 1232; 137 | max-udp-size 1232; 138 | }; 139 | ``` 140 | 141 | - Knot DNS 142 | ``` 143 | server: 144 | max-udp-payload: 1232 145 | ``` 146 | 147 | - Knot Resolver 148 | ``` 149 | net.bufsize(1232) 150 | ``` 151 | 152 | - PowerDNS Authoritative 153 | ``` 154 | udp-truncation-threshold=1232 155 | ``` 156 | 157 | - PowerDNS Recursor 158 | ``` 159 | edns-outgoing-bufsize=1232 160 | udp-truncation-threshold=1232 161 | ``` 162 | 163 | - Unbound 164 | ``` 165 | server: 166 | edns-buffer-size: 1232 167 | ``` 168 | 169 | - NSD 170 | ``` 171 | server: 172 | ipv4-edns-size: 1232 173 | ipv6-edns-size: 1232 174 | ``` 175 | 176 | 如果一切工作正常（支持TCP），以上的配置不会有明显的影响。如果递归或者权威不支持TCP，一些查询就会失败。 177 | 178 | 以前的 flag days 179 | ================== 180 | 181 | 下面是以前的Flag day活动列表： 182 | - [2019 EDNS workarounds](/2019/) 183 | 184 | 谁在推动 DNS flag day? 185 | ========================== 186 | 187 | DNS Flag Day的倡议活动由DNS软件和服务提供者社群发起，该活动也得到了[DNS-OARC](https://www.dns-oarc.net/)的支持（OARC的会员大部分都在这个社群内）。 188 | 189 | 如果你有围绕DNS Flag Day相关的技术的问题，你可以参与[DNS-operations邮件列表](https://lists.dns-oarc.net/mailman/listinfo/dns-operations)来向他们提问. 190 | 191 | 联系我们 192 | ============ 193 | 194 | 新闻与媒体的问题请发信给 media (at) dns-oarc.net, 请将“DNS Flag Day” 填入邮件的主题栏。 注：邮箱(at)替换成@ 195 | 196 | - Web: 197 | - Twitter: 198 | - Announcements: 199 | - Discussion: 200 | 201 | 支持者 202 | ========== 203 | 204 | {% include 2020_supporters.html %} 205 | 206 | 常见问题 207 | ====== 208 | 209 | - Q: 是不是DNS over UDP要消失绝迹了? 210 | 211 | A: 不，UDP 将仍然是主要的DNS传输协议, 因为它大规模的可扩展性，很高资源效率和容错特性。 212 | 213 | - Q: 能一句话解释[RFC 7766](https://tools.ietf.org/html/rfc7766)么？ 214 | 215 | A: DNS**必须**能在TCP上工作! 216 | 217 | - Q: 在2020即将发布的那一天，所有的通信都会出故障么？ 218 | 219 | A: 当然不是所有！只有少量的站点会受影响，而且这个数量会逐步减少当运营者开始修补他们的系统。 220 | 在即将发布的那一天，主要的DNS递归解析运营者将停止接受错误的、违反标准的行为，所以这个 221 | 改变不会影响那些符合标准的站点。另外，在发布的那一天软件供应商只在新版DNS软件中改变行为， 222 | 所以这个改变只会逐渐的影响到那些运营自己DNS递归解析服务的人。（翻译解释：新版DNS软件的推广和应用 223 | 需要一段时间，作为缓冲） 224 | 225 | - Q: 为什么支持TCP（对DNS）这么重要？ 226 | 227 | A: 阻断TCP通信或者不能支持TCP可能会造成解析失效和应用层的超时。 228 | 229 | 另外TCP通常实现了路径MTU检测，能够避免TCP分段在IP层分片。采用TCP也能够增加DNS应答欺骗的难度。 230 | 231 | 最后一点，早期的DNS标准中是建议“支持TCP”，但是一些软件开发人员当作TCP是可选项，所以大概10年之后 232 | （2010年8月）[RFC 5966](https://tools.ietf.org/html/rfc5966)明确要求为了符合DNS的Internet标准， 233 | TCP支持是绝对必要的。 234 | 235 | 236 | - Q: 为什么不直接切换到纯TCP（放弃UDP）? 237 | 238 | A: DNS通过UDP传输特别适合小数据包，而且不需要IP分片，因此这类DNS数据包仍然会 239 | 采用UDP的传输，而且它们将占据大部分互联网DNS流量。切换所有的DNS流量到TCP 240 | 会给DNS服务带来压力。虽然原则上采用TCP的DNS是可行的，但它比采用UDP的DNS慢4倍 241 | （根据一项Baptiste Jonglez的工作，[发表在RIPE76会议](https://ripe76.ripe.net/archives/video/63/)），因此他会限制DNS服务器能接受的并发连接的数量。 242 | 243 | 244 | - Q: 将来Flag Day是否需要一个软件更新? 245 | 246 | A: 符合标准的DNS软件不需要软件升级，能够继续正常工作。比如，支持主要的开源软件的 247 | DNS服务器将会工作的很好 248 | 249 | 特定部署是否兼容取决于软件的配置方式，以及该站点使用的防火墙配置。不太常用的定制 250 | 或专有DNS软件可能不兼容，可能需要更新。 251 | 252 | 253 | - Q: DNS对TCP传输的要求是DNS标准么？ 254 | 255 | A: 是的，是标准的要求。[RFC 1035](https://tools.ietf.org/html/rfc1035)的4.2节 256 | 明确列出了UDP和TCP传输是同等要求的。此外 [RFC 7766](https://tools.ietf.org/html/rfc7766) 257 | 强制要求DNS软件提供商支持DNS TCP. 虽然是否允许TCP 53端口流量是由网络运营者决定的， 258 | 但是如果当DNS应答数据包大于客户端选择的EDNS 缓冲区大小，无法通过TCP响应可能导致DNS 259 | 解析失败。（翻译注:这种情况权威服务器将设置TC，要求Resolver用TCP重新发起请求） 260 | 261 | - Q: 我想要支持2020 DNS Flag Day，我应该怎么做? 262 | 263 | A: 太好了！你可以把自己添加到支持者列表中。请生成过一个[合并请求](https://github.com/dns-violations/dnsflagday/pulls), 264 | 增加你的名字，图标，和URL到 `_data/2020_supporters.yml`, 265 | 或者通过添加一个[问题描述](https://github.com/dns-violations/dnsflagday/issues/new) 提供这些信息。 266 | -------------------------------------------------------------------------------- /2020/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: 2020 3 | lang: en-US 4 | redirect_from: 5 | - / 6 | - /en/ 7 | - /ru/ 8 | - /pt-br/ 9 | - /de/ 10 | - /cs/ 11 | - /2020/en/ 12 | - /2020/ru/ 13 | - /2020/pt-br/ 14 | - /2020/de/ 15 | - /2020/cs/ 16 | flagdayyear: 2020 17 | --- 18 | 19 | {% include 2020_languages.html %} 20 | 21 | 22 | 23 | Contents 24 | ======== 25 | - [What's next?](#whats-next) 26 | - [DNS Flag Day 2020](#dns-flag-day-2020) 27 | - [Action: Authoritative DNS Operators](#action-authoritative-dns-operators) 28 | - [Action: DNS Resolver Operators](#action-dns-resolver-operators) 29 | - [Action: DNS software vendors](#action-dns-software-vendors) 30 | - [How to test?](#how-to-test) 31 | - [Who's behind DNS Flag Day?](#whos-behind-dns-flag-day) 32 | - [Get in touch](#get-in-touch) 33 | - [Supporters](#supporters) 34 | - [FAQ](#faq) 35 | - [Previous DNS Flag Days](#previous-dns-flag-days) 36 | 37 | What's next? 38 | ============ 39 | 40 | The next DNS Flag Day is scheduled for 2020-10-01. It focuses on the 41 | operational and security problems in DNS caused by Internet Protocol 42 | packet fragmentation. 43 | 44 | On this page you can find comprehensive description of the problem, 45 | technical changes planned for 2020-10-01, and ways to test your systems 46 | before the set date. 47 | 48 | You can also subscribe to 49 | [the dns-announce mailing list](https://lists.dns-oarc.net/mailman/listinfo/dns-announce) 50 | or follow [@dnsflagday on Twitter](https://www.twitter.com/dnsflagday) 51 | to receive a notification about significant changes. 52 | 53 | The exact date 54 | ============== 55 | 56 | **2020-10-01** (October 1st 2020) 57 | 58 | DNS Flag Day 2020 59 | ================= 60 | 61 | The DNS community has been discussing persistent interoperability and 62 | performance issues with the DNS system on industry mailing lists and at 63 | conferences such as [DNS-OARC 30](https://www.dns-oarc.net/oarc30) panel 64 | discussion ([video](https://youtu.be/mH_elg9EUWw?t=680), 65 | [slides](https://indico.dns-oarc.net/event/31/contributions/678/attachments/673/1102/dns_flag_day_panel.pdf)). 66 | 67 | The proposed plan for DNS Flag Day 2020 was announced in October 2019 at 68 | [RIPE78](https://ripe78.ripe.net) by Petr Špaček, CZ.NIC and Ondřej Surý, 69 | ISC ([video](https://ripe78.ripe.net/archives/video/28), 70 | [slides](https://ripe78.ripe.net/presentations/53-plenary.pdf)). This 71 | year, we are focusing on problems with IP fragmentation of DNS packets. 72 | 73 | IP fragmentation is unreliable on the Internet today, and can cause 74 | transmission failures when large DNS messages are sent via UDP. Even 75 | when fragmentation does work, it may not be secure; it is theoretically 76 | possible to spoof *parts* of a fragmented DNS message, without easy 77 | detection at the receiving end. 78 | - Bonica R. et al, "[IP Fragmentation Considered Fragile](https://tools.ietf.org/html/draft-bonica-intarea-frag-fragile)", Work in Progress, July 2018 79 | - Huston G., "[IPv6, Large UDP Packets and the DNS](https://www.potaroo.net/ispcol/2017-08/xtn-hdrs.html)", August 2017 80 | - Fujiwara K., "[Measures against cache poisoning attacks using IP fragmentation in DNS](https://indico.dns-oarc.net/event/31/contributions/692/)", May 2019 81 | - Fujiwara K. et al, "[Avoid IP fragmentation in DNS](https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation)", September 2019 82 | 83 | Recently, there was an paper and presentation [Defragmenting DNS - Determining 84 | the optimal maximum UDP response size for DNS 85 | ](https://indico.dns-oarc.net/event/36/contributions/776/) by Axel Koolhaas, and 86 | Tjeerd Slokker in collaboration with NLnet Labs that explored the real world data 87 | using the RIPE Atlas probes and the researchers suggested different values for 88 | IPv4 and IPv6 and in different scenarios. This is practical for the server 89 | operators that know their environment, and the defaults in the DNS software 90 | should reflect the minimum safe size which is **1232**. 91 | 92 | These issues can be addressed by a) configuring servers to limit DNS 93 | messages sent over UDP to a size that will not trigger fragmentation on 94 | typical network links, and b) ensuring that DNS servers can switch from 95 | UDP to TCP when a DNS response is too big to fit in this limited buffer 96 | size. 97 | 98 | Message Size Considerations 99 | --------------------------- 100 | 101 | The optimum DNS message size to avoid IP fragmentation while minimizaing 102 | the use of TCP will depend on the Maximum Transmission Unit (MTU) of the 103 | physical network links connecting two network endpoints. Unfortunately, 104 | there is not yet a standard mechanism for DNS server implementors to access 105 | this information. Until such a standard exists, we recommend that the EDNS 106 | buffer size should, by _default_, be set to a value small enough to avoid 107 | fragmentation on the majority of network links in use today. 108 | 109 | An EDNS buffer size of 1232 bytes will avoid fragmentation on nearly all current 110 | networks. This is based on an MTU of 1280, which is required by the IPv6 111 | specification, minus 48 bytes for the IPv6 and UDP headers and the 112 | aforementioned research. 113 | 114 | Note that this recomendation is for a _default_ value, to be used when 115 | better information is not available. Operators may still configure larger 116 | values if their networks support larger data frames and they are certain 117 | there is no risk of IP fragmentation. DNS server vendors may use higher 118 | (or lower) packet sizes if better information about the MTU is available 119 | from the kernel. 120 | 121 | Action: Authoritative DNS Operators 122 | ----------------------------------- 123 | 124 | If you are an authoritative DNS server operator, what you should do to help 125 | with these issues is ensure that your DNS servers can answer DNS queries 126 | over TCP (port 53). _Check your firewall(s) as well,_ as some of them block 127 | TCP/53. 128 | 129 | You should also configure your servers to negotiate an EDNS buffer size 130 | that will not cause fragmentation. The value recommended here is 131 | 1232 bytes. 132 | 133 | _Authoritative DNS servers **MUST NOT** send answers larger than the 134 | requested EDNS buffer size!_ 135 | 136 | You can now check your servers by entering your domain name below and 137 | pressing "Test!". This tester uses 138 | [ISC's EDNS Compliance Tester](https://ednscomp.isc.org/) and will 139 | check that its `edns512tcp` test is successful, among other tests for 140 | general standards compliance. 141 | 142 | {% include 2020_checker.html lang=site.data.2020_checker.en %} 143 | 144 | Action: DNS Resolver Operators 145 | ------------------------------ 146 | 147 | Requrirements on the resolver side are more or less the same as for 148 | authoritative: ensure that your servers can answer DNS queries over TCP 149 | (port 53), and configure an EDNS buffer size of 1232 bytes to avoid 150 | fragmentation. Remember to check your firewall(s) for problems with 151 | DNS over TCP! 152 | 153 | Most importantly: _Resolvers **MUST** resend queries over TCP if they 154 | receive a truncated UDP response (with TC=1 set)!_ 155 | 156 | **NEW!** This checker will test your browser, system and ISP's resolver by 157 | loading an image on a specific URL that can only be looked up if there is 158 | support for TCP at the last resolver querying the authority. For more 159 | information, go to [Check My DNS](https://cmdns.dev.dns-oarc.net) which 160 | this checker uses. 161 | 162 | {% include 2020_cli_checker.html lang=site.data.2020_checker.en %} 163 | 164 | Action: DNS Software Vendors 165 | ---------------------------- 166 | 167 | It is important for DNS software vendors to **comply with DNS standards**, 168 | and to use a default EDNS buffer size (1232 bytes) that will not cause 169 | fragmentation on typical network links. 170 | 171 | Relevant standards include [RFC 7766](https://tools.ietf.org/html/rfc7766), 172 | [RFC 6891 section 6.2.3.](https://tools.ietf.org/html/rfc6891#section-6.2.3) 173 | and 174 | [RFC 6891 section 6.2.4.](https://tools.ietf.org/html/rfc6891#section-6.2.4). 175 | 176 | The motivation for this effort is described in 177 | [IETF draft intarea-frag-fragile section 6.1](https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-10#section-6.1) 178 | and [IETF draft iab-protocol-maintenance](https://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/). 179 | 180 | How to test? 181 | ------------ 182 | 183 | If you're the owner of a domain or the operator of an authoritative DNS 184 | server, you can use our web-based testing tool to check your domains; you 185 | can find it above under 186 | [Action: Authoritative DNS Operators](#action-authoritative-dns-operators). 187 | 188 | Our web-based testing tool for clients and DNS resolver operators can be 189 | found above under 190 | [Action: DNS Resolver Operators](#action-dns-resolver-operators). 191 | 192 | You can also test by using the following CLI commands: 193 | 194 | ```shell 195 | $ dig +tcp @auth_IP yourdomain.example. 196 | $ dig +tcp @resolver_IP yourdomain.example. 197 | $ dig @resolver_IP test.knot-resolver.cz. TXT 198 | ``` 199 | 200 | All DNS queries must be successful, and commands should return the same 201 | results both with and without the `+tcp` option. 202 | 203 | If you are a service provider, you can test your authoritative and 204 | recursive DNS services by configuring the default EDNS buffer size: 205 | 206 | - BIND 207 | ``` 208 | options { 209 | edns-udp-size 1232; 210 | max-udp-size 1232; 211 | }; 212 | ``` 213 | 214 | - Knot DNS 215 | ``` 216 | server: 217 | max-udp-payload: 1232 218 | ``` 219 | 220 | - Knot Resolver 221 | ``` 222 | net.bufsize(1232) 223 | ``` 224 | 225 | - PowerDNS Authoritative 226 | ``` 227 | udp-truncation-threshold=1232 228 | ``` 229 | 230 | - PowerDNS Recursor 231 | ``` 232 | edns-outgoing-bufsize=1232 233 | udp-truncation-threshold=1232 234 | ``` 235 | 236 | - Unbound 237 | ``` 238 | server: 239 | edns-buffer-size: 1232 240 | ``` 241 | 242 | - NSD 243 | ``` 244 | server: 245 | ipv4-edns-size: 1232 246 | ipv6-edns-size: 1232 247 | ``` 248 | 249 | The configuration above will have no visible effect if everything works 250 | correctly. Some queries will fail to resolve if the TCP transport is not 251 | available. 252 | 253 | Who's behind DNS Flag Day? 254 | ========================== 255 | 256 | The DNS Flag Day effort is community driven by DNS software and service 257 | providers, and supported by [The DNS Operations, Analysis, and Research Center (DNS-OARC)](https://www.dns-oarc.net/) 258 | which most in the community are members of. 259 | 260 | If you have technical questions about DNS Flag Day, you can join 261 | [the DNS-operations mailing list](https://lists.dns-oarc.net/mailman/listinfo/dns-operations) 262 | and ask them there. 263 | 264 | Get in touch 265 | ============ 266 | 267 | For press & media inquiries please use media (at) dns-oarc.net and please put 268 | “DNS Flag Day" in the email subject line. 269 | 270 | - Web: 271 | - Twitter: 272 | - Announcements: 273 | - Discussion: 274 | 275 | Supporters 276 | ========== 277 | 278 | {% include 2020_supporters.html %} 279 | 280 | FAQ 281 | === 282 | 283 | - Q: TL;DR [RFC 7766](https://tools.ietf.org/html/rfc7766) 284 | 285 | A: DNS **MUST** work over TCP! 286 | 287 | - Q: Is DNS over UDP dead? 288 | 289 | A: No, DNS over UDP will still be the primary mode of transmission, as it 290 | is massively scalable, very resource-efficient, and fault-tolerant. 291 | 292 | - Q: Will everything break on 2020-10-01? 293 | 294 | A: No! Latest measurements shown that only 295 | a [tiny percentage](https://github.com/dns-violations/dnsflagday/issues/139#issuecomment-673489183) 296 | of sites will be affected. On the 297 | flag day software vendors will change their default 298 | behavior in new software releases so that the default message size 299 | used over UDP will be 1232 bytes. As these new releases are 300 | deployed, sites that return DNS responses larger than 1232 bytes, 301 | but which cannot answer DNS queries via TCP, may fail to resolve. 302 | Note that these sites are already unreliable today. 303 | 304 | - Q: Why is TCP support so important? 305 | 306 | A: Blocking TCP, or failure to support TCP, may result in resolution 307 | failure and application-level timeouts. 308 | 309 | Furthermore, TCP normally implements Path MTU Discovery and can avoid 310 | IP fragmentation of TCP segments. It also makes it harder to spoof 311 | DNS responses. 312 | 313 | TCP support was recommended in the earliest DNS standard 314 | specifications. Some implementers may have taken that to mean TCP 315 | was optional, and so in August 2010 316 | [RFC 5966](https://tools.ietf.org/html/rfc5966) made it clear that TCP 317 | support is absolutely required for compliance with the Internet 318 | standards for DNS. 319 | 320 | - Q: Why not just switch to TCP only? 321 | 322 | A: DNS over UDP is fine for small packets that do not require IP 323 | fragmentation. It can still be used for that class of DNS messages, 324 | which is the majority of DNS traffic. Switching everything 325 | over to TCP may cause stress on DNS services. While in principle 326 | DNS over TCP only should be feasible, it is slower than DNS over UDP 327 | by at least a factor of 4 (based on Baptiste Jonglez work 328 | [presented at RIPE76](https://ripe76.ripe.net/archives/video/63/)), 329 | and it may limit the number of connections a DNS server can accept 330 | simultaneously. 331 | 332 | - Q: What if we want to use bigger packet sizes in the future? 333 | 334 | A: Our goal is simply to avoid IP fragmentation by choosing a _default_ 335 | EDNS buffer size that will work well on typical networks today. This 336 | is not a permanent change to any DNS specification. Default values 337 | can always be overridden locally if better information is avaialble. 338 | If a standard method for retrieving MTU data from the kernel becomes 339 | available, that can be used as well. 340 | 341 | - Q: Will DNS Flag Day 2020 require a software update? 342 | 343 | A: In most cases, no. DNS software which follows published standards does 344 | not require upgrade and will continue to work. All supported versions 345 | of major open source DNS servers work correctly now and will continue 346 | to do so. They can all be configured to use the recommended EDNS 347 | buffer sizes, even if they have not yet been updated to use those 348 | sizes by default. 349 | 350 | Whether a particular deployment is compliant depends on the way the 351 | software is configured, and on the firewall configuration used at 352 | that site. Less commonly-used and custom or proprietary DNS software 353 | may not be compliant, and may require updates. 354 | 355 | - Q: Is the requirement for DNS over TCP actually a DNS standard? 356 | 357 | A: Yes, it is. The [RFC 1035](https://tools.ietf.org/html/rfc1035) 358 | Section 4.2 Transport explicitly lists UDP and TCP transports as 359 | equals. Furthermore, [RFC 7766](https://tools.ietf.org/html/rfc7766) 360 | makes the requirement for DNS over TCP mandatory to implement for DNS 361 | vendors. While it's at operator's discretion to allow traffic on the 362 | TCP port 53, the inability to respond over TCP might lead to resolution 363 | failure in case of DNS answers bigger than EDNS buffer size chose at 364 | the client side. 365 | 366 | - Q: I want to support DNS Flag Day 2020, what do I do? 367 | 368 | A: Great to hear! You can add yourself as a supporter by making a 369 | [pull request](https://github.com/dns-violations/dnsflagday/pulls) and 370 | add name, image and URL to `_data/2020_supporters.yml`, or make 371 | an [issue](https://github.com/dns-violations/dnsflagday/issues/new) 372 | and supply the same information in that. 373 | 374 | Previous DNS Flag Days 375 | ====================== 376 | 377 | Here is a list of the previous DNS Flag Days: 378 | - [2019 EDNS workarounds](/2019/) 379 | 380 | The [2019 DNS Flag Day](/2019/) was a very successful event. The Internet 381 | community worked together and fixed problems which were causing delays and 382 | other problems for Internet users worldwide. We would like to thank all 383 | operators who cooperated and helped to make Internet a better place. 384 | 385 | Summary of the past and future DNS Flag Days can be found e.g. in 386 | [https://youtu.be/mH_elg9EUWw?t=649](https://youtu.be/mH_elg9EUWw?t=649). 387 | -------------------------------------------------------------------------------- /CNAME: -------------------------------------------------------------------------------- 1 | www.dnsflagday.net -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | [https://dnsflagday.net](https://dnsflagday.net) 2 | 3 | Thank you! 4 | ========== 5 | 6 | The [DNS flag day 2019](https://dnsflagday.net/2019/) was very successful event and the Internet community 7 | worked together and fixed problems which were causing delays and other 8 | problems for Internet users worldwide. We would like to thank to all 9 | operators who cooperated and helped to make Internet a better place. 10 | 11 | Summary of the past and future DNS flag days can be found e.g. in 12 | [https://youtu.be/mH_elg9EUWw?t=649](https://youtu.be/mH_elg9EUWw?t=649). 13 | 14 | What's next? 15 | ============ 16 | 17 | Next round of DNS flag day is being planned right now, with focus on 18 | operational and security problems in DNS caused by Internet Protocol 19 | fragmentation. 20 | 21 | Please subscribe to [mailing list dns-announce](https://lists.dns-oarc.net/mailman/listinfo/dns-announce) 22 | or follow [dnsflagday Twitter](https://www.twitter.com/dnsflagday) 23 | to receive notification when more information becomes available. 24 | 25 | DNS Flag Day 2020 26 | ================= 27 | 28 | The DNS community has been discussing persistent interoperability and 29 | performance issues with the DNS system on industry mailing lists and at 30 | conferences such as [DNS-OARC 30](https://www.dns-oarc.net/oarc30) panel 31 | discussion ([video](https://youtu.be/mH_elg9EUWw?t=680), 32 | [slides](https://indico.dns-oarc.net/event/31/contributions/678/attachments/673/1102/dns_flag_day_panel.pdf)). 33 | 34 | The proposed plan for the DNS flag day 2020 was announced at 35 | [RIPE78](https://ripe78.ripe.net) by Petr Špaček, CZ.NIC and Ondřej Surý, 36 | ISC ([video](https://ripe78.ripe.net/archives/video/28), 37 | [slides](https://ripe78.ripe.net/presentations/53-plenary.pdf)). This time, 38 | we will focus on the problems with IP fragmentation of DNS packets. 39 | 40 | Please see https://dnsflagday.net/2020/ for more information. 41 | 42 | Who's behind DNS flag day? 43 | ========================== 44 | 45 | The DNS flag day effort is community driven by DNS software and service 46 | providers, and supported by [The DNS Operations, Analysis, and Research Center (DNS-OARC)](https://www.dns-oarc.net/) 47 | which most in the community are members of. 48 | 49 | If you have technical questions around DNS flag day you can join 50 | [the DNS-operations mailing list](https://lists.dns-oarc.net/mailman/listinfo/dns-operations) 51 | and ask them there. 52 | 53 | Get in touch 54 | ============ 55 | 56 | For press & media inquiries please use media (at) dns-oarc.net and please put 57 | “DNS Flag Day" in the email subject line. 58 | 59 | - Web: 60 | - Twitter: 61 | - Announcements: 62 | - Discussion: 63 | 64 | Want to build this locally? 65 | =========================== 66 | 67 | In `Gemfile`, put: 68 | 69 | ``` 70 | source 'https://rubygems.org' 71 | gem 'github-pages', group: :jekyll_plugins 72 | 73 | ``` 74 | 75 | Then, to build (and keep building after every edit, run: 76 | 77 | ``` 78 | docker run --rm -v "$PWD:/srv/jekyll" -v "$PWD/vendor/bundle:/usr/local/bundle" -it jekyll/jekyll jekyll build --watch 79 | ``` 80 | 81 | Then, in `_site/`, run: 82 | 83 | ``` 84 | python3 -mhttp.server 85 | ``` 86 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | theme: jekyll-theme-slate 2 | title: DNS flag day 3 | plugins: 4 | - jekyll-sitemap 5 | - jekyll-redirect-from 6 | sitemap: 7 | file: "/sitemap.xml" 8 | defaults: 9 | - 10 | scope: 11 | path: "" 12 | type: "pages" 13 | values: 14 | layouts: "default" 15 | - 16 | scope: 17 | path: "2019" 18 | type: "pages" 19 | values: 20 | layouts: "default" 21 | - 22 | scope: 23 | path: "2020" 24 | type: "pages" 25 | values: 26 | layouts: "default" 27 | -------------------------------------------------------------------------------- /_data/2019_supporters.yml: -------------------------------------------------------------------------------- 1 | - name: "PowerDNS" 2 | img: "/images/powerdns.svg" 3 | url: "https://blog.powerdns.com/2018/03/22/removing-edns-workarounds/" 4 | - name: "ISC" 5 | img: "/images/isc.png" 6 | url: "https://www.isc.org/blogs/end-to-bandaids/" 7 | - name: "NLnet Labs" 8 | img: "/images/nlnetlabs.svg" 9 | url: "https://www.nlnetlabs.nl/news/2018/Jun/07/putting-an-end-to-workarounds-for-broken-software/" 10 | - name: "CZ.NIC" 11 | img: "/images/cznic.svg" 12 | url: "https://en.blog.nic.cz/2018/03/14/together-for-better-stability-speed-and-further-extensibility-of-the-dns-ecosystem/" 13 | - name: "Quad9" 14 | img: "/images/quad9.png" 15 | url: "https://quad9.net/" 16 | - name: "CleanBrowsing" 17 | img: "https://cleanbrowsing.org/images/CleanBrowsing-logo-small-dark.png" 18 | url: "https://cleanbrowsing.org/" 19 | - name: "Cloudflare" 20 | img: "/images/cloudflare.png" 21 | url: "https://www.cloudflare.com/" 22 | - name: "Cisco" 23 | img: "/images/cisco.svg" 24 | url: "https://www.opendns.com/cisco-opendns/" 25 | - name: "Google" 26 | img: "/images/google.svg" 27 | url: "https://developers.google.com/speed/public-dns/" 28 | - name: "Facebook" 29 | img: "/images/facebook.svg" 30 | url: "https://www.facebook.com/" 31 | -------------------------------------------------------------------------------- /_data/2020_supporters.yml: -------------------------------------------------------------------------------- 1 | - name: "PowerDNS" 2 | img: "/images/powerdns.svg" 3 | url: "https://www.powerdns.com/" 4 | - name: "CZ.NIC" 5 | img: "/images/cznic.svg" 6 | url: "https://www.nic.cz/" 7 | - name: "CoreDNS" 8 | img: "/images/CoreDNS_Colour_Horizontal.png" 9 | url: "https://coredns.io/" 10 | - name: "ISC" 11 | img: "/images/isc.png" 12 | url: "https://www.isc.org/" 13 | - name: "NLnet Labs" 14 | img: "/images/nlnetlabs.svg" 15 | url: "https://www.nlnetlabs.nl/" 16 | - name: "Quad9" 17 | img: "/images/quad9.png" 18 | url: "https://quad9.net/" 19 | - name: "Alibaba Cloud" 20 | img: "/images/AlibabaCloud.png" 21 | url: "https://www.alibabacloud.com/" 22 | - name: "BlueCat Networks" 23 | img: "/images/bluecat.png" 24 | url: "https://www.bluecatnetworks.com/blog/dns-flag-day-is-coming-and-bluecat-is-ready/#flagday2020" 25 | - name: "Infoblox" 26 | img: "/images/Infoblox-logo-with-tag.png" 27 | url: "https://blogs.infoblox.com/company/infoblox-is-supporting-dns-flag-day-2020/" 28 | - name: "Whalebone, s.r.o." 29 | img: "/images/whalebone.png" 30 | url: "https://whalebone.io/" 31 | - name: "Space available for the next supporter!" 32 | img: "/images/space-available.png" 33 | url: "https://dnsflagday.net" 34 | -------------------------------------------------------------------------------- /_includes/2019_checker.html: -------------------------------------------------------------------------------- 1 |
2 |
3 |
4 | {{ include.lang.form.legend }} 5 | 8 | 9 | 10 |
11 |
12 |
13 | 47 |
48 | -------------------------------------------------------------------------------- /_includes/2019_languages.html: -------------------------------------------------------------------------------- 1 |
2 | 3 | Česky 4 | Deutsch 5 | English 6 | Español 7 | Português Brasileiro 8 | Русский 9 | 中文（中国） 10 |
11 | -------------------------------------------------------------------------------- /_includes/2019_supporters.html: -------------------------------------------------------------------------------- 1 | 6 |
7 | 8 | {% assign col = 0 %} 9 | 10 | {% for supporter in site.data.2019_supporters %} 11 | 12 | {% if col == 0 %} 13 |
14 | {% endif %} 15 | 16 |
17 |

18 |
19 | 20 | {% if col == 1 %} 21 |
22 | {% assign col = 0 %} 23 | {% else %} 24 | {% assign col = 1 %} 25 | {% endif %} 26 | 27 | {% endfor %} 28 | 29 | 30 | -------------------------------------------------------------------------------- /_includes/2020_checker.html: -------------------------------------------------------------------------------- 1 |
2 |
3 |
4 | {{ include.lang.form.legend }} 5 | 8 | 9 | 10 |
11 |
12 |
13 |
14 |
15 |
16 | 48 |
49 | -------------------------------------------------------------------------------- /_includes/2020_cli_checker.html: -------------------------------------------------------------------------------- 1 |
2 |
3 |
4 | {{ include.lang.form.client_legend }} 5 | 6 | 7 |
8 |
9 |
10 |
11 |
12 | 13 |
14 | 36 |
37 | -------------------------------------------------------------------------------- /_includes/2020_languages.html: -------------------------------------------------------------------------------- 1 |
2 | English (US) 3 | Le Français 4 | 日本語 5 | Español 6 | 中文（中国） 7 |
8 | -------------------------------------------------------------------------------- /_includes/2020_supporters.html: -------------------------------------------------------------------------------- 1 | 6 |
7 | 8 | {% assign col = 0 %} 9 | 10 | {% for supporter in site.data.2020_supporters %} 11 | 12 | {% if col == 0 %} 13 |
14 | {% endif %} 15 | 16 |
17 |

18 |
19 | 20 | {% if col == 1 %} 21 |
22 | {% assign col = 0 %} 23 | {% else %} 24 | {% assign col = 1 %} 25 | {% endif %} 26 | 27 | {% endfor %} 28 | 29 | {% if col == 1 %} 30 |
31 |

32 |
33 | 34 | {% endif %} 35 | 36 | 37 | -------------------------------------------------------------------------------- /_includes/footer.html: -------------------------------------------------------------------------------- 1 | 9 | -------------------------------------------------------------------------------- /_includes/header.html: -------------------------------------------------------------------------------- 1 |
2 |
3 |
4 | 8 |
9 | 10 | {% if site.github.is_project_page %} 11 | View on GitHub 12 | {% endif %} 13 | 14 |

15 | {{ site.title | default: site.github.repository_name }} 16 | {{ page.flagdayyear }} 17 |

18 | 19 | 20 | {% if site.show_downloads %} 21 |
22 | Download this project as a .zip file 23 | Download this project as a tar.gz file 24 |
25 | {% endif %} 26 |
27 |
28 | -------------------------------------------------------------------------------- /_layouts/default.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | {% seo %} 13 | 14 | 15 | 16 | 17 | 18 | 19 | {% include header.html %} 20 | 21 | 22 |
23 |
24 | {{ content }} 25 |
26 |
27 | 28 | 29 | {% include footer.html %} 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | -------------------------------------------------------------------------------- /assets/css/style.scss: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | @import "{{ site.theme }}"; 5 | 6 | .translation img { 7 | padding: 0; 8 | height: 1.8em; 9 | border: 1px solid #ccc; 10 | box-shadow: none; 11 | -webkit-box-shadow: none; 12 | } 13 | .social img { 14 | height: 2.5em; 15 | border: none; 16 | box-shadow: none; 17 | -webkit-box-shadow: none; 18 | margin: 0; 19 | } 20 | .home img { 21 | margin: 0; 22 | height: 40px; 23 | border: none; 24 | box-shadow: none; 25 | -webkit-box-shadow: none; 26 | -webkit-filter: invert(100%); 27 | filter: invert(100%); 28 | } 29 | 30 | /* logos */ 31 | .logo { 32 | width: 250px; 33 | padding: 25px !important; 34 | border: none; 35 | box-shadow: none; 36 | -webkit-box-shadow: none; 37 | } 38 | 39 | #main_content_wrap { 40 | background: #ffffff; 41 | } 42 | -------------------------------------------------------------------------------- /flags/cs.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | -------------------------------------------------------------------------------- /flags/de.svg: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | Flag of Germany 6 | 7 | 8 | 9 | 10 | -------------------------------------------------------------------------------- /flags/es.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | -------------------------------------------------------------------------------- /flags/fr.svg: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /flags/ja.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | -------------------------------------------------------------------------------- /flags/pt-br.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | -------------------------------------------------------------------------------- /flags/ru.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /flags/zh-CN.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 64 | 65 | -------------------------------------------------------------------------------- /images/AlibabaCloud.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dns-violations/dnsflagday/31ae96854214ea4241bcaf44bf31f1dfe325ab30/images/AlibabaCloud.png -------------------------------------------------------------------------------- /images/CoreDNS_Colour_Horizontal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dns-violations/dnsflagday/31ae96854214ea4241bcaf44bf31f1dfe325ab30/images/CoreDNS_Colour_Horizontal.png -------------------------------------------------------------------------------- /images/DNS_Flag.svg: -------------------------------------------------------------------------------- 1 | DNS_Flag -------------------------------------------------------------------------------- /images/Infoblox-logo-with-tag.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dns-violations/dnsflagday/31ae96854214ea4241bcaf44bf31f1dfe325ab30/images/Infoblox-logo-with-tag.png -------------------------------------------------------------------------------- /images/Twitter_Social_Icon_Rounded_Square_Color.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 9 | 10 | 12 | 13 | 14 | 20 | 21 | 22 | -------------------------------------------------------------------------------- /images/bluecat.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dns-violations/dnsflagday/31ae96854214ea4241bcaf44bf31f1dfe325ab30/images/bluecat.png -------------------------------------------------------------------------------- /images/cisco.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | image/svg+xml 49 | 54 | 57 | 59 | 61 | 69 | 75 | 81 | 87 | 93 | 94 | 95 | 101 | 107 | 113 | 119 | 125 | 131 | 137 | 143 | 149 | 150 | -------------------------------------------------------------------------------- /images/cleanbrowsing.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dns-violations/dnsflagday/31ae96854214ea4241bcaf44bf31f1dfe325ab30/images/cleanbrowsing.png -------------------------------------------------------------------------------- /images/cloudflare.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dns-violations/dnsflagday/31ae96854214ea4241bcaf44bf31f1dfe325ab30/images/cloudflare.png -------------------------------------------------------------------------------- /images/cznic.svg: -------------------------------------------------------------------------------- 1 | 2 | image/svg+xml -------------------------------------------------------------------------------- /images/facebook.svg: -------------------------------------------------------------------------------- 1 | 2 | 14 | 16 | 17 | 19 | image/svg+xml 20 | 22 | FB-Wordmark-RGB-1024 23 | 24 | 25 | 26 | 28 | 30 | 31 | FB-Wordmark-RGB-1024 33 | 38 | 43 | 48 | 53 | 58 | 63 | 68 | 73 | 74 | -------------------------------------------------------------------------------- /images/google.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /images/home.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | -------------------------------------------------------------------------------- /images/isc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dns-violations/dnsflagday/31ae96854214ea4241bcaf44bf31f1dfe325ab30/images/isc.png -------------------------------------------------------------------------------- /images/nlnetlabs.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | image/svg+xml -------------------------------------------------------------------------------- /images/powerdns.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 6 | 7 | 13 | 26 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 39 | 43 | 45 | 47 | 50 | 52 | 54 | 59 | 60 | -------------------------------------------------------------------------------- /images/quad9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dns-violations/dnsflagday/31ae96854214ea4241bcaf44bf31f1dfe325ab30/images/quad9.png -------------------------------------------------------------------------------- /images/space-available.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dns-violations/dnsflagday/31ae96854214ea4241bcaf44bf31f1dfe325ab30/images/space-available.png -------------------------------------------------------------------------------- /images/whalebone.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dns-violations/dnsflagday/31ae96854214ea4241bcaf44bf31f1dfe325ab30/images/whalebone.png -------------------------------------------------------------------------------- /index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: DNS flag day 3 | lang: en-US 4 | --- 5 | 6 | 7 | 8 | 9 | Contents 10 | ======== 11 | - [Previous flag days](#previous-flag-days) 12 | - [Who's behind DNS flag day?](#whos-behind-dns-flag-day) 13 | - [Get in touch](#get-in-touch) 14 | 15 | Previous flag days 16 | ================== 17 | 18 | Here is a list of the previous flag days: 19 | - [2019 EDNS workarounds](/2019/) 20 | 21 | Who's behind DNS flag day? 22 | ========================== 23 | 24 | The DNS flag day effort is community driven by DNS software and service 25 | providers, and supported by [The DNS Operations, Analysis, and Research Center (DNS-OARC)](https://www.dns-oarc.net/) 26 | which most in the community are members of. 27 | 28 | If you have technical questions around DNS flag day you can join 29 | [the DNS-operations mailing list](https://lists.dns-oarc.net/mailman/listinfo/dns-operations) 30 | and ask them there. 31 | 32 | Get in touch 33 | ============ 34 | 35 | For press & media inquiries please use media (at) dns-oarc.net and please put 36 | “DNS Flag Day" in the email subject line. 37 | 38 | - Web: 39 | - Twitter: 40 | - Announcements: 41 | - Discussion: 42 | -------------------------------------------------------------------------------- /js/client-tcp-checker.js: -------------------------------------------------------------------------------- 1 | var clientTcpChecker = function(init) { 2 | (function(init) { 3 | $('#client-tcp').submit(function(event) { 4 | console.log('start'); 5 | 6 | $('#client-tcp-loading-area').append(''); 7 | var img = $('#client-tcp-loading-area img:last-child'); 8 | img.on('load', function () { 9 | $('#client-tcp-loading-area').append(''); 10 | var img = $('#client-tcp-loading-area img:last-child'); 11 | img.on('load', function () { 12 | $('#client-tcp input[type="submit"]').attr('disabled', false); 13 | console.log('load OK'); 14 | $('#client-tcp-checker-status').text(init.status.done); 15 | $('#client-tcp-checker-result').html(init.texts.reportOkHtml); 16 | }); 17 | img.on('error', function (e) { 18 | $('#client-tcp input[type="submit"]').attr('disabled', false); 19 | console.log('load FAIL'); 20 | $('#client-tcp-checker-status').text(init.status.done); 21 | $('#client-tcp-checker-result').html(init.texts.reportFailHtml); 22 | }); 23 | 24 | img.attr('src', 'https://dnsflagdaytcp.cmdns.dev.dns-oarc.net/dot.png'); 25 | console.log('loading'); 26 | $('#client-tcp-checker-status').text(init.status.loading); 27 | }); 28 | img.on('error', function (e) { 29 | $('#client-tcp input[type="submit"]').attr('disabled', false); 30 | console.log('network problem'); 31 | $('#client-tcp-checker-status').text(init.status.done); 32 | $('#client-tcp-checker-result').html(init.texts.reportNetworkProblemHtml); 33 | }); 34 | 35 | $('#client-tcp input[type="submit"]').attr('disabled', true); 36 | img.attr('src', 'https://cmdns.dev.dns-oarc.net/dot.png'); 37 | console.log('checking network'); 38 | $('#client-tcp-checker-status').text(init.status.checkNetwork); 39 | 40 | event.preventDefault(); 41 | }); 42 | })(init); 43 | } 44 | -------------------------------------------------------------------------------- /js/domain-checker.js: -------------------------------------------------------------------------------- 1 | 'use strict'; 2 | var domainChecker = function(domainCheckerInit) { 3 | ( function (domainCheckerInit) { 4 | const API_URL = new URL( '/ednscomp', 'https://ednscomp.isc.org' ); // URL object not supported in MS IE 5 | const API_METHOD = 'GET'; 6 | const INPUT_NAME = 'zone'; 7 | const PARAM_JSON_NAME = 'json'; 8 | const PARAM_JSON_VALUE = 'yes'; 9 | const INPUT_NODE_NAME = 'INPUT'; 10 | const ROOT_NODE_NAME = 'FORM'; 11 | const SUBMIT_TYPE = 'submit'; 12 | const UNDEFINED = 'undefined'; 13 | const RESULTS_ID = 'domain-checker-results'; 14 | const SUBMIT_ENABLE_AFTER = 30000; // [int] in ms 15 | const DIVIDERS_REGEXP = new RegExp( '(?:,|;|\\s| |\\r?\\n)+', 'u' ); // lot of possible dividers 16 | 17 | const dict_to_values = function (dict) { 18 | var values = [] 19 | for (var key in dict) { 20 | values.push(dict[key]) 21 | } 22 | return values 23 | } 24 | 25 | const checks_2019 = [ 26 | 'dns', 'edns', 'edns@512', 'ednsopt', 'edns1opt', 'do', 27 | 'ednsflags', 'docookie', 'edns512tcp', 'optlist' 28 | ] 29 | 30 | // eval one server 31 | const eval_edns_strict = function (tests_results) { 32 | // strip test names -> array of arrays with test results 33 | var test_values = dict_to_values(tests_results) 34 | var all_ok = test_values.every(results => results.indexOf('ok') !== -1) 35 | if (all_ok) 36 | return 'ok' 37 | 38 | // consider only tests relevant for 2019 flag day 39 | // (ignore EDNS1 which was out of scope, 40 | // and also any other tests added later) 41 | var edns0_tests_results = {} 42 | for (var key in tests_results) { 43 | if (checks_2019.includes(key)) 44 | edns0_tests_results[key] = tests_results[key] 45 | else 46 | edns0_tests_results[key] = ['ignored'] 47 | } 48 | test_values = dict_to_values(edns0_tests_results) 49 | 50 | // does not fully comply with EDNS but at least it does not break horribly 51 | var compatible = test_values.every(results => results.indexOf('timeout') === -1) 52 | if (compatible) 53 | return 'compatible' 54 | else // timeout detected, it will die 55 | return 'dead' 56 | 57 | for (var test_name in tests_results) { 58 | console.log(test_name, tests_results[test_name]) 59 | } 60 | } 61 | 62 | const eval_domain = function (genreport_data) { 63 | if (genreport_data === undefined) { 64 | return 'test_error' 65 | } 66 | var nsip_results = [] 67 | console.log('NS IP;NSID;result') 68 | for (var srv_idx in genreport_data) { 69 | var ns_result = eval_edns_strict(genreport_data[srv_idx]['tests']) 70 | nsip_results.push(ns_result) 71 | console.log(genreport_data[srv_idx]['address'] + ';' + genreport_data[srv_idx]['nsid'] + ';' + ns_result) 72 | } 73 | if (nsip_results.length === 0) { 74 | return 'test_error' 75 | } 76 | // all results are the same - nothing to analyze 77 | var all_same = nsip_results.every(nsres => nsres === nsip_results[0]) 78 | if (all_same) 79 | return nsip_results[0] 80 | 81 | if (nsip_results.filter(nsres => nsres === 'dead').length > 0) 82 | // at least one NS is dead, fallback to other NS will be required 83 | return 'high_latency' 84 | else // mix of ok and compatible NS -> compatible 85 | return 'compatible' 86 | } 87 | 88 | const createSingleResultElement = function ( /** @type {{}} */ json, /** @type {String} */ name ) { 89 | const element = document.createElement( 'div' ); 90 | if ( name ) 91 | { 92 | const title = document.createElement( 'strong' ); 93 | title.appendChild( document.createTextNode( name ) ); 94 | element.appendChild( title ); 95 | } 96 | 97 | const span = document.createElement( 'span' ); 98 | const test_result = eval_domain(json['data']) 99 | switch (test_result) { 100 | case 'ok': 101 | span.innerHTML = domainCheckerInit.texts.reportOkHtml; 102 | break; 103 | 104 | case 'compatible': 105 | span.innerHTML = domainCheckerInit.texts.reportCompatibleHtml; 106 | break; 107 | 108 | case 'high_latency': 109 | span.innerHTML = domainCheckerInit.texts.reportHighLatencyHtml; 110 | break; 111 | 112 | case 'dead': 113 | span.innerHTML = domainCheckerInit.texts.reportFailHtml; 114 | break; 115 | 116 | case 'test_error': 117 | span.innerHTML = domainCheckerInit.texts.reportTestErrorHtml; 118 | break; 119 | 120 | } 121 | element.appendChild( span ); 122 | 123 | if ( json.report ) 124 | { 125 | element.appendChild( document.createTextNode( domainCheckerInit.texts.reportLinkText ) ); 126 | const link = document.createElement( 'a' ); 127 | link.href = json.report; 128 | link.onclick = function () { 129 | return !window.open( this.href ); 130 | }; 131 | link.appendChild( document.createTextNode( json.report ) ); 132 | element.appendChild( link ); 133 | } 134 | 135 | return element; 136 | } 137 | 138 | const formOnSubmit = function ( /** @type {Event} */ event ) { 139 | event.preventDefault(); 140 | 141 | /** @type {HTMLFormElement} */ 142 | const eventTarget = ( event.target ); 143 | 144 | /** @type {HTMLFieldSetElement} */ 145 | const fieldset = eventTarget.firstElementChild; 146 | 147 | const list = eventTarget.elements[ INPUT_NAME ].value.split( DIVIDERS_REGEXP ); 148 | 149 | let submitElement; 150 | for ( const i in eventTarget.elements ) 151 | { 152 | if ( 153 | eventTarget.elements[ i ].nodeType === Node.ELEMENT_NODE 154 | && eventTarget.elements[ i ].nodeName === INPUT_NODE_NAME 155 | && eventTarget.elements[ i ].type === SUBMIT_TYPE 156 | ) 157 | { 158 | submitElement = eventTarget.elements[ i ]; 159 | break; 160 | } 161 | } 162 | 163 | let resultsElement = document.createElement( 'div' ); 164 | if ( fieldset.lastElementChild.id === RESULTS_ID ) 165 | { 166 | resultsElement = fieldset.lastElementChild; 167 | while ( resultsElement.lastChild ) // delete old results 168 | { 169 | resultsElement.removeChild( resultsElement.lastChild ); 170 | }; 171 | } else 172 | { 173 | resultsElement.id = RESULTS_ID; 174 | } 175 | 176 | submitElement.disabled = true; 177 | const timeout = window.setTimeout( function () { 178 | submitElement.disabled = false; 179 | }, SUBMIT_ENABLE_AFTER ); 180 | 181 | const statusElement = document.createElement( 'small' ); 182 | statusElement.appendChild( document.createTextNode( domainCheckerInit.status.loading ) ); 183 | resultsElement.appendChild( statusElement ); 184 | fieldset.appendChild( resultsElement ); 185 | 186 | list.forEach( function ( /** @type {String} */ zone ) { 187 | 188 | if ( zone ) 189 | { 190 | const url = API_URL; 191 | url.searchParams.set( INPUT_NAME, zone ); 192 | url.searchParams.set( PARAM_JSON_NAME, PARAM_JSON_VALUE ); 193 | 194 | fetch( url, { 195 | method: API_METHOD, 196 | headers: { 197 | 'Accept': 'application/json', 198 | }, 199 | } ).then( function ( /** @type {Response} */ response ) { 200 | submitElement.disabled = false; 201 | clearTimeout( timeout ); 202 | 203 | if ( response.status === 200 ) 204 | { 205 | return response.json(); 206 | } else if ( response.status == 429 ) { 207 | return Promise.reject(new Error(domainCheckerInit.status.rateLimit)); 208 | } else if ( response.status == 403 ) { 209 | return Promise.reject(new Error(domainCheckerInit.status.errorBan)); 210 | } 211 | return Promise.reject(new Error(domainCheckerInit.status.errorApi)); 212 | } ).then( function ( /** @type {{}} */ json ) { 213 | resultsElement.appendChild( createSingleResultElement( json, zone ) ); 214 | fieldset.appendChild( resultsElement ); 215 | 216 | if ( ( resultsElement.children.length - 1 ) >= list.length ) // ( -1 ) is for status element 217 | { 218 | submitElement.disabled = false; 219 | clearTimeout( timeout ); 220 | statusElement.replaceChild( document.createTextNode( domainCheckerInit.status.done ), statusElement.firstChild ); 221 | } 222 | 223 | } ).catch( function ( /** @type {Error | SyntaxError} */ error ) { 224 | submitElement.disabled = false; 225 | clearTimeout( timeout ); 226 | const errmsg = document.createElement( 'span' ); 227 | errmsg.innerHTML = error.message; 228 | statusElement.replaceChild( errmsg, statusElement.firstChild ); 229 | } ); 230 | } 231 | } ); 232 | 233 | return true; 234 | }; 235 | 236 | /** @type {HTMLElement} */ 237 | const intoElement = domainCheckerInit.placeIntoElement; 238 | 239 | let rootFormElement = document.createElement( ROOT_NODE_NAME ); 240 | if ( 241 | intoElement.firstElementChild 242 | && intoElement.firstElementChild.nodeType === Node.ELEMENT_NODE 243 | && intoElement.firstElementChild.nodeName === ROOT_NODE_NAME 244 | ) 245 | { 246 | rootFormElement = intoElement.firstElementChild; 247 | rootFormElement.addEventListener( 'submit', formOnSubmit, false ); 248 | rootFormElement.elements[ INPUT_NAME ].removeAttribute( 'pattern' ); 249 | } else 250 | { 251 | rootFormElement.action = API_URL; 252 | rootFormElement.method = API_METHOD; 253 | rootFormElement.target = '_blank'; 254 | 255 | const fieldset = document.createElement( 'fieldset' ); 256 | if ( typeof domainCheckerInit.texts.formTitle !== UNDEFINED && domainCheckerInit.texts.formTitle ) 257 | { 258 | const legend = document.createElement( 'legend' ); 259 | legend.appendChild( document.createTextNode( domainCheckerInit.texts.formTitle ) ); 260 | fieldset.appendChild( legend ); 261 | } 262 | const inputTextLabel = document.createElement( 'label' ); 263 | inputTextLabel.htmlFor = INPUT_NAME; 264 | if ( typeof domainCheckerInit.texts.labelText !== UNDEFINED && domainCheckerInit.texts.labelText ) 265 | { 266 | inputTextLabel.appendChild( document.createTextNode( domainCheckerInit.texts.labelText ) ); 267 | } 268 | 269 | const inputText = document.createElement( INPUT_NODE_NAME ); 270 | inputText.type = 'text'; 271 | inputText.required = true; 272 | inputText.name = INPUT_NAME; 273 | inputText.id = INPUT_NAME; 274 | 275 | inputTextLabel.appendChild( inputText ); 276 | 277 | fieldset.appendChild( inputTextLabel ); 278 | 279 | const submit = document.createElement( INPUT_NODE_NAME ); 280 | submit.type = SUBMIT_TYPE; 281 | if ( typeof domainCheckerInit.texts.submitText !== UNDEFINED && domainCheckerInit.texts.submitText ) 282 | { 283 | submit.value = domainCheckerInit.texts.submitText; 284 | } 285 | 286 | fieldset.appendChild( submit ); 287 | 288 | rootFormElement.appendChild( fieldset ); 289 | 290 | rootFormElement.onsubmit = formOnSubmit; 291 | domainCheckerInit.placeIntoElement.appendChild( rootFormElement ); 292 | } 293 | 294 | } )(domainCheckerInit); 295 | }; 296 | -------------------------------------------------------------------------------- /js/supporters-randomiser.js: -------------------------------------------------------------------------------- 1 | var supportersRandomiser = function () { 2 | ( (/** @type {HTMLElement} */ root ) => { 3 | let current = root; 4 | const list = []; 5 | while ( current.nextElementSibling ) 6 | { 7 | current = current.nextElementSibling; 8 | if ( 9 | current.nodeName === 'DIV' 10 | && current.firstElementChild 11 | && current.firstElementChild.nodeName === 'DIV' 12 | && current.firstElementChild.firstElementChild 13 | && current.firstElementChild.firstElementChild.nodeName === 'P' 14 | ) 15 | { 16 | list.push( current.firstElementChild ); 17 | list.push( current.firstElementChild.nextElementSibling ); 18 | } 19 | else { 20 | break; 21 | } 22 | } 23 | for ( let i = list.length - 1; i > 0; i-- ) 24 | { 25 | const j = Math.floor( Math.random() * ( i + 1 ) ); 26 | [ list[ i ], list[ j ] ] = [ list[ j ], list[ i ] ]; // eslint-disable-line no-param-reassign 27 | } 28 | 29 | list2 = []; 30 | let row = null; 31 | for ( let i = 0; i < list.length; i++ ) 32 | { 33 | if ( (i % 2) == 0 ) { 34 | row = document.createElement( 'div' ); 35 | row.classList.add('row'); 36 | row.appendChild(list[i]); 37 | } else { 38 | row.appendChild(list[i]); 39 | list2.push(row); 40 | row = null; 41 | } 42 | } 43 | if (row) { 44 | list2.push(row); 45 | } 46 | 47 | root.parentNode.insertBefore( document.createElement( 'div' ), root.nextSibling ); 48 | list2.forEach( (/** @type {HTMLElement} */ item ) => { 49 | root.nextElementSibling.appendChild( item ); 50 | } ); 51 | } )( document.getElementById( 'do-not-translate-randomize-this-section' ) ); 52 | }; 53 | -------------------------------------------------------------------------------- /js/tcp-checker.js: -------------------------------------------------------------------------------- 1 | var tcpChecker = function(init) { 2 | (function(init) { 3 | $('#tcp-checker').submit(function(event){ 4 | console.log('test starting'); 5 | $('#tcp-checker input[type="submit"]').attr('disabled', true); 6 | $('#tcp-checker-result, #tcp-checker-report').text(''); 7 | var zone = $('#tcp-checker input[type="text"]').val(); 8 | var tcp_hard_breakage_types = ['timeout', 'failed', 'reset', 9 | 'connection-refused', 'eof', 'malformed', 'mismatch', 10 | 'rcode15', 'servfail', 'refused', 'nxdomain'] 11 | 12 | const dict_to_values = function (dict) { 13 | var values = [] 14 | for (var key in dict) { 15 | values.push(dict[key]) 16 | } 17 | return values 18 | } 19 | 20 | // eval one server 21 | const eval_tcp_strict = function (tests_results) { 22 | // strip test names -> array of arrays with test results 23 | var test_values = dict_to_values(tests_results) 24 | var all_ok = test_values.every(results => results.indexOf('ok') !== -1) 25 | if (all_ok) 26 | return 'ok' 27 | 28 | // check if TCP or simple UDP query have one of blacklisted results 29 | for (var key in tests_results) { 30 | if (key === 'edns512tcp' || key === 'do') { 31 | for (var resultidx in tests_results[key]) { 32 | if (tcp_hard_breakage_types.includes(tests_results[key][resultidx])) { 33 | // TCP or simple UDP query on this IP does not work, die 34 | return 'dead' 35 | } 36 | } 37 | } 38 | } 39 | // the IP is not 100% compliant but does not break horribly 40 | return 'compatible' 41 | } 42 | 43 | const eval_domain = function (genreport_data) { 44 | if (genreport_data === undefined) { 45 | return 'test_error' 46 | } 47 | var nsip_results = [] 48 | console.log('NS IP;NSID;result') 49 | for (var srv_idx in genreport_data) { 50 | var ns_result = eval_tcp_strict(genreport_data[srv_idx]['tests']) 51 | nsip_results.push(ns_result) 52 | console.log(genreport_data[srv_idx]['address'] + ';' + genreport_data[srv_idx]['nsid'] + ';' + ns_result) 53 | } 54 | if (nsip_results.length === 0) { 55 | return 'test_error' 56 | } 57 | // all results are the same - nothing to analyze 58 | var all_same = nsip_results.every(nsres => nsres === nsip_results[0]) 59 | if (all_same) 60 | return nsip_results[0] 61 | 62 | if (nsip_results.filter(nsres => nsres === 'dead').length > 0) 63 | // at least one NS is dead, fallback to other NS will be required 64 | return 'high_latency' 65 | else // mix of ok and compatible NS -> compatible 66 | return 'compatible' 67 | } 68 | $.ajax('https://ednscomp.isc.org/ednscomp', { 69 | data: { 70 | zone: zone, 71 | json: true, 72 | }, 73 | }) 74 | .done(function(data) { 75 | $('#tcp-checker input[type="submit"]').attr('disabled', false); 76 | console.log('Request Successful:'); 77 | console.log(data); 78 | $('#tcp-checker-status').text(init.status.done); 79 | 80 | var domain = $(''); 81 | $('strong', domain).text(zone); 82 | 83 | const test_result = eval_domain(data.data) 84 | if (test_result == 'test_error') { 85 | $('#tcp-checker-result').html(domain.html()+init.texts.reportTestErrorHtml); 86 | } else if (test_result == 'dead') { 87 | $('#tcp-checker-result').html(domain.html()+init.texts.reportFailHtml); 88 | // data.errors => some NS names cannot be resolved to an IP address 89 | } else if (test_result == 'high_latency' || data.errors) { 90 | $('#tcp-checker-result').html(domain.html()+init.texts.reportHighLatencyHtml); 91 | } else if (test_result == 'compatible') { 92 | $('#tcp-checker-result').html(domain.html()+init.texts.reportWarningHtml); 93 | } else if (test_result == 'ok') { 94 | $('#tcp-checker-result').html(domain.html()+init.texts.reportOkHtml); 95 | } 96 | 97 | $('#tcp-checker-report').html(''); 98 | $('#tcp-checker-report > span').text(init.texts.reportLinkText); 99 | $('#tcp-checker-report > a') 100 | .text(data.report) 101 | .attr('href', data.report); 102 | }) 103 | .fail(function(jqXHR, textStatus, errorThrown) { 104 | $('#tcp-checker input[type="submit"]').attr('disabled', false); 105 | console.log('Request Failed:'); 106 | console.log(jqXHR); 107 | console.log('textStatus: '+textStatus); 108 | console.log('errorThrown: '+errorThrown); 109 | switch (jqXHR.status) { 110 | case 429: 111 | $('#tcp-checker-status').text(init.status.rateLimit); 112 | break; 113 | case 403: 114 | $('#tcp-checker-status').text(init.status.errorBan); 115 | break; 116 | default: 117 | $('#tcp-checker-status').text(init.status.errorApi); 118 | break; 119 | } 120 | var domain = $(''); 121 | $('strong', domain).text(zone); 122 | $('#tcp-checker-result').html(domain.html()+init.texts.reportTestErrorHtml); 123 | }); 124 | $('#tcp-checker-status').text(init.status.loading); 125 | event.preventDefault(); 126 | }); 127 | })(init); 128 | } 129 | -------------------------------------------------------------------------------- /robots.txt: -------------------------------------------------------------------------------- 1 | User-agent: * 2 | Allow: / 3 | Sitemap: https://dnsflagday.net/sitemap.xml 4 | -------------------------------------------------------------------------------- /signs/compatible.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | -------------------------------------------------------------------------------- /signs/dead.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | image/svg+xml 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | -------------------------------------------------------------------------------- /signs/high_latency.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 19 | 21 | 46 | 48 | 49 | 51 | image/svg+xml 52 | 54 | 55 | 56 | 57 | 58 | 63 | 69 | 75 | 81 | 87 | 93 | 102 | 111 | 112 | 113 | -------------------------------------------------------------------------------- /signs/ok.svg: -------------------------------------------------------------------------------- 1 | 2 | image/svg+xml --------------------------------------------------------------------------------