Configurar corretamente a cache do resolver do NGINX

Compreender o Resolver do NGINX e a cache de DNS

Um proxy reverso necessita, inicialmente, de um endereço IP para um backend com nome de anfitrião. O Resolver NGINX para tal, consulta os servidores de nomes definidos na configuração. A resposta DNS recebida é armazenada em cache, para que o NGINX não tenha de resolver novamente o nome para cada pedido durante o seu período de validade. Este cache diz respeito exclusivamente à resolução do nome para o sistema de destino.

A diretiva resolver contém um ou mais endereços de resolutor ou identificadores de resolutor suportados. Se não for especificada uma porta diferente, o NGINX utiliza a porta 53; caso existam vários servidores registados, as consultas são processadas, de acordo com a documentação, através do método Round Robin. Para uma configuração de inicialização robusta, os endereços IP fixos são frequentemente preferíveis, uma vez que a sua resolução não depende, por sua vez, do DNS.

Por predefinição, o NGINX tem em conta os endereços IPv4 e IPv6 de um nome. Isto é adequado quando a rede transmite de forma fiável ambas as famílias de protocolos até ao backend. Parâmetros como ipv4=off ou ipv6=off excluem especificamente uma família, mas não constituem uma otimização geral da cache. A sua necessidade depende da acessibilidade do backend específico e não da mera existência de um registo AAAA.

O Resolver não é nem um servidor DNS recursivo completo nem uma transferência automática de todas as definições a partir de /etc/resolv.conf. O NGINX utiliza os servidores de nomes explicitamente especificados. No caso de zonas internas e nomes de back-end em produção, estes devem ser resolvidos por um resolvedor fiável e devidamente protegido, localizado na própria rede. Desta forma, a responsabilidade pelos nomes privados e a proteção contra respostas DNS manipuladas permanecem numa infraestrutura controlável.

A cache DNS não é uma cache HTTP

A cache de respostas DNS do resolvedor armazena as correspondências entre nomes e respostas DNS, como endereços A ou AAAA. O seu objetivo é permitir aceder novamente a um backend sem ter de repetir cada resolução de nome. Se o endereço IP de um servidor de destino mudar, é por isso que a validade da resposta DNS é relevante – e não o conteúdo de uma resposta HTTP enviada anteriormente.

Separadamente, guarda proxy_cache Respostas HTTP de um servidor a montante. A chave inclui, dependendo da configuração, por exemplo, o URI, o host ou o cabeçalho; uma correspondência fornece ao cliente uma resposta já armazenada. Os problemas que podem surgir aqui incluem páginas desatualizadas, variantes incorretas ou acertos inesperados na cache. Esta função não determina qual o endereço IP que o NGINX utiliza ao estabelecer uma nova ligação com o backend.

A cache de ficheiros abertos constitui um terceiro nível: armazena informações sobre ficheiros e descritores abertos para acessos ao sistema de ficheiros local, mas não armazena respostas DNS nem conteúdos HTTP. Quem pretender aprofundar esta distinção no contexto da entrega estática, poderá encontrá-la no artigo sobre a Configuração do Open File Cache do NGINX. No entanto, não fornece qualquer base para a escolha do TTL do resolver.

Por conseguinte, esvaziar, limpar ou atualizar uma cache HTTP não acelera uma alteração no DNS. Por outro lado, uma nova resolução de DNS não corrige uma resposta HTTP armazenada incorretamente na cache. No caso de um proxy reverso, o Cache de DNS basear-se, além disso, em nomes e endereços: não verifica o estado de funcionamento de uma aplicação nem substitui o equilíbrio de carga, as tentativas repetidas ou o planeamento correto dos tempos de espera para o upstream.

Quando é que o NGINX tem de resolver novamente os nomes

Um nome de anfitrião pode já ser conhecido pelo NGINX no momento em que a configuração é lida. O caso é diferente quando se trata de um destino variável, como, por exemplo, proxy_pass http://$backend;. O NGINX procura primeiro o nome resultante nos grupos upstream definidos. Se não encontrar lá nenhum nome adequado, necessita, em tempo de execução, de um resolvedor configurado para determinar o endereço de destino.

A notificação no resolver defined Neste contexto, não indica a ausência de uma cache HTTP. Significa que o NGINX não conhece nenhum servidor DNS para a resolução necessária em tempo de execução. resolver pode, neste contexto http, server ou location está. Uma entrada central no httpO bloco -Block é adequado quando vários anfitriões virtuais utilizam o mesmo resolvedor; um âmbito mais restrito só se justifica quando os requisitos são efetivamente diferentes.

É necessário distinguir esta resolução de tempo de execução, disponível há muito tempo, da atualização dinâmica de um grupo upstream clássico. A configuração do resolutor diretamente no upstream-Bloco, bem como server hostname resolve De acordo com a documentação do NGINX, estão disponíveis em código aberto a partir da versão 1.27.3. As instalações de código aberto mais antigas não devem ser consideradas como suportando este padrão automaticamente; historicamente, algumas das funcionalidades correspondentes estavam reservadas ao NGINX Plus.

Antes de planear fluxos dinâmicos a montante, verifica a saída instalada e as informações de compilação. O comando seguinte apresenta a versão do NGINX, a versão do compilador e os parâmetros do `configure` utilizados na compilação.

nginx -V

Compare o estado apresentado em implementações críticas com a documentação do pacote concretamente utilizado e do seu fornecedor. O que é determinante é se essa instalação documenta e disponibiliza a funcionalidade necessária. Só depois disso é que um upstream dinâmico uma escolha arquitetónica robusta.

Definir o TTL e o valid de forma deliberada

Sem qualquer configuração adicional, a cache do resolver do NGINX segue a DNS-TTL na resposta do servidor de nomes consultado. Se o operador de DNS autoritário alterar o endereço IP de um backend, o NGINX utiliza a resposta anterior até ao termo do seu TTL. Só quando for necessária uma nova resolução de nomes é que o NGINX volta a consultar o resolvedor. Desta forma, o período de validade continua a ser controlável no local onde os dados dos nomes são geridos.

O parâmetro valid substitui totalmente este TTL pelo período configurado. Assim, não só limita o TTL do DNS a um valor máximo, como também não define uma atualização periódica para além do TTL. Um valor de valid=30s pode encurtar um TTL de DNS mais longo, mas também prolongar um TTL deliberadamente curto. Isso tem de se enquadrar no planeamento da migração e da implementação do backend.

Se a zona for mantida de forma fiável, uma configuração sem substituição constitui o ponto de partida lógico. O endereço apresentado no exemplo foi escolhido de acordo com as redes descritas na documentação e não deve ser utilizado como resolutor em produção. Em vez disso, introduza o endereço de um resolutor DNS acessível e fiável da sua própria rede.

resolver 192.0.2.53;
resolver_timeout 5s;

Uma substituição pode ser útil quando o TTL do DNS não pode ser alterado e existe uma diretriz operacional documentada. Nesse caso, o desvio torna explicitamente visível durante quanto tempo o NGINX mantém as respostas. Não se trata de uma otimização geral de desempenho: tempos mais curtos podem gerar mais consultas DNS, enquanto tempos mais longos podem atrasar a transição para novos endereços de backend.

resolver 192.0.2.53 valid=30s;
resolver_timeout 5s;

A decisão não começa, portanto, com uma indicação fixa em segundos, mas sim com a questão de saber quem controla os dados do DNS e com que rapidez uma mudança no backend deve entrar em vigor. válido trata-se de uma intervenção deliberada nesta regra. Não se adequa como uma solução genérica para tornar o proxy reverso mais rápido ou para encobrir problemas de DNS.

Resolver corretamente as variáveis em proxy_pass

Contém proxy_pass uma variável, o NGINX tem de processar o nome de host resultante em tempo de execução. Primeiro, o NGINX procura um grupo upstream adequado; se não o encontrar, necessita de um resolvedor configurado para esse nome. Se este não existir, a mensagem típica é no resolver defined Não se trata de uma referência a uma cache HTTP, mas sim à falta de configuração do DNS para este caminho de execução.

O exemplo seguinte torna a resolução em tempo de execução deliberadamente visível. O resolutor encontra-se no http-contexto e, por isso, aplica-se a vários anfitriões virtuais, desde que nenhuma configuração mais específica o substitua. O endereço de documentação utilizado deve ser substituído pelo resolvedor interno do respetivo ambiente.

http {
    resolver 192.0.2.53;
    resolver_timeout 5s;

    server {
        listen 80;

        location / {
            set $backend api.internal.example;
            proxy_pass http://$backend;
        }
    }
}

A diretiva resolver_timeout não controla a duração da cache. Limita o tempo que o NGINX aguarda pela resolução de um nome; o valor padrão documentado é de 30 segundos. A escolha faz parte dos restantes parâmetros de tolerância a erros: um valor demasiado elevado pode atrasar uma solicitação com falha até à resposta de erro; um valor demasiado baixo gera erros de resolução evitáveis quando os resolutores internos estão temporariamente lentos.

Para uma localização única e claramente delimitada, o Resolver pode, no location-Bloco. Se várias localizações ou servidores necessitarem da mesma resolução, é necessário definir um âmbito comum no server- ou http- O bloco requer menos manutenção. O NGINX permite a diretiva nos três contextos; o âmbito de aplicação deve refletir a estrutura operacional real, e não apenas resolver uma mensagem de erro isolada a curto prazo.

Mesmo no caso de destinos variáveis, o tempo limite do DNS e a ligação ao backend continuam a ser classes de erros distintas. Uma resolução de nome bem-sucedida não prova que a porta de destino esteja acessível, nem que a aplicação esteja a responder. Por outro lado, um tempo limite de upstream mais elevado não resolve o problema de um endereço de resolutor inacessível.

Configurar upstreams dinâmicos com o `resolve`

Para um grupo de back-end específico, um upstream dinâmico pode ser mais fácil de compreender do que um valor de destino variável em cada localização. Este padrão separa a definição dos membros do back-end do encaminhamento: proxy_pass refere-se ao grupo, enquanto o nome do anfitrião no upstream pode ser atualizado através do DNS. Isto é particularmente adequado quando várias rotas apontam para a mesma aplicação.

O parâmetro resolve para um server-Esta entrada existe historicamente desde o NGINX 1.5.12. No NGINX de código aberto, porém, de acordo com a documentação, só está disponível a partir da versão 1.27.3; anteriormente, esta funcionalidade estava limitada à versão comercial. A configuração do resolvedor diretamente no upstream- O bloco está documentado para o Open Source a partir da versão 1.27.3.

O Zona de memória partilhada Não se trata de um tempo limite de cache nem de um caminho de dados DNS. Esta funcionalidade disponibiliza, no âmbito do NGINX, memória partilhada necessária para as configurações de upstream que sofrem alterações dinâmicas. Se, durante a resolução do DNS, o NGINX detetar outros endereços para o nome, o grupo de upstream pode ser ajustado com base neste estado gerido internamente, sem necessidade de reiniciar o sistema.

http {
    resolver 192.0.2.53;
    resolver_timeout 5s;

    upstream application_pool {
        zone application_pool 64k;
        server app.internal.example resolve;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://application_pool;
        }
    }
}

Tal como em todos os exemplos, aplica-se 192.0.2.53 apenas para um endereço de documentação. Na prática, o resolvedor registado deve conhecer de forma fiável os nomes internos, estar acessível a partir da rede NGINX e ser considerado de confiança. Além disso, antes da implementação, é necessário verificar o âmbito real de funcionalidades do pacote instalado, em vez de basear a configuração apenas num exemplo atual.

Um serviço que só é acessível através de IPv4 pode justificar uma restrição específica: resolver 192.0.2.53 ipv6=off; Impede as consultas AAAA e a seleção de um endereço IPv6 para este contexto de resolução. No entanto, trata-se de uma decisão relativa à arquitetura de rede. Quando o Dual Stack estiver a funcionar corretamente, o IPv6 não deve ser desativado apenas por hábito; por predefinição, o NGINX resolve ambas as famílias de IP.

Verificar cuidadosamente a configuração e implementá-la

Antes de efetuar uma alteração, verifica primeiro em que pontos as diretivas do resolver se aplicam efetivamente. Para tal, procura a configuração ativa, incluindo os ficheiros incorporados, e verifica se o resolver se aplica a todo o http-Contexto, destinado apenas a um anfitrião virtual ou apenas a um único caminho. Um âmbito demasiado restrito pode fazer com que outro caminho de proxy variável não encontre um resolvedor; por outro lado, um âmbito demasiado amplo dificulta a atribuição posterior de alterações.

Após cada ajuste, segue-se o Verificação da sintaxe. Ele lê a configuração e tenta também abrir os ficheiros referenciados. Isto permite detetar erros de escrita, diretivas inválidas e problemas nos ficheiros «include» antes de uma recarga. No entanto, esta verificação não comprova que o servidor DNS indicado esteja acessível, que reconheça o nome esperado ou que o backend, por trás de um endereço resolvido, aceite ligações.

nginx -t
nginx -s reload

Só execute a recarga após a verificação ter sido bem-sucedida. nginx -s reload faz com que o NGINX inicie novos workers com a nova configuração e encerre os antigos de forma controlada. Dependendo do pacote instalado e do sistema operativo, o gestor de serviços previsto para esse ambiente pode, em vez disso, desencadear a recarga. Para tal, utilize o procedimento de operação documentado da instalação, em vez de utilizar comandos provenientes de um ambiente externo.

Em seguida, planeie um teste técnico na janela de alterações prevista. Compare o TTL do DNS esperado com o momento a partir do qual um novo endereço de backend deverá ser utilizado e verifique a acessibilidade do serviço através da família de IPs efetivamente autorizada. Documente também o endereço do resolvedor, o âmbito selecionado e um possível valid-Override. Desta forma, em caso de falha, é possível distinguir se a causa está no DNS, no encaminhamento ou na aplicação.

Identificar sistematicamente os erros típicos do resolver

Começa a procura de erros na expressão de destino em proxy_pass. Se contiver uma variável, o NGINX terá de resolver o nome de host nela contido em tempo de execução, desde que este não pertença a um grupo upstream definido. A mensagem no resolver defined aponta, por isso, em primeiro lugar, para a ausência de um elemento ou para um elemento que não é visível no contexto em questão Configuração do resolutor . Adicione um servidor de nomes fiável no contexto adequado, em vez de substituir precipitadamente o nome do anfitrião por um endereço IP fixo.

Se estiver configurado um resolvedor, verifica-se, em seguida, o seu endereço, o caminho de rede e a competência para a zona utilizada. Um resolver público não pode conhecer nomes internos; por outro lado, um resolver inacessível provoca tempos de espera na resolução. Verifica também se a diretiva está a ser substituída por uma configuração mais específica. O NGINX utiliza apenas os servidores de nomes explicitamente indicados, não aplicando automaticamente todas as configurações de /etc/resolv.conf.

Se, após uma alteração do DNS, um endereço de destino antigo continuar ativo, verifica o TTL da resposta e se está definido um valid. Uma substituição prolongada substitui o TTL da resposta DNS e pode atrasar a aplicação de uma alteração em conformidade. A correção admissível não é uma duração globalmente tão curta quanto possível, mas sim um valor que se adapte à janela de alteração e à capacidade de carga da infraestrutura DNS; muitas vezes, a omissão de valid a solução mais limpa.

Em caso de problemas de ligação após uma resolução bem-sucedida, separa o DNS da ligação ao backend. Verifica se existem respostas A e AAAA e se o destino é efetivamente encaminhado e acessível através do IPv6. ipv6=off É adequado apenas para um caso de arquitetura comprovadamente operado exclusivamente com IPv4. Um timeout do DNS afeta a resolução de nomes; por outro lado, um erro de ligação a um endereço IP já conhecido aponta para problemas de encaminhamento, firewall, porta ou aplicação.

No caso de «upstreams» dinâmicos, é necessário indicar ainda o número da versão, a zona de memória partilhada e resolve são compatíveis. O suporte de código aberto documentado para este fim aplica-se a partir do NGINX 1.27.3; as instalações mais antigas não devem ser consideradas equivalentes. status_zone Além disso, as estatísticas do Resolver baseadas na API não constituem uma solução de monitorização geral para o NGINX Open Source, uma vez que as funcionalidades referidas dizem respeito ao âmbito comercial.

Selecionar a estratégia do resolver para a operação

A estratégia adequada não começa com um valor de cache genérico, mas sim com a soberania do DNS e a taxa de alterações. Se a tua equipa conseguir manter a zona autoritativa e se os TTLs desta refletirem de forma realista a janela de implementação, então uma Resolução controlada por TTL sem valid é, na maioria das vezes, o ponto de partida mais compreensível. O DNS continua a ser, então, a fonte determinante para saber durante quanto tempo uma resposta é utilizada.

Um acento colocado deliberadamente valid É uma opção a considerar se não puderes alterar o TTL e se conseguires justificar, do ponto de vista operacional, um período de cache diferente. Ao fazê-lo, define qual a consequência de uma falha que é aceitável: um valor mais elevado reduz o número de possíveis consultas DNS, mas pode, após uma mudança, apontar para um endereço que já não é válido. Não se trata nem de um limite máximo para o TTL do DNS nem de um regulador geral de desempenho.

Seleciona o padrão NGINX com base na estrutura de encaminhamento. Uma variável proxy_pass é adequado quando o destino é determinado em tempo de execução, por cada pedido ou configuração; para tal, é necessário um resolutor no âmbito adequado. Para um grupo de backends nomeado com alterações de endereço baseadas em DNS, é necessário um upstream com zone e resolve É claro, desde que o NGINX Open Source 1.27.3 ou uma versão mais recente esteja efetivamente disponível.

Só depois é que decides Timeouts e famílias de IP. O tempo limite do resolver deve corresponder aos tempos limite do cliente e do upstream, para que a ausência de uma resposta DNS não provoque atrasos desproporcionados. O IPv4 ou o IPv6 só devem ser ativados de acordo com a arquitetura da rede. Utilize exclusivamente resolvers seguros, capazes de responder de forma fiável às zonas internas.

A resolução de DNS e o Keepalive upstream desempenham funções diferentes. O Resolver determina qual a morada de backend que o NGINX pode utilizar; o Keepalive mantém as ligações de backend já estabelecidas, mas inativas, para que possam ser reutilizadas. Uma alteração na reutilização de ligações não substitui, portanto, nem o planeamento do TTL nem a verificação do resolvedor. Para o dimensionamento deste nível de ligação, o artigo sobre Keepalive do Upstream do NGINX a estratégia do resolutor.