Cloudflare

O DNS autoritativo mantém os registros que orientam a resolução do domínio. Quando um registro está com proxy habilitado, sua resposta aponta para a rede Cloudflare, em vez de encaminhar o visitante diretamente ao endereço da origem. Resolver o nome e estabelecer a conexão são etapas distintas, ainda que ambas participem do mesmo acesso.

Na rede Anycast, um endereço pode ser anunciado a partir de diferentes pontos de presença. O roteamento da internet determina qual caminho será usado; o destino não é necessariamente o local geograficamente mais próximo. Essa distribuição aproxima a entrega de muitos visitantes e permite que a proteção aconteça antes do ambiente da aplicação.

Existem dois trechos a considerar: do navegador até a borda e da borda até a origem. O transporte cifrado e a verificação dos certificados precisam proteger essa cadeia, preservando confidencialidade e autenticidade da comunicação. Proteger apenas a conexão visível no navegador deixaria incompleto esse cuidado.

A política aceita TLS a partir de 1.2, com TLS 1.3 habilitado. HTTP/3 está disponível para a conexão entre visitantes compatíveis e a borda. HSTS declara o uso obrigatório de HTTPS por um ano, incluindo subdomínios, nos navegadores que recebem essa política. Transporte seguro protege a comunicação; não valida dados nem concede permissões dentro do sistema.

A mitigação de DDoS e a filtragem de requisições atuam sobre problemas diferentes. Um ataque volumétrico tenta consumir capacidade; uma requisição maliciosa pode explorar um caminho específico mesmo com pouco tráfego. As regras de borda complementam a mitigação distribuída com decisões sobre as características do acesso.

A limitação de requisições contém rajadas automatizadas e a filtragem avalia características do acesso, sem barrar o uso legítimo. O que a borda libera ainda passa pela validação e pela autorização do servidor.

Quando existe uma cópia válida de um recurso elegível no cache, a borda responde sem buscar o conteúdo na origem, o que reduz transferências repetidas e trabalho na aplicação. O acerto depende das regras, da validade da cópia e da versão solicitada: nem toda resposta é cacheável.

Arquivos públicos e respostas personalizadas têm necessidades diferentes. Cache longo pode fazer sentido para recursos imutáveis; conteúdo que depende de permissões ou dados particulares exige outros critérios. A validade deve acompanhar a natureza da resposta, sem aplicar uma regra indiscriminada a todo o projeto.

Uma camada de borda faz parte de uma proteção maior. Reduzir a exposição da origem preserva o controle da entrada e separa a entrega pública do ambiente da aplicação, resultado que depende da arquitetura por trás do domínio, e não apenas do proxy na frente dele.

Essa restrição de rede tem um objetivo específico: controlar por onde o tráfego web chega. Ela não autentica usuários e não corrige uma falha de autorização no código. Permissões, isolamento e validação no servidor continuam responsáveis pelo que cada requisição pode fazer depois de atravessar a borda.

DNS, transporte, filtragem, cache e controle de origem compõem a base de entrada dos projetos Daen. Cada camada resolve uma parte do problema e muda quando a aplicação muda: uma regra adequada para arquivos públicos costuma ser inadequada para login, formulários ou respostas com dados particulares.

A Cloudflare participa dessa arquitetura como serviço de borda. Desenvolvimento seguro, atualização do ambiente, cópias de segurança e recuperação dos dados seguem com a operação Daen: o fornecedor de borda cobre o caminho até a origem, não o que acontece depois dela.