← AWS Advanced Networking: redes e produção
22 / 22 · 120 MIN

DNSSEC e DNS Firewall: confiança, filtragem e recuperação

Planeia a cadeia de confiança DNS, interpreta falhas e distingue validação criptográfica de decisões de filtragem.

1. Definir o que cada controlo prova

DNSSEC permite validar origem e integridade de dados DNS assinados. Não cifra o nome consultado nem classifica o destino como adequado à organização. Um domínio malicioso pode ter uma cadeia DNSSEC válida. DNS Firewall aplica decisões de filtragem às consultas que passam pelo VPC Resolver; essa decisão tem outro objetivo. Na arquitetura, desenha o caminho de resolução utilizado pelos clientes e identifica onde ocorre recursão. Uma aplicação que usa outro resolver não fica automaticamente abrangida pela mesma associação de rule group. Também não deves presumir que AWS Network Firewall inspeciona as consultas ao VPC Resolver. Define critérios separados: confiança dos dados, resultado da política de nomes, transporte da aplicação e autorização da operação. Esta separação evita atribuir todos os SERVFAIL ao mesmo componente ou aceitar uma política apenas porque a resolução funciona.

2. Estabelecer confiança com dependências e tempos explícitos

A ativação exige coordenação entre quem gere a zona e quem publica o DS na zona pai. Antes da mudança, regista TTLs, consultas de referência, responsáveis e meios de observação. A chave KMS usada pela KSK tem requisitos específicos: região us-east-1, tipo assimétrico ECC_NIST_P256 e utilização SIGN_VERIFY, além das permissões necessárias. Depois de ativar a assinatura, confirma a propagação autoritativa e respeita o período necessário para expirarem os dados anteriores em cache antes de estabelecer a cadeia através do DS. INSYNC não limpa caches de resolvers externos. Reduzir um TTL agora também não reduz retroativamente o tempo de vida de uma resposta anteriormente guardada. Na reunião de mudança, distingue o tempo técnico de aplicação do tempo de observação e da disponibilidade do responsável pela zona pai.

3. Recuperar sem quebrar a cadeia publicada

Se o DS continua publicado ou em cache, desligar a assinatura pode tornar a resposta inválida para resolvers que validam DNSSEC. Na retirada planeada, remove o DS na zona pai, confirma a propagação e espera o respetivo TTL antes de desligar a assinatura. O modelo local calcula apenas essa condição temporal a partir de evidência fornecida; não consulta o DNS nem garante que toda a Internet convergiu. Um alarme ACTION_NEEDED na KSK pode indicar perda de acesso à chave KMS. Algumas consultas ainda podem funcionar enquanto existem assinaturas válidas, pelo que esperar por uma falha total não é um critério adequado. Investiga estado e permissões da chave, aplica a recuperação documentada e observa a resolução. A rotação da ZSK gerida pela AWS não elimina a responsabilidade pela chave associada à KSK.

4. Interpretar a validação no caminho híbrido

Quando o VPC Resolver faz recursão para nomes públicos, a configuração de validação pode verificar DNSSEC. Se a consulta é encaminhada para outro resolver, esse upstream recursivo tem de fazer a validação. O simples facto de a opção estar ativa na VPC não prova a validação desse caminho encaminhado. O comportamento dos bits DNS também é específico: o VPC Resolver ignora DO e CD e não devolve o bit AD nem registos DNSSEC ao cliente, mesmo quando valida. Assim, a ausência de AD numa captura não basta para declarar a validação desligada, e CD não fornece aqui uma forma de a contornar por consulta. Para aceitação, usa nomes e resultados de teste controlados, distingue respostas válidas e inválidas e confirma a configuração do componente que realmente faz a recursão.

5. Aplicar filtragem com cobertura e precedência

Criar regras não basta: o rule group precisa de associação à VPC e existe no âmbito regional apropriado. A prioridade numérica menor é avaliada primeiro. Allow e Alert terminam a inspeção da consulta; Alert deixa-a passar e regista o resultado, pelo que uma regra posterior de bloqueio não a transforma automaticamente em recusa. Uma lista com example.com não cobre necessariamente os subdomínios pretendidos; explicita o padrão e testa o nome exato usado pela aplicação. Nas cadeias CNAME, a opção de inspeção de redirecionamentos exige atenção aos nomes seguintes. Confiar na cadeia de uma transação não concede confiança a uma consulta independente do cliente ao destino. O plano de testes deve incluir o nome inicial, o destino consultado diretamente, os tipos A e AAAA relevantes e a resolução nas regiões onde existe produção.

6. Escolher resposta de falha e observar o efeito

Fail closed é o comportamento predefinido quando o Resolver não recebe resposta do DNS Firewall: devolve SERVFAIL. Fail open permite consultas nessa condição e exige uma decisão explícita entre continuidade e controlo. Esta escolha não converte uma resposta DNSSEC inválida numa resposta confiável. Numa regra Block, NXDOMAIN, NODATA e uma resposta de substituição produzem resultados diferentes para o cliente; não os trates como diagnóstico equivalente. Num piloto, Alert ajuda a observar impacto, mas a passagem a Block deve incluir exceções revistas, owner e rollback. Os eventos EventBridge não são um contador exato de consultas, pois eventos repetidos para o mesmo domínio são limitados numa janela de seis horas. Entrega a RUN consultas de teste, resultados esperados, configuração de logs e contactos. Correlaciona evidência de DNS com o efeito no batch, sem inferir sucesso de negócio a partir de uma resposta isolada.

def signing_removal_gate(parent_ds_present, propagation_confirmed_at, ds_ttl, now):
    if parent_ds_present or propagation_confirmed_at is None:
        return "hold: parent removal not confirmed"
    if ds_ttl < 0 or now < propagation_confirmed_at:
        raise ValueError("invalid supplied timing")
    if now - propagation_confirmed_at < ds_ttl:
        return "hold: DS cache interval remains"
    return "timing gate met: validate remaining runbook checks"

assert signing_removal_gate(True, None, 600, 1000).startswith("hold: parent")
assert signing_removal_gate(False, None, 600, 1000).startswith("hold: parent")
assert signing_removal_gate(False, 1000, 600, 1599).startswith("hold: DS")
assert signing_removal_gate(False, 1000, 600, 1600).startswith("timing gate met")
try:
    signing_removal_gate(False, 1000, -1, 1600)
except ValueError:
    pass
else:
    raise AssertionError("negative TTL accepted")
print("five timing checks passed; no DNS query or signing change performed")
NA PRÁTICA

Caso fictício: a zona de um portal está assinada, mas uma alteração à key policy coloca a KSK em ACTION_NEEDED. O portal ainda resolve. A equipa trata o alarme antes de expirarem as assinaturas, recupera o acesso documentado e valida consultas externas. Não retira imediatamente a assinatura enquanto existe DS na zona pai.

Armadilhas comuns

Confundir assinatura com cifragem ou reputação; desligar a assinatura antes de retirar DS; interpretar ausência de AD como prova de falha; tratar Alert como bloqueio ou eventos como todas as consultas.

Tópicos relacionados: Delegação DNS e TTL · Gestão de chaves e alarmes · Aceitação e rollback

Leva esta ideia contigo

Confiança DNS e filtragem têm condições e evidências próprias. A recuperação deve respeitar a cadeia e os caches.

Criar conta

Referência: Configuring DNSSEC signing · ANS-C01

AWS é uma marca comercial da Amazon.com, Inc. ou das suas afiliadas. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por AWS. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.