Uma consulta, sete atendentes: a ordem de processamento do BIG-IP DNS

Uma consulta DNS que chega a um listener do BIG-IP pode ser respondida por iRules, pelo processamento DNSSEC, por um wide IP de GSLB, pelo DNS Express, por um cache DNS, pelo BIND local ou por um pool de servidores DNS reais. A F5 documenta uma precedência rígida entre eles, e a maioria das surpresas no BIG-IP DNS, do registro que responde quando você esperava o GSLB ao Rapid Response que deixa o BIND mudo, se explica quando você lê essa ordem do jeito certo.

Um BIG-IP DNS não é um único servidor DNS. É uma porta de entrada, o listener (o endereço em que o BIG-IP escuta as consultas DNS), e atrás dela até sete atendentes diferentes esperam numa fila documentada: as iRules, o processamento , os wide IPs de (global server load balancing, o balanceamento global de servidores), o DNS Express, um de três tipos de cache DNS, a instância local do e, por último, um pool de servidores DNS reais. Toda consulta percorre essa fila em ordem, e quem responde é o primeiro atendente capaz de responder. Quase todo mistério do tipo "por que recebi ESSA resposta" no BIG-IP DNS desaparece quando você sabe essa fila de cor.

Quem responde e quem resolve

Antes de tudo, ajuda separar os atendentes em duas famílias. Os que respondem têm respostas próprias: um wide IP de GSLB calcula uma resposta inteligente a partir da saúde e da localização; o DNS Express serve uma zona que guarda como secundário autoritativo de alta velocidade, alimentada por transferência de zona; a instância local do BIND (a que o ZoneRunner gerencia) serve as zonas que estiverem nos arquivos dela. Os que resolvem, os resolvers, vão buscar a resposta em outro lugar: um cache em modo resolver ou validating resolver faz a recursão a partir dos root hints (a lista dos servidores raiz), e o validating também confere as assinaturas DNSSEC; um cache em modo transparent só lembra o que os servidores atrás dele responderam; e um pool do LTM associado ao listener filtra as consultas e as repassa a servidores de nomes reais. O BIG-IP consulta os que respondem antes dos que resolvem, e é exatamente isso que se quer: respostas autoritativas e calculadas devem ganhar das respostas buscadas fora.

A ordem documentada

O K14510 da F5 define a precedência, e o K28650431 descreve o caminho inteiro. O listener recebe o pacote, as iRules rodam primeiro e, em seguida, os mecanismos do profile DNS assumem, nesta sequência: processamento DNSSEC, GSLB (o match com um wide IP), DNS Express, o cache DNS, o BIND local, se o profile tiver a opção Use BIND Server on BIG-IP habilitada, e, por fim, um pool do LTM, se houver um associado ao listener. Existe até um passo depois do fim: se o endereço do listener também for um self IP com a porta 53 aberta, o BIND do sistema responde o que ninguém mais respondeu. Duas posições nessa fila sempre surpreendem. A primeira: as iRules estão acima de tudo, e uma iRule que responde a consulta encerra o caminho antes que o GSLB chegue a vê-la; é isso que torna as iRules de DNS tão poderosas quanto perigosas. A segunda: o match com o wide IP vem antes do DNS Express. Se um nome é ao mesmo tempo um wide IP e um registro dentro de uma zona do DNS Express, o GSLB vence, e o manual confirma o corolário para o cache: o sistema processa as requisições primeiro pelo DNS Express e só depois guarda as respostas em cache.

Onde uma consulta sai da fila

Uma consulta que não bate com nenhum wide IP nem com nenhuma zona do DNS Express cai na Unhandled Query Action do profile DNS, e essa pequena configuração define o caráter do listener inteiro. Allow, o padrão, deixa a consulta seguir pela fila até o cache, o BIND ou o pool. Drop descarta a consulta em silêncio; Reject responde com uma recusa; Hint devolve um referral (a resposta que indica a quem perguntar) para os servidores raiz; No Error devolve um sucesso vazio. Um listener pensado só como frente de GSLB e DNS Express não deveria virar um resolver aberto (open resolver) por causa de um Allow; já um listener pensado como resolver, obviamente, precisa dele.

Os três caches são três máquinas diferentes

O objeto de cache DNS existe em três tipos de resolver, e escolher o tipo errado é um erro de configuração clássico. O cache transparent fica na frente de outra coisa, em geral do pool de servidores DNS, e só memoriza as respostas que passam por ele. O cache resolver faz a recursão por conta própria, descendo a partir dos servidores raiz (os root hints; por padrão, a lista da InterNIC). O validating resolver acrescenta a validação DNSSEC a essa recursão. O próprio manual da F5 traz uma recomendação de desempenho que vale repetir: mande os cache misses (as consultas que o cache não consegue responder) para um pool de servidores DNS locais, e não para a instância local do BIND, porque um único processo BIND é mais lento do que vários resolvers externos.

O BIND é o último recurso, e às vezes fica mudo

A instância local do BIND está no fim da fila por merecimento: é o atendente mais lento do equipamento, e os projetos modernos usam o ZoneRunner principalmente como uma interface de edição, cujas zonas alimentam o DNS Express por transferência, e não como aquilo que responde aos clientes. Existe também um modo que tira o BIND da fila por completo: com o Rapid Response habilitado no profile DNS, só o GSLB e o DNS Express funcionam, e as consultas que não batem com nenhum dos dois seguem a rapid-response-last-action, que por padrão é drop; com isso, os registros que só existem no ZoneRunner param de resolver. O K13850558 documenta exatamente essa surpresa, que ilustra bem o artigo inteiro: o registro existia, só que o atendente que o tinha não estava mais na fila.

Um listener se lê como uma frase

Juntando tudo, o profile DNS de um listener se lê como uma frase que declara uma intenção. GSLB habilitado, DNS Express habilitado, sem cache, sem BIND, Unhandled Query Action em Drop: uma frente autoritativa blindada. GSLB desabilitado, cache transparent, pool associado: um forwarder com cache. Cache resolver com validação: um resolver recursivo para os clientes internos. Quando o comportamento não bate com a intenção, percorra a fila do K14510 desde o início (iRules, DNSSEC, wide IPs, DNS Express, cache, BIND, pool) e descubra qual atendente respondeu fora da vez. O explicador do fluxo de decisão do GSLB continua a história a partir do passo do wide IP, e o artigo sobre o iQuery mostra como o cérebro do GSLB fica sabendo da saúde que usa para decidir.

Esta série, em ordem

Este artigo abre a série BIG-IP DNS e balanceamento global. A ordem de processamento explica a maioria das surpresas; as partes seguintes acompanham o caminho do GSLB dentro dessa ordem: como o sistema descobre o que está no ar, as duas decisões que levam a uma resposta, a cadeia que existe dentro da segunda, os registros de topologia que dão pontos aos candidatos e as response policy zones que transformam o cache num controle.

Como o iQuery conecta o BIG-IP DNS ao resto da rede. O protocolo XML, o gtmd e o big3d, as conexões de longa duração e a confiança por certificado que formam a malha (o mesh).
GSLB em dois níveis: o wide IP escolhe o pool, e o pool escolhe o servidor. O balanceamento global como duas decisões: o wide IP escolhe um pool, depois o pool escolhe um virtual server.
Load balancing no BIG-IP DNS: o wide IP, o pool e a cadeia de três passos. A cadeia preferred, alternate e fallback dentro do pool, e as regras em que as pessoas tropeçam.
Registros de topologia do GTM: o Longest Match ordena, não escolhe. O longest match é uma ordenação, não a escolha: o primeiro registro que bate dá a pontuação do candidato, e os seguintes ficam sombreados.
DNS como motor de política: multi-RPZ no BIG-IP 21.1. Várias response policy zones num único cache, avaliadas por precedência e transferidas com segurança: o DNS como motor de política.

Fontes

A ordem de resposta acima é da própria F5, exposta em dois artigos de suporte que percorrem o caminho da consulta passo a passo. Ambos ficam atrás do login do my.f5.com, de modo que quem não tem conta verá uma página de acesso em vez do texto.