Como nomes, traduções, intermediários e pools determinam o caminho real de uma API
Edição aprofundada — material de estudo e consulta profissional
Por João Ricardo Dutra••Material integral
Apresentação do capítulo
Nos capítulos anteriores, estudamos como uma aplicação produz uma requisição, como ou transportam dados entre processos e como ou identificam interfaces e permitem que roteadores escolham um caminho. Este capítulo adiciona os componentes que tornam uma arquitetura corporativa utilizável em escala: o transforma nomes estáveis em destinos mutáveis; o traduz identidades de rede; dividem uma comunicação em conexões independentes; e balanceadores selecionam uma instância entre várias possibilidades.
Esses mecanismos são frequentemente desenhados em um único diagrama como caixas consecutivas, mas possuem responsabilidades diferentes. normalmente participa antes da conexão. altera campos de pacotes e mantém estado de tradução. Um encerra uma conexão e cria outra, podendo interpretar o protocolo de aplicação. Um balanceador aplica uma estratégia de seleção sobre um conjunto de destinos. Um mesmo produto pode executar várias dessas funções, o que torna indispensável distinguir o conceito da implementação.
Em ambientes de , erros atribuídos à aplicação frequentemente surgem antes da política ser executada. Um registro privado pode não estar visível ao runtime; uma resposta pode permanecer em ; um pool pode considerar uma instância saudável por um teste superficial; um pode substituir o Host; um balanceador pode terminar com um certificado diferente; ou um pode usar uma origem não prevista pela allowlist do . O sintoma final pode ser , 502, 503, falha de certificado ou comportamento intermitente.
O objetivo deste capítulo é fornecer um modelo mental ponta a ponta. Ao final, o leitor deverá saber localizar onde uma decisão foi tomada, quais dados foram alterados e quais evidências devem ser coletadas em cada etapa. O foco não é decorar produtos, e sim entender princípios que se aplicam a Axway , Azure Management, NGINX, HAProxy, Envoy, appliances de rede, ingress controllers e serviços gerenciados de nuvem.
Princípio central
Nome, endereço, conexão, mensagem e instância de são objetos diferentes. Um diagnóstico confiável registra a transformação entre eles em cada salto.
Objetivos de aprendizagem
Explicar a hierarquia do , zonas, delegações e os papéis de , resolvedor recursivo e servidor autoritativo.
Interpretar consultas, respostas, códigos, e os principais tipos de resource record usados em .
Relacionar , positivo, negativo e mudanças de ao comportamento real dos clientes.
Compreender por que utiliza e , o papel de e o impacto de bloqueios seletivos.
Projetar público, privado e split-horizon para , private e ambientes híbridos.
Diferenciar , , e TSIG, incluindo o que cada mecanismo protege e o que não protege.
Aprofundar Basic , , , , , e esgotamento de portas.
Distinguir , , e túnel conforme a semântica do .
Comparar pass-through, offload, re-encryption e quando existem intermediários.
Diferenciar balanceamento L4, L7 e baseado em , além de algoritmos de seleção e afinidade.
Projetar , readiness, drenagem, slow start e sem produzir falsos positivos.
Aplicar os conceitos a Axway e aos serviços Azure usados em arquiteturas de .
Diagnosticar falhas de resolução, 502/503, origem inesperada, distribuição desigual e esgotamento de .
Estrutura do capítulo
4.1 Quatro decisões diferentes no caminho de uma
4.2 Arquitetura e hierarquia do
4.3 Zonas, delegações e autoridade
4.4 Resolução recursiva e iterativa
4.5 Mensagens e resource records
4.6 , e propagação
4.7 , , EDNS e criptografado
4.8 privado, split-horizon e service discovery
4.9 Disponibilidade e balanceamento baseado em
4.10 Segurança do e
4.11 em profundidade
4.12 , , hairpin e CGNAT
4.13 em e nuvem
4.14 Intermediários
4.15 , , e túnel
4.16 Camada 4, camada 7 e terminação
4.17 Host, , e cabeçalhos encaminhados
4.18 Fundamentos de
4.19 Algoritmos de seleção
4.20 e ciclo de vida
4.21 Afinidade, estado e connection
4.22 Arquitetura com múltiplas camadas
4.23 Aplicação em Axway e Azure
4.24
4.25 Estudos de caso e laboratórios
Resumo, checklist, exercícios, glossário e referências
4.1 Quatro decisões diferentes no caminho de uma
Quando uma aplicação chama :// .empresa.com/clientes, a primeira decisão é de resolução: qual endereço ou serviço corresponde ao nome .empresa.com? Essa decisão é realizada pelo sistema de resolução de nomes, normalmente , e pode produzir um endereço , , uma cadeia de aliases ou informações adicionais de serviço. O resultado pode depender do ambiente, da localização do resolvedor, do e de políticas de tráfego global.
A segunda decisão é de tradução. Ao atravessar um , os endereços e eventualmente as portas do fluxo são substituídos. O destino pode observar o de um firewall, de nuvem ou pool de , e não o original da aplicação. Essa tradução é uma operação de rede orientada por estado e não equivale a , embora os dois mecanismos possam existir no mesmo equipamento.
A terceira decisão é de intermediação. Um recebe uma conexão do cliente, interpreta ou encaminha a mensagem e cria outra conexão para o . A partir desse ponto existem duas relações de transporte independentes: cliente- e - . , versões de , certificados, e endereços de origem podem ser diferentes em cada trecho.
A quarta decisão é de seleção de instância. Quando existem múltiplos destinos elegíveis, um balanceador escolhe qual receberá o fluxo ou requisição. A escolha depende do algoritmo, dos pesos, do estado de saúde, de afinidade e de políticas de localidade. , e também podem fazer algum tipo de distribuição, mas o momento e a granularidade da escolha são diferentes.
Tabela 1 - Responsabilidades que devem ser analisadas separadamente.
Mecanismo
Entrada principal
Decisão ou transformação
Evidência típica
DNS
Nome e tipo de registro
Retorna dados de resolução
dig, nslookup, Resolve-DnsName
NAT
Fluxo IP/porta
Traduz origem ou destino
Tabela NAT, captura, flow logs
Proxy
Conexão e protocolo
Termina e recria comunicação
Access log, upstream log, headers
Load balancer
Pool elegível
Seleciona destino
Health, algoritmo, backend metrics
4.2 Arquitetura e hierarquia do
O Domain Name System foi projetado como uma base de dados distribuída e hierárquica. Em vez de manter uma tabela central contendo todos os nomes da Internet, o espaço de nomes é organizado como uma árvore invertida. O topo é a raiz, representada por um ponto. Abaixo dela estão domínios de primeiro nível, como com, org e br. Cada ramo pode ser delegado a organizações diferentes, que passam a administrar as zonas correspondentes.
Um nome totalmente qualificado, ou , é formado por labels separadas por pontos. Em .pagamentos.empresa.com., , pagamentos, empresa e com são labels, e o ponto final explicita a raiz. Interfaces e ferramentas frequentemente omitem esse ponto final, mas a distinção entre nome absoluto e nome relativo importa em arquivos de zona e em configurações que acrescentam sufixos de pesquisa.
A hierarquia fornece escalabilidade administrativa. A organização responsável por com não precisa conhecer os endereços de .empresa.com; ela precisa indicar quais servidores são autoritativos por empresa.com. Da mesma forma, a zona empresa.com pode delegar pagamentos.empresa.com a outra equipe. A resolução percorre essas referências até alcançar uma autoridade capaz de responder sobre o nome consultado.
O não é apenas uma lista nome- . Ele armazena conjuntos tipados de dados chamados resource record sets. Um nome pode possuir registros A, , TXT, MX, CAA e outros. A resposta correta depende do nome, da classe e do tipo solicitado. Esse modelo explica por que um nome pode existir e ainda assim não possuir o tipo de registro pedido.
Figura 1 - A autoridade é distribuída por zonas e delegações na árvore .
Nome absoluto
Em configurações de , .empresa.com e .empresa.com. podem ser interpretados de forma diferente. O ponto final indica que o nome já está completo e não deve receber o sufixo da zona atual.
4.3 Zonas, delegações e autoridade
Uma zona é a porção do espaço de nomes administrada como uma unidade. Zona e domínio não são sinônimos perfeitos: um domínio pode conter subdomínios delegados que pertencem a outras zonas. A zona empresa.com, por exemplo, pode conter registros de .empresa.com e delegar parceiros.empresa.com. Após a , os registros internos de parceiros passam a ser mantidos nos servidores indicados para a nova zona.
A é publicada por registros NS no lado pai. Dependendo da posição dos próprios servidores de nomes, registros adicionais chamados glue podem ser necessários para evitar dependência circular. Se empresa.com é atendido por ns1.empresa.com, o pai com precisa fornecer o endereço de ns1.empresa.com junto à referência, caso contrário o resolvedor precisaria consultar a própria zona antes de saber como alcançá-la.
O registro SOA descreve propriedades administrativas da zona, como servidor principal, contato, número serial e temporizadores relacionados à transferência e ao negativo. O serial é usado por servidores secundários para detectar alterações. O desenho de alta disponibilidade normalmente publica múltiplos servidores autoritativos em redes e localidades independentes, frequentemente usando anycast para distribuir consultas.
Uma resposta autoritativa significa que o servidor responde com base na zona pela qual possui autoridade, não apenas com base em . A AA da mensagem indica essa condição em respostas apropriadas. Em , perguntar a um resolvedor recursivo e perguntar diretamente a cada autoritativo são testes diferentes: o primeiro revela a experiência do cliente; o segundo ajuda a identificar divergência entre servidores e propagação de zona.
Tabela 2 - Componentes de autoridade e delegação.
Elemento
Função
Falha típica
Zona
Unidade administrativa de dados DNS
Registro criado na zona errada
Delegação NS
Indica autoridade da zona filha
NS inconsistente ou indisponível
Glue
Fornece endereço para nameserver dentro da zona delegada
Dependência circular de resolução
SOA serial
Versiona o conteúdo da zona
Secundário não detecta atualização
Servidor autoritativo
Responde pelos dados da zona
Respostas divergentes entre réplicas
4.4 Resolução recursiva e iterativa
A aplicação normalmente não percorre a hierarquia diretamente. Ela utiliza um do sistema operacional, que envia uma consulta ao resolvedor recursivo configurado pela rede. O stub pede uma resposta final e costuma ativar a RD, recursion desired. O resolvedor recursivo consulta seu e, quando necessário, realiza as etapas para obter a resposta em nome do cliente.
Na resolução iterativa, servidores intermediários retornam a melhor informação que possuem, geralmente uma referência aos servidores da próxima zona. O recursivo começa por uma raiz, recebe referência ao TLD, consulta o TLD, recebe referência ao autoritativo e então consulta a zona final. O resultado é armazenado em conforme os TTLs dos RRsets recebidos.
O caminho exato pode ser mais complexo por causa de CNAMEs, delegações, registros adicionais e validação . Um instrui que o nome consultado é um alias de outro nome; o resolvedor precisa continuar a resolução até obter o tipo final. Cada elo possui próprio e pode apontar a uma zona administrada por outra organização ou provedor de tráfego.
Em redes corporativas, o recursivo pode atuar como forwarder e encaminhar consultas a outro resolvedor em vez de percorrer a hierarquia pública. Essa cadeia é comum em filiais, VPNs e ambientes de nuvem. Ela também cria dependências: uma regra de encaminhamento condicional incorreta pode fazer nomes privados seguirem para a Internet ou criar loops entre servidores .
Figura 2 - Exemplo simplificado de resolução recursiva com consultas iterativas.
Comandos de observação - execute apenas em ambientes autorizados
# Linux / macOS
dig api.empresa.com A
dig api.empresa.com AAAA
dig +trace api.empresa.com
dig @ns1.exemplo.net api.empresa.com A +norecurse
# Windows PowerShell
Resolve-DnsName api.empresa.com -Type A
Resolve-DnsName api.empresa.com -Type AAAA
Resolve-DnsName api.empresa.com -Server 10.0.0.10
4.5 Mensagens e resource records
A mensagem possui cabeçalho e quatro seções lógicas: Question, Answer, Authority e Additional. O cabeçalho inclui identificador, e contadores de registros. Entre as relevantes estão QR, que distingue consulta e resposta; RD e RA, relacionadas à recursão; AA, que indica resposta autoritativa; TC, que sinaliza truncamento; e o código de resposta, como NOERROR, NXDOMAIN ou SERVFAIL.
Os dados são transportados como resource records. Um RR contém nome, tipo, classe, e dados específicos. Registros com mesmo nome, tipo e classe formam um e devem ser tratados como conjunto. Essa ideia é importante em e em múltiplos registros A ou : a ordem apresentada não deve ser confundida com garantia de seleção ou afinidade.
A e associam nomes a endereços e . cria alias para outro nome e possui restrições de coexistência com outros dados no mesmo nó. NS informa servidores autoritativos. SOA descreve a zona. PTR é usado em resolução reversa. MX direciona correio. TXT transporta texto estruturado por diferentes protocolos. SRV permite descobrir host e porta de um serviço, enquanto CAA informa quais autoridades certificadoras podem emitir certificados para o domínio.
modernas também podem encontrar registros SVCB e , que permitem anunciar propriedades de um serviço, alternativas e parâmetros de conexão. O suporte depende do cliente e da plataforma; por isso, esses registros não substituem automaticamente A, ou a configuração de reverse . O arquiteto deve separar a existência do padrão da capacidade efetivamente implantada no ambiente.
Tabela 3 - Resource records frequentes em ambientes corporativos.
Tipo
Dados principais
Uso em arquitetura de APIs
A
Endereço IPv4
Endpoint público ou privado
AAAA
Endereço IPv6
Dual stack e acesso IPv6
CNAME
Nome canônico
Alias para front door, CDN ou serviço gerenciado
NS
Servidor de nomes
Delegação da zona
SOA
Metadados da zona
Serial e parâmetros administrativos
PTR
Nome associado ao IP
Resolução reversa e auditoria
SRV
Prioridade, peso, porta e alvo
Service discovery em protocolos compatíveis
CAA
CA autorizada
Governança de emissão de certificados
TXT
Texto arbitrário
Verificações de domínio e políticas
Arquivo de zona didático com blocos de documentação
; Exemplo didático de zona
$ORIGIN empresa.com.
$TTL 300
@ IN SOA ns1.empresa.com. dnsadmin.empresa.com. (
2026071501 ; serial
3600 ; refresh
600 ; retry
1209600 ; expire
300 ) ; negative cache
IN NS ns1.empresa.com.
IN NS ns2.empresa.com.
api IN A 198.51.100.25
api IN AAAA 2001:db8:20::25
status IN CNAME api.empresa.com.
4.6 , e o significado de propagação
O de um resource record informa por quanto tempo o dado pode permanecer em . Quando um resolvedor recebe um com 300, ele pode reutilizá-lo por cinco minutos sem consultar novamente a autoridade. O valor diminui no e a entrada expira ao chegar a zero. O autoritativo não envia notificações a todos os quando o registro muda; por isso, clientes diferentes podem observar respostas antigas até que suas entradas expirem.
A expressão propagação é usada de forma informal, mas pode ocultar fenômenos distintos: transferência de zona entre autoritativos, atualização de servidores de um provedor, expiração de recursivos, do sistema operacional, da aplicação e até connection para o endereço antigo. Alterar o registro no painel e confirmar o novo valor no autoritativo não garante que uma aplicação com ou conexão persistente o utilize imediatamente.
baixo reduz o período potencial de dados antigos e é útil antes de migrações, mas aumenta consultas, dependência do e carga operacional. Além disso, alguns componentes aplicam valores mínimos, máximos ou estratégias próprias de refresh. Para uma mudança planejada, o deve ser reduzido com antecedência suficiente para que o valor anterior expire nos antes do corte.
O negativo armazena conhecimento de que um nome não existe, representado por NXDOMAIN, ou de que o nome existe mas não possui o tipo solicitado, frequentemente chamado NODATA. Essa otimização reduz consultas repetidas, mas surpreende equipes que criam um registro logo após uma resposta negativa. O tempo de negativo é derivado das informações da zona conforme as regras atuais do .
Figura 3 - O permanece válido até o expirar, inclusive para respostas negativas.
Mudança segura de
Antes de trocar um endereço, reduza o , aguarde o antigo expirar, valide o novo destino, execute o corte e mantenha o destino anterior disponível durante a janela de transição quando possível.
4.7 , , EDNS e criptografado
Consultas clássicas utilizam a porta 53 tanto sobre quanto sobre . possui menor custo por não estabelecer conexão e atende grande parte das consultas. Entretanto, sobre não é apenas um mecanismo de transferência de zona: implementações precisam suportá-lo para respostas grandes, truncadas e cenários modernos. Um firewall que libera /53 e bloqueia /53 pode criar falhas seletivas difíceis de reproduzir.
No formato original, uma mensagem possuía limite prático pequeno. adiciona um pseudo-registro OPT pelo qual o solicitante anuncia recursos e o tamanho de que consegue receber. Valores exagerados podem causar fragmentação ; valores adequados procuram equilibrar eficiência e confiabilidade. Quando a resposta não cabe, o servidor pode definir a TC e o cliente tenta novamente por .
over , normalmente associado à porta 853, e over , transportado em , protegem o canal entre cliente e resolvedor contra observação ou alteração no percurso. Eles não transformam o resolvedor em autoridade confiável por si mesmos e não fornecem autenticação criptográfica dos dados de zona como . A organização precisa avaliar privacidade, governança, filtragem e observabilidade ao permitir resolvers externos ou embutido em aplicações.
Em redes corporativas, interceptar ou bloquear sem uma estratégia pode quebrar aplicações, enquanto liberá-lo indiscriminadamente pode contornar privado, e políticas de segurança. O objetivo arquitetural deve ser oferecer resolvedores corporativos confiáveis, redundantes e compatíveis com os mecanismos necessários, além de controlar explicitamente quais canais alternativos são permitidos.
Figura 4 - possui múltiplos transportes; cada um resolve um problema diferente.
Tabela 4 - Falhas relacionadas ao transporte DNS.
Sintoma
Possível causa
Teste
Consultas simples funcionam, DNSSEC falha
EDNS ou respostas grandes filtradas
dig +dnssec e captura
UDP funciona, resposta grande falha
TCP/53 bloqueado após TC=1
dig +tcp
Aplicação ignora DNS privado
DoH próprio ou resolver externo
Verificar destino DNS da aplicação
Timeout somente em uma filial
Fragmentação/MTU ou firewall DNS
Comparar payload EDNS e caminho
4.8 privado, split-horizon e service discovery
privado publica nomes que somente determinados ambientes devem resolver, como redes corporativas, VNets, e datacenters. O acesso depende de quais resolvedores e zonas estão visíveis à origem. Um private sem integração adequada pode existir e ainda ser inutilizável: a aplicação continuará resolvendo o nome para o público ou receberá NXDOMAIN.
No split-horizon, o mesmo nome retorna respostas diferentes conforme o caminho de resolução. Um cliente externo pode receber o endereço do público, enquanto o interno recebe o endereço privado do . Essa técnica preserva nomes consistentes, certificados e , mas exige disciplina para evitar divergências silenciosas entre zonas pública e privada.
Encaminhamento condicional direciona consultas de certos sufixos a resolvers específicos. Em ambiente híbrido, a VNet pode encaminhar corp.empresa para o datacenter, enquanto o datacenter encaminha privatelink ou zonas de nuvem ao resolver correspondente. Regras simétricas mal planejadas podem criar loops, e regras ausentes podem vazar nomes internos para resolvers públicos.
Service discovery em Kubernetes e service meshes também utiliza nomes e registros, mas os ciclos de vida são mais dinâmicos. Um serviço pode resolver para um ClusterIP virtual, uma lista de pods ou um de . O curto e o comportamento de do cliente tornam-se decisivos. Bibliotecas que resolvem uma vez no startup não acompanham mudanças, enquanto como Envoy podem consumir de descoberta e possuir visão explícita dos .
Figura 5 - O mesmo pode direcionar clientes públicos e privados a diferentes.
Private não é
O fornece conectividade privada. A aplicação ainda precisa resolver o nome para o endereço privado, possuir rota e passar pelas políticas de rede e .
4.9 Disponibilidade e balanceamento baseado em
O pode retornar múltiplos endereços ou escolher respostas com base em políticas de prioridade, peso, localização, desempenho e saúde. Essa técnica é usada para distribuição global e entre regiões. A decisão ocorre na resolução; depois dela, o cliente conecta diretamente ao retornado. Portanto, o serviço não observa necessariamente a conexão ou a requisição da aplicação.
O comportamento depende do resolvedor recursivo. Políticas geográficas podem enxergar o endereço do resolvedor, que pode estar distante do usuário real. O controla por quanto tempo a decisão permanece em . Durante uma falha, clientes com resposta antiga podem continuar tentando o indisponível até que o expire ou a aplicação implemente fallback próprio.
Múltiplos registros A ou não constituem, isoladamente, um balanceador com health checking. A ordem pode variar e clientes podem escolher apenas o primeiro endereço. Retirar um registro não encerra conexões existentes e não remove a entrada de todos os imediatamente. -based deve ser combinado com resilientes e monitoramento compatível com a janela de .
Anycast é outra técnica usada por infraestrutura e serviços globais. O mesmo endereço é anunciado em múltiplas localidades e o roteamento da Internet conduz o cliente a uma instância próxima conforme a topologia BGP. Anycast não é round robin de : a resposta pode conter um único , enquanto a distribuição ocorre na camada de roteamento.
Tabela 5 - Formas diferentes de distribuição global.
Estratégia
Momento da decisão
Vantagem
Limitação
Múltiplos A/AAAA
No cliente/resolvedor
Simplicidade
Saúde e escolha variam por cliente
GSLB por DNS
Durante resolução
Distribuição global e failover
TTL e visão do resolver
Anycast
Roteamento IP
Endpoint global com proximidade
Depende de anúncios e convergência
Reverse proxy global
A cada conexão/requisição
Controle L7, WAF e TLS
Tráfego passa pelo serviço
4.10 Segurança do e
O clássico foi criado em um ambiente com pressupostos de confiança diferentes dos atuais. Ataques podem explorar respostas forjadas, poisoning, servidores comprometidos, sequestro de configuração do resolver e registros administrativos alterados. Identificadores aleatórios, portas de origem imprevisíveis e validações adicionais aumentam a resistência, mas não fornecem prova criptográfica completa da origem dos dados.
acrescenta autenticação de origem e integridade aos dados por meio de assinaturas sobre RRsets e uma cadeia de confiança baseada em registros DS e DNSKEY. Um resolvedor validador consegue distinguir dados assinados válidos, respostas comprovadamente inexistentes e falhas de validação. não fornece confidencialidade: observadores ainda podem ver nomes e respostas em tradicional.
A validação depende de tempo, chaves, assinaturas e publicação correta. Uma rotação mal executada ou assinatura expirada pode transformar uma zona existente em SERVFAIL para clientes validadores. Por isso, exige monitoramento específico, sincronização de tempo e procedimentos de rollover. O benefício é reduzir a possibilidade de um intermediário apresentar dados adulterados como se fossem autoritativos.
over e over protegem o transporte até o resolvedor, enquanto protege a autenticidade dos dados entre a zona assinada e o validador. TSIG, por sua vez, autentica transações entre participantes que compartilham uma chave, como transferências e atualizações dinâmicas. Esses mecanismos são complementares e não devem ser tratados como substitutos.
rebinding
Aplicações que confiam apenas no nome recebido do usuário podem resolver inicialmente para um público e depois para um endereço interno. Controles de devem validar destinos efetivos, faixas, redirecionamentos e novas resoluções, não apenas a string do hostname.
4.11 em profundidade
Network Address Translation modifica endereços em pacotes ao atravessar um dispositivo de borda. No Basic , um endereço de um domínio é mapeado para outro endereço. No ou , a tradução inclui identificadores de transporte, permitindo que várias conexões internas compartilhem um endereço externo por meio de portas diferentes. O dispositivo mantém estado para reverter a tradução no tráfego de retorno.
Uma tradução altera campos cobertos por checksums. O precisa ajustar os checksums de e transporte conforme o protocolo. Protocolos que carregam endereços ou portas dentro do podem exigir application-level ou falhar, porque a tradução do cabeçalho não atualiza automaticamente dados internos. Criptografia que protege esses campos também limita a capacidade de tradução transparente.
não é firewall, embora frequentemente esteja no mesmo equipamento. O fato de uma conexão de entrada não possuir mapeamento não substitui política explícita de filtragem. Port forwarding e podem publicar serviços internos; conexões iniciadas de dentro criam estado; regras de firewall determinam o que deve ser permitido. Segurança deve ser modelada como política, não como efeito colateral do endereçamento.
A presença de quebra a transparência fim a fim do endereço. do mostram a identidade traduzida, e protocolos que dependem do do cliente precisam de outro mecanismo. Em , controlados podem inserir ou X- -For, mas esses cabeçalhos são metadados de aplicação e podem ser falsificados se a borda não remover valores enviados pelo consumidor.
Figura 6 - permite que fluxos internos compartilhem um endereço externo por portas distintas.
4.12 , , e CGNAT
Source altera a origem do fluxo e é comum na saída para Internet ou para uma rede parceira. Destination altera o destino e é usado para publicar um serviço interno atrás de um endereço virtual. Uma conexão pode atravessar ambos: o cliente alcança um VIP que sofre para o servidor, e o retorno pode sofrer para garantir simetria e ocultar a topologia interna.
, também chamado loopback, ocorre quando um cliente interno acessa o endereço externo de um serviço que também está na rede interna. O dispositivo precisa traduzir e conduzir o fluxo de volta para dentro. Sem suporte ou configuração correta, o cliente pode resolver o nome público, enviar ao firewall e receber retorno direto do servidor, quebrando o estado esperado. Split é frequentemente usado para evitar esse caminho.
Carrier-Grade permite que provedores compartilhem endereços entre assinantes. Em arquiteturas B2B, isso reduz a utilidade de identificar um consumidor apenas pelo público. Vários clientes podem compartilhar o mesmo endereço e o conjunto pode mudar. Allowlist por pode continuar sendo requisito de conectividade, mas não deve ser a única autenticação de uma sensível.
Double ocorre quando o fluxo atravessa traduções sucessivas, por exemplo, local, CGNAT e de nuvem. Cada estado possui seus próprios e limites de portas. precisa registrar a origem observada em cada fronteira; presumir que o da estação chegará ao produz regras e auditorias incorretas.
Tabela 6 - Modalidades de tradução e seus impactos.
Tipo
Campo alterado
Uso frequente
Risco operacional
SNAT
Origem
Saída de gateway/API para backend
Esgotamento de portas e allowlist
DNAT
Destino
VIP ou publicação de serviço
Retorno assimétrico
PAT/NAPT
IP e porta
Compartilhar endereço externo
Estado e timeout
Hairpin
Tradução de retorno interno
Acesso interno ao endereço externo
Fluxo assimétrico
CGNAT
Origem no provedor
Compartilhar IPv4 entre assinantes
IP não identifica cliente
4.13 em e ambientes de nuvem
Um cria conexões outbound para . Dependendo do modo de rede, essas conexões podem sair por endereços próprios da instância, por um , firewall, appliance ou conjunto de IPs gerenciados. O observa essa origem traduzida e precisa permitir todos os endereços possíveis. Escala, mudança de tier ou manutenção podem alterar a distribuição entre origens documentadas pela plataforma.
Esgotamento de ocorre quando muitas conexões concorrentes ou conexões curtas consomem as portas disponíveis para uma combinação de origem e destino. O problema é agravado quando connection está desabilitado, mantêm estados por muito tempo ou um único de saída atende grande volume. Sintomas incluem falha intermitente de conexão, connect e recuperação espontânea após estados expirarem.
A solução não é apenas adicionar . Retentativas agressivas podem consumir ainda mais portas. O desenho deve reutilizar conexões, dimensionar endereços e portas de saída, distribuir destinos, ajustar com critério e monitorar utilização. Quando a plataforma oferece integração privada sem ou com múltiplos IPs, a escolha deve considerar capacidade e previsibilidade de origem.
Inbound private e outbound private connectivity são direções diferentes. Um private para o permite que consumidores o alcancem privadamente; não garante que o acesse por rede privada. Cada perna exige , rota, firewall, identidade e próprios.
Diagnóstico de
Colete número de conexões novas por segundo, conexões estabelecidas, TIME_WAIT, destinos, IPs de saída, erros de connect e métricas da plataforma. Um 502 no pode ser consequência de falta de /porta antes de qualquer resposta do .
4.14 Intermediários
permite uma cadeia de intermediários. A 9110 distingue formas comuns como , e . Na prática, o vocabulário de produtos varia, mas a pergunta técnica é estável: o componente interpreta mensagens e cria uma nova conexão, ou apenas encaminha bytes após estabelecer um túnel? A resposta determina quais políticas, e transformações são possíveis.
Quando um intermediário termina , ele recebe uma mensagem completa ou um fluxo protocolar, aplica regras e envia outra mensagem ao próximo salto. Ele pode alterar Host, path, query, , codificação e versão de . O não observa diretamente o do consumidor; observa a conexão criada pelo intermediário. Essa separação explica por que o , certificado e latência medidos no representam o .
Intermediários melhoram segurança e governança ao centralizar autenticação, , , roteamento e observabilidade. Ao mesmo tempo, adicionam filas, , , limites de e pontos de falha. Cada camada deve possuir propósito claro. Empilhar , , Application , , ingress e sem definir responsabilidades produz duplicidade de , e regras contraditórias.
Um também modifica a semântica de falha. Se não consegue conectar ao , pode retornar 502. Se o pool está indisponível, pode retornar 503. Se o excede , pode retornar 504. O código recebido pelo cliente pode ter sido criado pelo intermediário e não pela aplicação. correlacionados por ID são essenciais para localizar o emissor.
4.15 , , e túnel
O representa clientes. Ele é configurado no sistema ou aplicação e recebe uma de destino. Empresas o utilizam para controle de saída, filtragem, inspeção e autenticação. Para , o cliente pode usar o método CONNECT para solicitar um túnel até o destino; nesse caso o conhece host e porta, mas não necessariamente interpreta o criptografado. Em inspeção corporativa, o termina e emite um certificado aceito pela instalada no cliente.
O representa servidores. O cliente acredita estar conectando ao serviço final, mas a conexão termina no , que escolhe um . NGINX, HAProxy, Envoy, Application , Front Door e podem atuar assim. O controla certificados, virtual hosts, roteamento por path, compressão, e proteção, desde que a camada de aplicação esteja visível.
O termo em descreve um intermediário que atua como origem para a conexão de entrada e traduz ou conecta a outro serviço. Um amplia essa ideia com políticas de segurança, quotas, transformação e ciclo de vida de . Ele pode receber / e chamar , JMS ou outro , ocultando a implementação. O termo não deve ser confundido com padrão de roteamento .
Um túnel encaminha bytes sem interpretar o protocolo após sua criação. pass-through em um balanceador L4 se aproxima desse modelo: o ocorre com o . A vantagem é preservar autenticação e criptografia ponta a ponta; a limitação é que o intermediário não consegue aplicar regras baseadas em método, path, ou conteúdo .
Figura 7 - Intermediários se diferenciam pela entidade representada e pelo nível de interpretação.
4.16 Camada 4, camada 7 e terminação
Um balanceador ou de camada 4 decide com base em informações de transporte, como endereço, porta e estado do fluxo. Ele pode encaminhar ou sem compreender a aplicação. Essa abordagem suporta protocolos variados e reduz acoplamento ao . Quando permanece intacto, o certificado e a negociação pertencem ao , e o intermediário não consegue inspecionar paths ou .
Na camada 7, o componente compreende o protocolo de aplicação. Em , pode rotear por Host, , método, ou ; aplicar ; reescrever mensagens; e gerar respostas. Para isso, em normalmente termina . A conexão de pode ser , ou , formando uma segunda sessão com parâmetros e confiança independentes.
offload remove criptografia no trecho interno e simplifica o , mas deixa dados em texto claro na rede após o . Re-encryption mantém nos dois trechos, porém não é ponta a ponta: o tem acesso ao conteúdo e apresenta sua própria identidade ao . Certificados, , versões e cipher suites precisam ser configurados em ambos os lados.
Quando o cliente usa com o , o certificado do cliente não é automaticamente apresentado ao . O pode autenticar o cliente e propagar atributos por ou , desde que o confie exclusivamente nesse e a conexão seja protegida. A 9440 documenta padronizados para transportar informações de certificado em cenários de com terminação , mas o modelo de confiança precisa ser explicitamente protegido.
Figura 8 - Cada modo de define fronteiras de confiança diferentes. Figura 9 - Camada 4 distribui fluxos; camada 7 pode tomar decisões sobre .
4.17 Host, , e cabeçalhos encaminhados
Virtual hosting permite que vários serviços compartilhem um endereço. Antes de enviar sobre , o cliente pode incluir no ClientHello para indicar o hostname desejado, permitindo que o terminador selecione certificado e configuração. Depois do , o contém a autoridade da requisição, normalmente refletida no Host em /1.1 ou no pseudo- :authority em /2.
e Host pertencem a camadas diferentes e podem divergir por erro ou ataque. O balanceador pode selecionar certificado por e rota por Host. Configurações devem validar combinações permitidas para evitar encaminhamento indevido. Quando o chama o por hostname diferente, precisa decidir se preserva o Host original ou usa o nome do . Essa escolha afeta virtual hosts, redirects, e validação de certificado.
Reverse inserem metadados como X- -For, X- -Proto e X- -Host. A 7239 define o como forma padronizada de transportar informações perdidas no proxying. Entretanto, qualquer cliente pode enviar com esses nomes. A borda confiável deve remover ou reconstruir valores recebidos e o deve confiar apenas em conhecidos.
O original também pode ser preservado em camada 4 por mecanismos como protocol, quando suportados. Isso altera o protocolo esperado no primeiro bytes da conexão e precisa ser habilitado de forma consistente nos dois lados. Enviar protocol a um listener que espera ou resulta em falhas imediatas e mensagens de protocolo inválido.
Exemplo didático de metadados adicionados por uma borda confiável
Defina a lista de confiáveis e calcule o cliente a partir da cadeia conhecida. Caso contrário, o consumidor pode inserir um arbitrário e influenciar auditoria, ou autorização.
4.18 Fundamentos de
distribui trabalho entre múltiplos destinos para utilizar capacidade, tolerar falhas e permitir escala. Ele não acelera uma única operação por mágica: uma requisição específica ainda é processada por uma instância. O ganho surge da execução concorrente e da remoção de incapazes de atender novas solicitações.
O conjunto de destinos é chamado pool, ou set, conforme o produto. Antes de aplicar um algoritmo, o balanceador determina quais são elegíveis por configuração, prioridade, localidade e saúde. O algoritmo seleciona entre esses candidatos. Portanto, uma distribuição inesperada pode ser causada não pelo round robin, mas por metade do pool estar marcada como unhealthy.
Balanceamento pode ocorrer por conexão ou por requisição. Em L4, uma decisão costuma ser tomada quando o fluxo é criado e permanece até o encerramento. Em /1.1, o pode reutilizar conexões de e selecionar por requisição. Em /2, várias requisições são multiplexadas em poucas conexões, o que pode alterar a relação entre número de conexões e carga real.
O escopo pode ser local ou global. Um balanceador regional distribui entre instâncias próximas. Um sistema global seleciona região por , anycast ou de borda. Arquiteturas robustas frequentemente combinam as duas camadas: uma decisão global escolhe a região e um balanceador local escolhe a instância.
4.19 Algoritmos de seleção de
Round robin distribui seleções em sequência e funciona bem quando servidores possuem capacidades semelhantes e o custo das requisições é relativamente homogêneo. Weighted round robin atribui proporções diferentes, permitindo que uma instância maior receba mais tráfego ou que uma nova versão seja introduzida gradualmente. Pesos não garantem percentuais exatos em janelas pequenas.
escolhe o destino com menos conexões ativas. É útil quando conexões possuem durações variáveis, mas a contagem pode não representar trabalho real em /2 ou quando uma conexão contém muitas operações. Least e least time procuram aproximar carga ou latência observada, porém precisam evitar oscilações e decisões baseadas em métricas ruidosas.
seleciona o destino a partir de uma chave, como , , ou identificador. Ele fornece afinidade determinística enquanto o conjunto permanece estável. Quando entram ou saem, um simples pode remapear grande parte das chaves. Consistent e algoritmos como ring ou Maglev procuram reduzir remapeamento, sendo úteis para e dados localizados.
Power of two choices seleciona dois candidatos aleatórios e escolhe o menos carregado, obtendo boa distribuição com menor custo que examinar todo o pool. Produtos modernos também combinam prioridade, localidade, pesos dinâmicos, outlier detection e circuit breaking. A escolha deve ser validada com o padrão real de tráfego, não apenas com uma definição abstrata.
Figura 10 - Algoritmos diferentes otimizam padrões de carga diferentes.
Tabela 7 - Critérios para escolha do algoritmo.
Algoritmo
Sinal usado
Indicado quando
Cuidado
Round robin
Sequência
Instâncias e requisições semelhantes
Ignora carga atual
Weighted RR
Peso estático/dinâmico
Capacidades diferentes
Pesos incorretos concentram carga
Least connections
Conexões ativas
Sessões de duração variável
HTTP/2 distorce a métrica
Least response time
Latência e atividade
Desempenho variável
Pode oscilar
Hash
Chave da requisição
Afinidade e cache local
Remapeamento e hotspots
Consistent hash
Anel/tabela estável
Reduzir churn de afinidade
Mais complexidade
4.20 , readiness, drenagem e
determinam se um deve receber tráfego. Um check confirma que a porta aceita conexão, mas não prova que a aplicação consegue consultar banco, validar ou responder uma operação crítica. Um check pode verificar um path, status e conteúdo. O de saúde deve refletir readiness para o tráfego que será enviado, sem causar carga excessiva ou depender de componentes irrelevantes.
Liveness e readiness respondem a perguntas diferentes. Liveness indica se o processo deve ser reiniciado. Readiness indica se está pronto para receber novas requisições. Misturar os dois pode criar loops: uma dependência temporariamente indisponível torna liveness falso, o orquestrador reinicia todas as instâncias, e a recuperação fica ainda mais difícil.
Thresholds evitam remoção por uma falha isolada e retorno prematuro após um único sucesso. Intervalo, , número de falhas e número de sucessos definem a velocidade de detecção e recuperação. Checks muito agressivos podem gerar falsos negativos durante picos; checks lentos mantêm instâncias quebradas no pool por mais tempo.
Drenagem remove o de novas seleções enquanto permite que conexões existentes terminem. Slow start aumenta o peso gradualmente após startup ou recuperação, evitando enviar carga total a frios e runtimes ainda aquecendo. Em , readiness, pre-stop, connection draining e máximo da aplicação devem ser coordenados para evitar resets.
Figura 11 - Um percorre estados que influenciam elegibilidade e peso.
de
Uma verificação de porta pode marcar o como saudável mesmo quando o repositório de configuração, ou críticos estão indisponíveis. Projete checks por camada e monitore também a experiência ponta a ponta.
4.21 Afinidade, estado e connection
direciona requisições relacionadas ao mesmo , normalmente por , ou . Ela pode ser necessária para sistemas legados com sessão em memória, mas reduz liberdade de distribuição e complica . idealmente mantêm estado de sessão em mecanismos compartilhados ou , permitindo que qualquer instância processe a chamada.
Afinidade por é frágil atrás de e , pois muitos consumidores podem aparecer com a mesma origem. Usuários móveis podem mudar de , e pode utilizar múltiplos endereços temporários. -based affinity oferece chave mais específica, mas precisa considerar domínio, Secure, SameSite e o comportamento quando o sai do pool.
Connection reutiliza conexões do para o e reduz / , latência e consumo de portas . Porém, pools muito pequenos podem concentrar tráfego, e conexões persistentes podem manter um endereço resolvido antes de uma mudança . A política de refresh , lifetime das conexões e idle precisa ser compatível com e rotação de .
/2 multiplexa diversas em uma conexão. Se o mantiver uma única conexão /2 por , métricas de conexões deixam de representar a quantidade de requisições. O algoritmo, os limites de e a criação de múltiplas conexões precisam ser observados. A mesma preocupação vale para , e long , que possuem durações e padrões distintos.
Tabela 8 - Estado e persistência alteram a distribuição.
Mecanismo
Benefício
Efeito colateral
Cookie affinity
Sessão estável
Dependência de backend e failover
IP hash
Sem cookie
NAT concentra clientes
Connection pooling
Menos handshake e SNAT
Conexões antigas e concentração
HTTP/2 multiplexing
Alta eficiência
Conexão não representa carga
Draining
Deploy sem interrupção abrupta
Precisa de timeout coordenado
4.22 Arquitetura com múltiplas camadas
Uma arquitetura de pode conter / , ou Front Door, , regional, , ingress controller, service mesh e aplicação. Cada camada pode terminar , gerar , fazer e aplicar . O desenho precisa definir uma matriz de responsabilidades: quem autentica o cliente, quem aplica , quem seleciona região, quem seleciona instância, quem preserva o Host e quem gera o ID.
em múltiplas camadas multiplicam tráfego. Se cliente, Front Door, e service mesh tentam três vezes, uma única operação pode produzir dezenas de chamadas ao . Em operações não idempotentes, isso também cria risco funcional. O orçamento de deve diminuir ao longo da cadeia para que camadas externas ainda tenham tempo de processar a falha e responder.
A observabilidade deve registrar timestamps, endereço, hostname, protocolo, status originado, selecionado, duração de conexão e duração de resposta. Um identificador de correlação deve ser criado na borda ou preservado de forma controlada. precisam distinguir status do e status do , além de connect , error, reset e .
Alta disponibilidade exige eliminar single points of failure na própria camada de . Múltiplas instâncias atrás de , configuração consistente e são necessários. Componentes , distribuídos e bancos de configuração precisam de desenho próprio; duplicar apenas o listener não garante que a plataforma continue operando durante falha de dependência.
Figura 12 - Cada salto toma decisões e pode alterar a identidade observada.
Tabela 9 - Exemplo de divisão de responsabilidades.
Camada
Responsabilidade recomendada
Evitar duplicidade de
DNS/GSLB
Escolha global e failover de endpoint
Regras de aplicação
Borda/WAF
Proteção pública, TLS, roteamento amplo
Autorização de negócio
API Gateway
Autenticação, quotas, transformação, governança
Balanceamento global improvisado
LB/Ingress
Distribuição local e health
Políticas de identidade duplicadas
Service mesh
Resiliência service-to-service e mTLS interno
Retries sem orçamento
Aplicação
Regra de negócio e estado funcional
Confiança em headers não validados
4.23 Aplicação em Axway e Azure
Axway
Em uma implantação Axway de alta disponibilidade, múltiplas instâncias de ficam atrás de um balanceador que executa e distribui a carga. O balanceador deve preservar ou reconstruir corretamente host, protocolo e identidade de origem conforme o desenho. Afinidade deve ser usada somente quando um recurso realmente depende dela; políticas e estado compartilhado precisam ser avaliados separadamente.
No roteamento outbound, filtros como Connect to fazem o atuar como para o cliente e chamar o destino configurado, ocultando a hierarquia de implantação. Remote Host Settings controlam como o se conecta a destinos específicos, incluindo conexões, e parâmetros relacionados. A resolução e o pool de conexões podem fazer com que alterações de não sejam percebidas imediatamente.
Quando a saída exige corporativo, a configuração de define um intermediário adicional. O diagnóstico precisa separar conexão - e -destino. Em topologias com na frente e na saída, o está entre duas formas de intermediação, cada uma com , e próprios.
Operações de manutenção devem coordenar drenagem no e shutdown controlado da instância para evitar interrupção de conexões ativas. A documentação da Axway também permite configurar endereços e opções de em integrações específicas do Manager; esses parâmetros devem ser validados conforme a versão em uso.
Aplicação prática em Axway
Ao investigar 502 ou connect , registre: hostname configurado no filtro, resposta vista pelo processo, endereço selecionado, Remote Host Settings aplicadas, outbound, pool de conexões e origem observada pelo .
Serviços Azure e Management
Azure oferece serviços de distribuição com propósitos diferentes. Traffic Manager toma decisões por e o cliente conecta diretamente ao retornado. Azure Front Door é um global de camada 7, com aceleração, , roteamento e . Azure opera principalmente em camada 4. Application atua como regional de camada 7 para / , com roteamento por Host/path e , além de capacidades L4 em cenários suportados pela plataforma.
Azure Management é uma plataforma de gerenciamento de cujo aplica políticas, autenticação, transformação e observabilidade. Ele não substitui automaticamente um ou serviço de distribuição global. Um desenho comum posiciona Front Door ou Application diante do , mas health probes precisam utilizar o hostname correto, porque virtuais podem não responder a probes por e Host padrão.
Em modo interno, os do exigem acessível dentro da VNet. Application na frente do precisa de custom probes e configuração de compatível com o hostname e certificado. No caminho outbound, o precisa resolver privados e possuir conectividade à rede correspondente. Configurar apenas a exposição inbound não resolve a perna de .
A escolha entre Traffic Manager e Front Door ilustra a diferença conceitual: Traffic Manager responde e não vê o tráfego da aplicação; Front Door permanece no caminho como . Isso altera origem observada, , , , e capacidade de roteamento.
Figura 13 - Serviços Azure se diferenciam por escopo, camada e permanência no caminho.
Tabela 10 - Mapeamento conceitual de serviços Azure.
Serviço
Escopo/camada
Permanece no caminho?
Uso principal
Traffic Manager
Global por DNS
Não
Escolher endpoint por política e saúde
Front Door
Global L7
Sim
Reverse proxy, WAF, TLS e aceleração
Load Balancer
Regional L4
Sim
Distribuir fluxos TCP/UDP
Application Gateway
Regional L7
Sim
Host/path routing, WAF e TLS
API Management
API Gateway
Sim
Segurança, políticas e governança de APIs
4.24 sistemático
O diagnóstico deve seguir a ordem real da chamada. Comece no ambiente do consumidor ou do runtime que falha, não em uma estação diferente. Registre o nome consultado, servidor utilizado, resposta A/ / , e . Em seguida, identifique o endereço de destino, rota, , terminação , Host e selecionado.
Compare uma chamada bem-sucedida e uma chamada com falha. Diferenças em resolvedor, família , endereço retornado, origem ou instância de pool costumam revelar intermitência. Para 502, determine se houve falha , connect error, error, reset ou resposta inválida. Para 503, verifique se o pool está sem saudáveis ou se a própria política gerou indisponibilidade. Para 504, compare em todas as camadas.
Ferramentas de captura e precisam ser usadas de forma autorizada e com filtros mínimos. dig ou Resolve-DnsName observam ; curl -v mostra resolução, conexão, e ; openssl s_client ajuda a analisar e cadeia; ss/netstat mostra ; tcpdump/Wireshark confirma endereços e resets; métricas do balanceador mostram health e selection. Nenhuma ferramenta isolada explica toda a cadeia.
O objetivo não é apenas restaurar o serviço, mas produzir uma causa verificável. Documente a configuração que gerou a falha, evidências, mecanismo técnico, correção permanente e monitoramento que detectará recorrência. Limpar , reiniciar ou aumentar pode mascarar o problema sem corrigir a arquitetura.
Comandos de diagnóstico - use apenas em sistemas e destinos autorizados
# DNS
dig api.empresa.com A +noall +answer
dig api.empresa.com AAAA +noall +answer
dig api.empresa.com +tcp
dig api.empresa.com +dnssec
# Rede e sockets
ip route get 198.51.100.25
ss -tan state established
ss -tan state time-wait
Tabela 11 - Sintomas e linhas iniciais de investigação.
Sintoma
Hipóteses prioritárias
Evidências
NXDOMAIN após criar registro
Cache negativo ou zona errada
SOA, TTL negativo, consulta autoritativa
Funciona por IP, falha por nome
DNS, SNI, Host ou certificado
dig, curl --resolve, s_client
Alguns clientes usam endpoint antigo
TTL/cache/conexão persistente
TTL restante e pool de conexões
502 intermitente
DNS múltiplo, TLS upstream, SNAT, reset
Backend escolhido e erro detalhado
503 no balanceador
Todos unhealthy ou pool vazio
Status de health e probe logs
504 após tempo fixo
Timeout em uma camada
Duração e emissor do status
Backend vê IP do proxy
Reverse proxy ou SNAT
Headers confiáveis e captura
Distribuição desigual
Keep-alive, HTTP/2, afinidade, pesos
Requisições por backend e conexões
Health verde, API falha
Probe superficial
Testar dependências e path real
Somente respostas grandes DNS falham
TCP/53, EDNS ou fragmentação
TC flag, dig +tcp, captura
Árvore de decisão para uma falha de
O nome resolve no mesmo runtime que executa a chamada? Registre servidor , resposta, e aliases.
O endereço resolvido é o esperado para esse ambiente e família ?
A conexão é criada? Caso não, analise rota, firewall, , e capacidade de portas.
O termina? Valide , certificado, , hostname e na perna correta.
O recebe ? Identifique o componente que gerou o status e o ID.
O pool possui saudáveis e o probe representa readiness real?
Qual foi escolhido e qual Host/path/ foi enviado?
O respondeu, resetou ou excedeu ?
A resposta retornou pelo mesmo estado de e pelas mesmas camadas?
A correção elimina a causa ou apenas força novo /conexão?
4.25 Estudos de caso
Caso 1 - Alteração de sem reduzir
Uma equipe troca o registro .empresa.com do balanceador antigo para o novo durante uma mudança. O anterior era de 3600 segundos. Testes feitos diretamente no autoritativo mostram o endereço novo, mas parte dos consumidores continua no antigo por quase uma hora. Reiniciar uma estação parece resolver, enquanto aplicações em contêiner mantêm conexões antigas.
A causa combina recursivo válido e connection . O plano correto seria reduzir o com antecedência, aguardar expiração, manter os dois compatíveis durante a transição e observar tráfego por endereço. O evento demonstra que atualização autoritativa não equivale a adoção imediata por todos os clientes.
Caso 2 - interno marcado como unhealthy pelo Application
Um Application utiliza o privado do Management como e o probe padrão envia Host incompatível. O responde somente aos hostnames configurados, e o probe considera o indisponível. Usuários recebem 502 ou 503 mesmo que o esteja operacional quando acessado com o hostname correto.
A correção é criar custom probe com host e path adequados, configurar settings e garantir resolução/certificado. O caso mostra que de camada 7 precisa reproduzir a autoridade esperada e não apenas alcançar o .
Caso 3 - Esgotamento de causado por conexões curtas
Um chama um externo e abre nova conexão para quase toda requisição. Durante pico, novas conexões começam a falhar de forma intermitente. O não mostra saturação, e elevam ainda mais o volume. Métricas revelam grande quantidade de TIME_WAIT e consumo de portas no de saída.
A solução envolve connection , , dimensionamento de , ajuste de e monitoramento de portas. Aumentar o não cria portas e pode prolongar estados. O caso relaciona conceitos dos capítulos de e ao comportamento do .
Caso 4 - X- -For falsificado
Uma aplica pelo primeiro valor de X- -For, mas o apenas acrescenta o observado ao final do recebido. Um consumidor envia X- -For com endereços arbitrários e alterna o primeiro valor para contornar limite e poluir auditoria.
A borda deve remover não confiáveis e criar a cadeia a partir do observado. O deve configurar confiáveis e selecionar a posição correta. Identidade forte deve vir de autenticação, não de um controlável pelo cliente.
Caso 5 - Distribuição desigual com /2
O balanceador usa entre três . Um cliente abre poucas conexões /2 e envia milhares de pela mesma conexão. O contador de conexões não reflete a carga por requisição, e uma instância recebe parcela desproporcional do trabalho.
A investigação compara e requisições por , não apenas . A solução pode envolver balanceamento por requisição no L7, múltiplas conexões, limites de ou algoritmo baseado em /latência. O algoritmo deve ser compatível com o protocolo.
Aplicação no mundo bancário
Em integrações financeiras, , origem de rede, e identificação da instituição são controles diferentes. Allowlist de reduz superfície, autentica a entidade no canal e / autoriza operações. Nenhum deles deve ser usado como substituto automático dos demais.
Laboratórios de observação
Os laboratórios devem ser executados em ambiente próprio ou autorizado. Use domínios de documentação, serviços locais ou recursos de laboratório. Não faça varredura nem tente contornar controles corporativos. Registre previsões antes de executar comandos e compare com os resultados.
Para cada laboratório, anote horário, resolvedor, resposta , , endereço de destino, protocolo, terminador , Host, status, servidor escolhido e duração. Essa disciplina transforma comandos isolados em evidência arquitetural.
Consulte A, , , NS e SOA de um domínio sob seu controle. Identifique autoridade e TTLs.
Execute uma resolução normal e depois uma consulta direta ao autoritativo. Compare AA, RD e RA.
Use dig + e compare com . Observe tamanho, tempo e presença de EDNS.
Crie em laboratório um registro com baixo, altere o valor e acompanhe o restante no .
Teste uma resposta NXDOMAIN e observe por quanto tempo ela permanece em .
Configure dois nomes locais que apontem para o mesmo e roteie por Host.
Em Docker ou rede local, configure NGINX/HAProxy com dois e observe round robin e .
Desative um e verifique quantos checks são necessários para removê-lo do pool.
Habilite e compare número de e com conexões novas por requisição.
Simule uma troca de mantendo o antigo ativo e documente a janela de coexistência.
Adicione um X- -For no cliente e confirme se a borda de laboratório o remove ou preserva.
Desenhe uma arquitetura com global, , e dois , indicando quem termina e gera o ID.
Resumo do capítulo
é uma base distribuída e hierárquica de RRsets, não apenas uma agenda de IPs.
Zonas e domínios não são idênticos; delegações distribuem autoridade por registros NS e glue quando necessário.
O stub usa um recursivo, que pode consultar raiz, TLD e autoritativo ou encaminhar a outro resolvedor.
controla ; mudanças não invalidam instantaneamente entradas já armazenadas.
NXDOMAIN e ausência de tipo também podem ser armazenados em .
precisa funcionar sobre e ; EDNS amplia capacidades e respostas grandes podem exigir fallback.
privado e split-horizon exigem visibilidade de zona, forwarding e controle de loops.
Balanceamento por toma decisão antes da conexão e é limitado por e comportamento do resolver.
traduz endereços e portas com estado; não é substituto de firewall ou autenticação.
altera a origem observada e pode sofrer esgotamento de portas.
termina uma conexão e cria outra; um túnel apenas encaminha bytes após ser estabelecido.
L4 decide por fluxo; L7 pode interpretar , terminar , rotear por Host/path e aplicar .
e X- -* só são confiáveis quando reconstruídos por conhecidos.
O algoritmo seleciona entre elegíveis; definem esse conjunto.
Round robin, e atendem padrões diferentes de carga.
Readiness, draining e slow start são necessários para e recuperação sem avalanche.
Connection reduz e , mas influencia , distribuição e .
Em Azure, Traffic Manager, Front Door, , Application e possuem papéis distintos.
Em Axway, inbound, filtros de roteamento, remote hosts e outbound devem ser analisados por perna.
Checklist de arquitetura
Qual cada consumidor usa e qual zona é autoritativa?
Quais resolvers são usados por clientes, e ?
Existem respostas públicas e privadas para o mesmo nome?
Quais TTLs positivos e negativos foram definidos?
/53 e /53 funcionam em todos os caminhos necessários?
é validado e monitorado quando adotado?
Qual componente executa e quais IPs podem ser observados pelo ?
A capacidade de portas suporta o pico e os ?
Onde cada conexão / termina?
Qual hostname é usado em , Host e validação de certificado?
Quais são removidos e reconstruídos na borda?
Qual camada escolhe região e qual escolhe instância?
O testa readiness real e usa Host/path corretos?
Há thresholds, draining e slow start?
O algoritmo é adequado para /2, , e conexões longas?
Afinidade é realmente necessária? Onde o estado é mantido?
Connection pools respeitam alterações e ?
e possuem orçamento coordenado?
distinguem status do e status do ?
Existe ID ponta a ponta e métricas por ?
Exercícios de fixação
Diferencie domínio, zona, e servidor autoritativo.
Explique por que um pode terminar com ponto e o risco de omiti-lo em arquivo de zona.
Descreva o fluxo entre , recursivo, raiz, TLD e autoritativo.
Diferencie consulta recursiva e iterativa.
Qual é a diferença entre NXDOMAIN e NODATA?
Explique a função das AA, RD, RA e TC.
Compare A, , , NS, SOA, PTR, SRV e CAA.
Por que múltiplos registros A não garantem balanceamento uniforme?
Explique como e connection podem manter uso de um antigo.
Por que liberar somente /53 pode quebrar ?
Qual problema resolve e qual risco surge com muito grandes?
Compare , , e TSIG.
Como split-horizon ajuda e quais riscos operacionais cria?
Diferencie Basic , , e .
Por que não deve ser tratado como mecanismo de autenticação?
Explique esgotamento de e a relação com connection .
Diferencie , , e túnel.
Compare pass-through, offload e re-encryption.
Por que terminado no não é automaticamente até o ?
Diferencie e Host e explique como cada um participa do roteamento.
Como deve ser estabelecida a confiança em X- -For?
Compare balanceamento L4, L7 e por .
Quando round robin, e consistent são apropriados?
Diferencie liveness, readiness e externo.
Explique como /2 pode tornar inadequado.
Qual a diferença entre Azure Traffic Manager e Azure Front Door?
Por que o probe padrão de um Application pode falhar contra interno?
Quais elementos devem ser coletados para investigar um 502 no ?
Questões de cenário
Uma muda de 203.0.113.10 para 203.0.113.20, mas 15% dos clientes continuam no endereço antigo. Proponha hipóteses e um plano de evidências.
O privado retorna 10.20.5.10 para VMs, mas o resolve o endereço público. Desenhe o caminho de resolução e os pontos a verificar.
Um permite apenas um de saída, porém o usa três origens. Explique por que a falha parece intermitente e proponha solução.
Um considera o saudável por , mas a retorna 500 por banco indisponível. Projete checks adequados.
Um cliente usa até o , e o precisa conhecer a identidade do certificado. Defina um modelo de propagação confiável.
Uma aplicação exige affinity por , mas consumidores estão atrás de CGNAT. Analise o risco e proponha alternativa.
Uma arquitetura possui no cliente, Front Door, e service mesh. Calcule o potencial de multiplicação e proponha orçamento.
Após habilitar /2 entre e , a distribuição por fica desigual. Explique o mecanismo e possíveis ajustes.
Glossário técnico
Tabela 12 - Glossário do capítulo.
Termo
Definição
Authoritative server
Servidor que responde com autoridade sobre uma zona.
CNAME
Registro que define um nome como alias de outro nome canônico.
Delegação
Transferência de autoridade de uma parte da árvore DNS para outra zona.
DNAT
Tradução do endereço ou porta de destino.
DNSSEC
Extensões que fornecem autenticação de origem e integridade para dados DNS.
DoH
Transporte de mensagens DNS sobre HTTPS.
DoT
Transporte de mensagens DNS sobre TLS.
EDNS(0)
Mecanismo extensível que anuncia capacidades e payload UDP DNS.
Forward proxy
Intermediário que representa clientes diante de destinos.
Forwarded
Header HTTP padronizado para metadados de proxying.
FQDN
Nome de domínio totalmente qualificado.
Glue record
Endereço fornecido pelo pai para alcançar nameserver dentro da zona delegada.
GSLB
Distribuição global de tráfego, frequentemente baseada em DNS e saúde.
Hairpin NAT
Tradução que permite a cliente interno acessar o endereço externo de serviço interno.
Health check
Teste usado para decidir se um endpoint deve permanecer elegível.
Least connections
Algoritmo que escolhe o endpoint com menos conexões ativas.
NAPT/PAT
Tradução que inclui endereços e portas de transporte.
Negative caching
Cache de inexistência de nome ou tipo DNS.
Recursive resolver
Servidor que obtém a resposta final em nome do cliente e mantém cache.
Reverse proxy
Intermediário que representa servidores e seleciona upstream.
RRset
Conjunto de registros com mesmo nome, classe e tipo.
Session affinity
Mecanismo que tenta manter requisições relacionadas no mesmo backend.
SNI
Indicação de hostname enviada durante o handshake TLS.
SNAT
Tradução do endereço ou porta de origem.
Split-horizon DNS
Respostas diferentes para o mesmo nome conforme o ambiente de resolução.
Stub resolver
Componente local que envia consultas a um resolvedor recursivo.
TTL
Tempo pelo qual dados DNS podem permanecer em cache.
Tunnel
Intermediário que encaminha bytes após estabelecer um túnel.
Upstream
Destino ao qual proxy ou gateway encaminha tráfego.
Zone
Porção administrada do espaço de nomes DNS.
Referências oficiais e leituras recomendadas
As especificações abaixo são as fontes primárias para os conceitos apresentados. antigas continuam fundamentais, mas devem ser lidas junto às atualizações indicadas na página do Editor. Documentações de produto mudam com o tempo; valide a versão e o modo de implantação em uso antes de aplicar uma configuração.
A leitura recomendada começa por 1034 e 1035, segue para terminologia e , depois transportes e . Para intermediários , leia a arquitetura da 9110 e os . Em seguida, compare as documentações de e as referências oficiais de Axway e Azure.
1034 - Domain Names: Concepts and Facilities
1035 - Domain Names: Implementation and Specification
2308 - of Queries
6891 - Extension Mechanisms for ( )
7766 - Transport over
9499 - Terminology
4033 - Security Introduction and Requirements
4034 - Resource Records for
4035 - Protocol Modifications
7858 - over
8484 - Queries over
3022 - Traditional Network Address Translator
4787 - Behavioral Requirements for
5382 - Behavioral Requirements for
9110 - Semantics
7239 - Extension
9440 - Client-Cert Field
- Service Name and Port Number Registry
- Technical requirements for authoritative name servers
NGINX -
Envoy - Overview
Axway - Configure High Availability
Axway - Routing Filters
Axway - Remote Host Settings
Axway - Configure Servers
Azure Overview
Azure Application Overview
Azure Traffic Manager Overview
Azure Front Door Overview
Azure Management Virtual Network Concepts
Integrate Management internal VNet with Application
Azure
Próximo capítulo
O Capítulo 5 aprofundará /1.1, /2 e /3: estrutura de mensagens, semântica, conexões persistentes, , compressão de cabeçalhos, e impactos em .
