Product
Indisponibilidade da API do Mailgun: post-mortem de agosto de 2016
Isso foi publicado originalmente em 12 de agosto de 2016.
Resumo
Em 4 de agosto, às 22:20 UTC, o Mailgun foi alertado sobre vários relatórios de falha na resolução de DNS do nosso nome de domínio mailgun.net, que é o domínio primário que usamos para a nossa API. Ao começarmos a investigar, descobrimos que nosso domínio tinha sido colocado no estado de “client hold” pela Dynadot, nosso registrador de domínio.
Aproximadamente às 22:47, a Dynadot reativou o domínio e começamos a notar o aumento do tráfego para nosso domínio api.mailgun.net. Os níveis de tráfego só atingiram os limites normais às 23:17 devido a caches de registros de DNS negativos.
Detalhes
Assim que nossa equipe foi alertada sobre o problema às 22:20 UTC, começamos a buscar uma solução confirmando que nossos servidores de nomes autoritativos ainda respondiam corretamente às solicitações de DNS. Confirmamos que nossa infraestrutura de DNS de back-end estava funcional e configurada corretamente, e começamos a revisar a nossa configuração de domínio com a Dynadot, nosso registrador.
Descobrimos que nosso domínio tinha sido colocado em um estado de “client hold”, o que impede a resolução normal de DNS. Não houve comunicação recente, prévia ou imediatamente antes de a Dynadot adotar essa ação punitiva contra o nosso domínio.
Nossa equipe de engenharia tentou contatar imediatamente o suporte da Dynadot através do sistema telefônico e do suporte via chat ao vivo deles. Durante toda a duração deste incidente, não conseguimos falar com a equipe de suporte técnico deles por telefone. Uma mensagem pré-gravada informava a quem ligava que todos os agentes de suporte estavam ocupados e que a pessoa deveria tentar ligar mais tarde. Conseguimos falar com um agente através do sistema de chat que nos informou que não era possível resolver o problema e que, para o bloqueio ser removido, precisávamos enviar um e-mail para a equipe de suporte deles. O agente de suporte insistiu que esse seria o único meio disponível para solucionarmos o problema. Durante esse tempo, também solicitamos uma ligação da gerência e tentamos escalonar o problema, mas não nos ofereceram opções adicionais de resolução.
Às 22:37, enviamos um e-mail para a equipe de suporte deles e nosso domínio foi reativado cerca de dez minutos depois, às 22:47. Apesar de o domínio ter sido ativado, não recebemos mais nenhuma comunicação da Dynadot até sexta-feira às 00:12 UTC afirmando que o domínio tinha sido desativado devido a reclamações de spam, mas sem recebermos nenhuma informação correspondente que comprovasse essa alegação.
Solicitamos que o problema fosse escalonado para alguém da equipe de liderança deles e que nos fossem enviados detalhes sobre as reclamações recebidas. Não recebemos nenhum detalhe adicional e, até o momento, não falamos com ninguém da equipe de liderança sênior deles sobre este incidente.
Ações e lições aprendidas
O nosso relacionamento com a Dynadot existia desde 2010, sendo anterior à aquisição do Mailgun pela Rackspace. Embora historicamente tenhamos tido poucos problemas no gerenciamento de nossos domínios, este incidente e, principalmente, a incapacidade de receber um retorno oportuno da Dynadot, tornaram necessária a mudança de provedores de serviços. No dia de hoje, concluímos a transição para o serviço de registro de domínio corporativo da Rackspace. Eles oferecem serviço 24 horas e ajudarão a garantir que problemas semelhantes não se repitam. Embora tenhamos encerrado o nosso relacionamento comercial, ainda estamos abertos a discussões com a Dynadot sobre este problema, na esperança de que suas políticas e procedimentos possam ser atualizados para evitar causar problemas a outros clientes legítimos no futuro.
