Pare de usar nomes de domínio .IO para o tráfego de produção

Nota: Se você é um usuário do Stream , não se esqueça de atualizar o seu cliente da API para a versão mais recente para uma grande melhoria na confiabilidade. Para aqueles de você em um cliente API personalizado, veja nossa documentação REST atualizada .

A resolução do domínio é um dos serviços de backbone da Internet. É algo em que normalmente passamos muito pouco tempo pensando. Claro, isso muda quando se quebra. Durante o ano passado, as quedas de domínio do IO foram a principal razão por que nossos clientes não podiam usar o Stream . Especificamente, a interrupção em 20 de setembro de 2017 acabou por ser uma grande dor de cabeça. Este artigo entrará nos detalhes por trás dos problemas de confiabilidade de nomes de domínio .IO e como trabalhamos em torno deles.

A infra-estrutura do Sistema de Nomes de Domínio (DNS) da Internet é grande e complexa. Devido à sua natureza descentralizada, se o problema for com o seu provedor de DNS ou com a infra-estrutura de DNS mais ampla, há pouco que você pode fazer além de sentar e esperar que o problema seja resolvido. A única solução prática para lidar com interrupções de DNS é recuar para um domínio de backup.

Isso torna as interrupções do DNS bastante desagradáveis. Muitos riscos são complexos e onerosos para mitigar e, em alguns cenários, é praticamente impossível fazê-lo.

O que foi errado: uma interrupção global no domínio de nível superior '.io'

Em 20 de setembro de 2017, nossos monitores de sistema e cheques de saúde começaram a mostrar falhas intermitentes. Pings para o nosso site e os servidores da API não conseguiram resolver registros "getstream.io" para um nome de host válido.

A resolução de nomes de domínio é necessária para acessar nosso serviço de API principal e painel de controle. Sem ele, os clientes não conseguem encontrar o endereço para nossos servidores. Escusado será dizer que isso foi imediatamente triangular como crítico e recebeu toda a atenção de nossa equipe.

Após uma investigação inicial, descobrimos que a resolução de qualquer registro getstream.io falharia aleatoriamente com um erro NXDOMAIN incorreto retornado. Posteriormente, um dos nossos engenheiros identificou que a resolução de domínios .io falharia consistentemente em 2 dos 6 servidores de nomes .io autorizados. Os restantes quatro estavam funcionando corretamente, o que explicava a aparente natureza aleatória dos erros.

Um mau parece com o seguinte:

Uma vez que isso aconteceu com os servidores de nomes autorizados, chegamos ao nosso provedor de DNS e depois tentamos entrar em contato com o NIC.io também. Para nossa surpresa, descobrimos que o NIC.io só pode ser alcançado por telefone entre as 7:00 da manhã a 12:00 UTC de segunda a sexta-feira e não expôs nenhum status sobre a saúde do serviço .

Entretanto, começamos a olhar para quem mais foi afetado por esta interrupção e postou sobre isso no Twitter e no Hacker News . Enquanto aguardava a interrupção da interrupção, também aumentávamos o DNS TTL para que a quantidade de consultas DNS fosse tão baixa quanto possível. Pouco depois, recebemos uma resposta da Gandi.net informando-nos que NIC.io estava corrigindo o problema.

A interrupção durou quase 2 horas, durante a qual 1/5 de consultas de DNS para qualquer registro .getstream.io falhariam. Para algo que se senta na frente do nosso serviço, este é um grande problema e criou mais do que algumas questões sobre o nosso fim.

Não foi possível isso acontecer com qualquer TLD?

Entendemos. Às vezes, as coisas se quebram. Realmente, uma interrupção semelhante poderia ter ocorrido em qualquer domínio de nível superior.

Quando começamos em 2014, decidimos que .io era ótimo de uma perspectiva de marca. Stream é um produto técnico e nossa audiência é principalmente técnica, então o .io pareceu um ótimo jogo. O uso do mesmo domínio para as APIs foi mais uma conseqüência do que uma decisão pensativa.

É impossível estimar a probabilidade de que os servidores de nomes .com tenham o mesmo tipo de interrupção que os servidores de nomes .io. Uma coisa que nos surpreendeu foi que, enquanto cerca de 20% das resoluções de DNS para todos os domínios .io estavam totalmente quebradas , era difícil encontrar pessoas reclamando sobre isso no Twitter. Na verdade, acredito que fomos um dos primeiros a tweet isso. Se isso tivesse acontecido em todos os domínios .com, todas as fontes de notícias teriam sido incendiadas.

O que realmente foi errado

Infelizmente, descobrimos a dificuldade de o NIC.IO não estar equipado com o suporte técnico e os sistemas necessários para gerenciar um domínio de nível superior. Ser incapaz de alcançá-los enquanto uma grande interrupção estava acontecendo é inaceitável.

Olhando para mais, não é preciso muita pesquisa para descobrir que a equipe .io TLD cometeu diversos erros ao longo dos últimos anos. Apenas para citar alguns:

A pesquisa de .io na HN retorna uma longa lista de interrupções semelhantes.

Qual é a melhor solução imediata?

Adicionar um domínio .com e usá-lo como padrão em todos os nossos clientes de API é claramente a fruta com pouca suspensão. Claro que poderíamos ter o mesmo problema se a .com tivesse uma interrupção, no entanto, estamos muito mais confiantes no gerenciamento por trás do .com. É claro que não só o problema foi identificado anteriormente, mas também não teria levado horas para que as pessoas reconhecessem e corrigissem a situação.

Nosso roteiro para um serviço de privação de DNS

Esses problemas de DNS nos fizeram pausar e pensar sobre todas as maneiras pelas quais um DNS pode quebrar.

  1. Perdemos o controle de nosso próprio domínio. Isso pode acontecer de forma alarmante e grande:
  1. Interrupção da Route53. Uma vez que estamos delegando o getstream.io nos servidores de nomes do Route53, uma interrupção nos servidores de nomes prejudicaria nosso serviço. A interrupção do DynDNS DDoS a partir de 2016 é um exemplo.
  2. .com queda de TLD.

Como controlamos os clientes da API, a implementação de um mecanismo de failover é fácil. Configurar e manter um domínio de backup e / ou um provedor de DNS de backup pode ser muito desafiador. No primeiro caso, precisamos manter centenas de registros DNS em sincronia e dobrar nossos certificados SSL; Em segundo lugar, precisamos apenas alterar nossa infraestrutura para não usar qualquer recurso específico da Route53. Para isso, precisamos manter todos os registros DNS em sincronia em dois provedores diferentes e garantir que não usamos nenhum recurso específico do fornecedor. Como cliente da AWS, este é um grande desafio, já que o DNS está profundamente integrado de muitas maneiras.

Olhando para a frente, nosso plano é adicionar um domínio .org e encontrar um provedor de DNS para gerenciar os servidores de nomes.

Conclusão

Em retrospectiva, o uso de um domínio .IO para nossas APIs principais não foi uma ótima escolha. A interrupção em 20 de setembro mostrou a gravidade dos problemas e da infra-estrutura de suporte. Com base em nossa experiência, recomendamos o uso de um nome de domínio .IO se a disponibilidade for importante.

Para contornar a questão do DNS, o tráfego da API do Stream agora é executado em um nome de domínio .com. O site ainda funciona no .io, pois isso é mais difícil de mudar e não tão crítico em termos de tempo de atividade. Para melhorar ainda mais a confiabilidade, estamos considerando:

  • Adicionando um nome de domínio backup .ORG.
  • Usando um provedor DNS de backup para o nome de domínio .COM ou .ORG.
  • Implementando failover DNS do lado do cliente em nossos SDKs.

O DNS como um todo é uma daquelas coisas que mais dão por certo, mas podem facilmente causar sérios atrasos e problemas. Usar um TLD amplamente usado como .com / .net / .org é a melhor e mais fácil maneira de garantir a confiabilidade.

Esta é uma colaboração da equipe no GetStream.io, liderada por Tommaso Barbugli , CTO no GetStream.io. A publicação do blog original pode ser encontrada em https://getstream.io/blog/stop-using-io-domain-names-for-production-traffic/ .

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *