O que acontecerá em 1º de fevereiro?

Não que, é claro, tenha sido a primeira discussão de uma pergunta sobre Habré . No entanto, até agora, as consequências foram discutidas principalmente, enquanto, em nossa opinião, as causas são muito mais interessantes.

Portanto, o Dia da Bandeira do DNS está agendado para 1º de fevereiro. Os efeitos desse evento ocorrerão gradualmente, mas ainda mais rapidamente do que algumas empresas poderão se adaptar a ele.

O que é isso Em termos simples, este é um manifesto dos principais desenvolvedores de servidores DNS do mundo: CZ.NIC, ISC, NLnet Labs e PowerDNS.

Os fabricantes de software DNS há muito tempo enfrentam um problema: o desenvolvimento de um sistema de nome de domínio, a adição de novas funções exigidas pelos clientes, a solução de problemas de segurança - todos esses processos são drasticamente mais lentos devido à estrutura cooperativa do sistema DNS e à necessidade de oferecer suporte a servidores arcaicos que implementam versões de protocolo herdadas (e mesmo isso geralmente é feito com erros).

Situação excepcional

De acordo com o catálogo de padrões de protocolo DNS , a especificação atual contém, em 21 de janeiro de 2018, 3248 páginas. Eles incluem todas as RFCs relevantes nos status de “padrão da Internet” , “padrão proposto” (que é essencialmente o mesmo para hoje), “melhores práticas atuais” e “informativo” . Para comparação: o protocolo HTTP, que fornece a entrega de conteúdo para todos os sites da Internet, é descrito no total em 672 páginas.

Como diz o ditado, se o TOR do seu projeto não se parece com algo assim, nem tente me convidar.

A necessidade de implementar o processamento de todas as funções e exceções descritas em 3.000 páginas é um trabalho árduo por si só e, além disso, vários servidores DNS implementam essa ou aquela funcionalidade incorretamente, o que leva à necessidade de processar adicionalmente o comportamento não padrão. Em algumas das RFCs acima mencionadas, o desespero que atinge as pessoas que trabalham com o protocolo é espalhado até pelo nome .

Segundo os principais desenvolvedores de DNS, a situação com a complexidade do código do programa já é grave o suficiente para tomar medidas drásticas. Em 1º de fevereiro, como parte de uma ação coordenada, serão lançadas versões atualizadas de todos os principais servidores DNS, nas quais o suporte a determinados comportamentos incorretos será encerrado agora e para sempre.

E com mais detalhes?

Para explicar o que exatamente deixará de ser suportado, darei uma analogia. Imagine que até 1999 as pessoas não eram permitidas em um avião com bagagem e, em 1999, por decisão oficial da autoridade supervisora, os passageiros podiam levar as malas (com um certo peso e tamanho). Confortável o suficiente, certo? Você pode carregar muitas coisas úteis.

Imagine agora que em 2019 ainda existem aviões que não podem ser transportados com malas e até o embarque você não tem como descobrir se pode levar bagagem com você.

Esse é aproximadamente o caso da extensão EDNS , cuja falta de suporte a partir de 1º de fevereiro levará à inacessibilidade de vários sites. Em termos gerais, em fevereiro, devido ao vigésimo aniversário do primeiro padrão EDNS , aviões que não sabem como levar bagagem a bordo (pelo menos o mínimo) não serão mais permitidos em vários aeroportos.

Um anúncio sobre isso foi divulgado com bastante antecedência: em março-maio ​​de 2018, os principais organizadores do Dia da Bandeira do DNS informaram o público em várias conferências populares da indústria . Além disso, o lançamento de versões atualizadas dos servidores DNS por si só não causará problemas imediatamente, pois os operadores ainda precisam mudar para essas versões, e isso leva tempo. Mais importante, porém, vários provedores de serviços DNS baseados na nuvem também aderiram ao DNS Flag Day. Isso inclui gigantes como Google (e seu famoso servidor DNS com um endereço IP de 8.8.8.8), Cloudflare, Facebook e Cisco.

Como resultado, sites que usam servidores DNS sem suporte EDNS (ou seja, "aviões" que não sabem como "transportar bagagem a bordo") deixarão de funcionar para todos aqueles que usam servidores DNS abertos 8.8.8.8, 9.9.9.9 a partir de 1º de fevereiro, 1.1.1.1 e vários outros. À medida que os provedores de DNS atualizam seus ISPs, a lista aumenta.

A peculiaridade do funcionamento do servidor DNS na infraestrutura corporativa é que ele normalmente não solicita, trabalha por si mesmo e funciona, portanto, muitas vezes nunca é atualizado por ninguém. Os administradores de sistema da velha escola até gostam de se orgulhar do tempo de atividade a longo prazo dessas máquinas. O problema é que, quando é necessário atualizar, acontece que, para isso, é necessário, por exemplo, também mudar do FreeBSD 5 para o FreeBSD 10 (o caso real), que, entre outros problemas, exigirá uma reinicialização e, desde a reinicialização, o servidor antigo já está pode simplesmente não sair.

O mais desagradável é que a solução para o problema em geral não se resume a simplesmente atualizar os servidores DNS. Algumas organizações usam firewalls (tanto de software quanto de hardware) que forçam a remoção forçada de todos os pacotes DNS com a função EDNS. Entre outras coisas, os antigos modelos Juniper SRX estavam envolvidos nisso, mas o assunto não se limita a eles. Em princípio, se falamos sobre firewalls e soluções de DPI em geral, há muito que se sabe um nível de qualidade de desenvolvimento bastante baixo de várias dessas soluções. Durante todos esses anos, os desenvolvedores do protocolo DNS sofreram com os problemas que causaram objetivamente e agora decidiram revidar.

Mas atualizar essas soluções pode levar um tempo considerável e, em alguns casos, pode ser necessário jogar fora o equipamento outrora caro no lixo e adquirir novos, o que causará muitas dificuldades, por exemplo, dentro da estrutura do ciclo orçamentário russo (especialmente se o equipamento descartado foi fabricado em no exterior e não há mais oportunidade de comprar estrangeiros de uma organização por um motivo ou outro - financeiro, político, ideológico).

Então, para quem tem esse problema, é hora de começar a resolvê-lo. Observe que as soluções imediatas exigem apenas os problemas que a ferramenta de verificação correspondente exibe com “STOP” ou “LENTO” vermelho. O ponto de exclamação no triângulo amarelo é apenas um aviso até agora e 1º de fevereiro não causará problemas (embora, a longo prazo, esse problema precise ser corrigido).

E depois o que?

Em primeiro lugar, o Dia da Bandeira do DNS não deve provocar cataclismos significativos.

Em várias discussões, pode-se ouvir críticas ao post original de Alexei Lukatsky em Habré: eles dizem que o autor adotou um tom excessivamente alarmista. Não obstante, não se pode deixar de notar que Aleksey é a mesma pessoa que sabe muito bem como a infraestrutura de rede de grandes organizações e instituições estatais russas está ligada e a que equipamento está conectado. De acordo com o estudo, cujos resultados, aparentemente, estão disponíveis para o .RU e o Centro de Coordenação de Domínios. Before, o problema que, antes do registro de Lukatsky foi registrado em vários sites conhecidos, hoje já está aparecendo em pequenas quantidades, ou seja, uma entrada de blog na Cisco (e notas subsequentes, digamos, no blog Roskomsvoboda ) tiveram o efeito desejado.

No entanto, o sucesso do Dia da Bandeira do DNS obviamente trará consequências, a principal delas é que essas ações continuarão no futuro. Ainda existem muitos lugares no sistema DNS que os desenvolvedores gostariam de expandir o mais rápido possível; além disso, o DNS não é o único protocolo em que há algo para analisar. O exemplo com o atributo BGP 0xFF, que discutiremos no próximo artigo, mostra claramente: às vezes a vacina é útil para a Internet.

Até o momento, isso deixa os administradores de sistema com um dilema bastante claro:

1. Ou, o administrador do servidor DNS deve monitorar a vida da comunidade da Internet, em particular as notícias da comunidade profissional de desenvolvedores de DNS e, em particular, prestar atenção e tempo nas atualizações do servidor;
2. Ou o gerenciamento de sua própria zona de domínio deve ser transferido para um fornecedor terceirizado especializado em tais trabalhos (dos quais existem, em princípio, muitas pessoas no mundo).

No entanto, é provável que também voltemos a esse tópico.