Segundos bissextos: 2012 (Reddit, LinkedIn, kernel Linux) e Cloudflare 2017 (DNS)

01 · CONTEXTO

O DNS da Cloudflare e a consulta de CNAME

Na virada para 1 de janeiro de 2017, em plena meia-noite UTC, um número dentro do RRDNS, o software de DNS próprio da Cloudflare, ficou negativo quando deveria ser, no pior caso, zero. O efeito foi que algumas resoluções DNS de algumas propriedades web falharam. O post-mortem público da Cloudflare é a fonte deste caso.

O problema só atingiu clientes com registros CNAME. Nesse caso a Cloudflare precisa, de vez em quando, consultar via DNS o endereço real do servidor de origem. O RRDNS acompanha o desempenho de vários resolvedores internos, mantidos por data center para ter redundância, e escolhe o mais performático numa seleção ponderada.

1. Uma consulta de um nome configurado como CNAME chega ao RRDNS.

2. O RRDNS precisa descobrir o endereço de origem e pede a um dos resolvedores internos.

3. O resolvedor escolhido faz a consulta DNS recursiva e traz o endereço real.

4. O RRDNS mantém medidas de desempenho de cada resolvedor e usa essas medidas para decidir qual escolher.

02 · A CADEIA DE ERRO

De um relógio que anda para trás a um panic

A causa raiz, segundo a Cloudflare, foi uma suposição: algum código assumia que a diferença entre dois instantes seria, no pior caso, zero. O RRDNS mede o tempo de resposta de um resolvedor subtraindo duas leituras de time.Now, e a função de Go usada para isso não garante monotonicidade.

Esse cálculo funciona bem se o tempo avança. Os resolvedores foram ajustados para serem muito rápidos, e responder em poucos milissegundos é normal. Por isso, se o relógio retrocede um segundo durante uma resolução, o tempo percebido fica negativo.

Uma única medição negativa não bastaria para o RRDNS achar que o resolvedor trabalha em tempo negativo. Mas ele guarda várias medições e as suaviza; depois de algumas medições o valor suavizado podia ficar negativo. Mais tarde, o código de seleção ponderada recebeu esse valor, e a função de sorteio de Go entra em panic com argumento negativo.

1. Durante uma resolução rápida, o relógio retrocede e a diferença entre as duas leituras sai negativa.

2. Algumas resoluções gravam um valor negativo na estrutura de medidas durante o segundo bissexto.

3. A suavização combina várias medições e, depois de algumas, o valor suavizado fica negativo.

4. A seleção ponderada lê o valor negativo e a função de sorteio entra em panic.

5. O panic é capturado com recover, mas algumas resoluções DNS falham para quem usa CNAME.

03 · IMPACTO E RESPOSTA

Poucas máquinas, uma correção em ondas

O alcance foi limitado: poucas máquinas foram afetadas. No pico, cerca de 0,2% das consultas DNS e menos de 1% das requisições HTTP à Cloudflare tiveram problema. As máquinas mais afetadas foram corrigidas em 90 minutos e a correção chegou ao mundo todo até 06h45 UTC.

O post traz um gráfico com a taxa de erros por data center (observabilidade), que mostra locais mais afetados que outros e a queda rápida de erros conforme a correção avançava. A Cloudflare implantou a correção priorizando os locais com mais erros.

1. A mitigação vai primeiro a um nó canário e é confirmada às 00:55 UTC.

2. Depois vai a um data center canário e é confirmada às 01:03 UTC.

3. A correção chega ao data center mais impactado às 01:23 UTC.

4. Em seguida é implantada nos data centers principais, a partir das 01:45 UTC.

5. Os erros por data center caem conforme as ondas avançam, e o impacto termina às 06:45 UTC.

04 · O CONSERTO

Esquecer a medida em vez de gravar o impossível

O patch fez o RRDNS esquecer o desempenho atual do resolvedor e normalizar de novo se o tempo pulasse para trás. A correção impede a gravação de valores negativos na seleção de servidor, e reiniciar todos os servidores RRDNS resolveu qualquer recorrência.

Com uma fonte de relógio não monotônica, o post cita como precaução sempre verificar se a diferença entre dois instantes é negativa. Segundo o post, Go não oferecia na época uma fonte de tempo monotônica. A empresa disse ainda estar inspecionando todo o código por outros usos de intervalos de tempo sensíveis ao segundo bissexto.

05 · LIÇÕES

Relógio de parede não mede duração

A lição de projeto é separar dois usos do tempo: saber que horas são e medir quanto algo durou. O primeiro depende de um relógio que pode ser ajustado; o segundo pede um relógio que nunca anda para trás. Quando só existe o primeiro, o código que mede duração precisa tratar o resultado negativo como possível.

Uma segunda lição de projeto é validar nas duas pontas: quem produz um valor e quem o consome podem checá-lo de forma independente, e cada checagem custa pouco.