[GTER] uma ideia para discussão: SPF reverso.

[Henrique de Moraes Holschuh]

On 01-08-2012 00:56, Danton Nunes wrote:
> 1. Deve usar o DNS como base de dados distribuída, através dos
> domínios in-adr.arpa e ip6.arpa, pois controlar esses domínios é um
> bom sinal de controle sobre os endereços IP correspondentes.

Boa ideia.

Vai atrelar ao resultado retornado pela RRset PTR ?  Note que mais de um
registro PTR é *explicitamente* uma configuração válida, definida no
RFC-2181 (que é um daqueles RFCs que você ainda vai se arrepender de não
ter lido).

PTRs são interessantes.  Obrigatoriamente apontam para um nó que deve
retornar A ou AAAA (não podem apontar para CNAMEs), e podem ser
facilmente validados (aliás, se não vai validar, não use a informação
retornada pelo PTR para nada).  Para validar, verifica-se que
PTR(RDNS(B)) resolve para um conjunto de RRset com registros A e/ou
AAAA, que contém B.  É importante lembrar que RDNS(B) retorna um RRset
que pode ter mais de um RR PTR, precisa verificar todos eles (e cada
verificação resulta em um RRset com diversos RR A e/ou AAAA), e retornar
no primeiro sucesso.

É útil se for de alguma valia atrelar o SPF reverso a domínios e
subdomínios explicitamente referenciados no conjunto de PTRs do MX de
saída.  Se isso for funcionalidade inútil, melhor não tocar nesse
vespeiro...

> 2. Deve servir para endereços IP individuais. Blocos poderão ser
> simulados por coringas ou esquemas de geração automática de registros
> similares (como o $GENERATE do bind). Não haverá provisão para
> blocos, pois isto requeriria várias consultas ao DNS para decidir um
> par (domínio,endereço) e a intenção é que o protocolo seja rápido.
> Assim como no SPF direto, serão usados RRs do tipo TXT para codificar
> os resultados. NOTA: isto é provisório, pode ser que o TXT seja muito
> limitado para acomodar outros requisitos.

Que tal usar a RR SPF ao invés de abusar de RRs TXT?  Outra alternativa
é definir uma consulta SRV no espaço de DNS reverso.

Abusar o TXT *não* é boa ideia.

A ideia de definir um registro SRV tem consequências:

Se o SRV estiver no espaço do reverso, vai precisar que você tenha o
controle da SOA (ou seja, alocação /24 ou maior), ou que seu upstream
delegue via CNAMEs também os nós correspondentes aos registros SRVs.
Não recomendo.

Se usar o conteúdo dos registros PTR, pode mover o registro SRV para o
mesmo espaço do conteúdo do registro PTR... mas ver meu comentário sobre
vespeiros, acima.

> 3. Para cada par (domínio,endereço) haverá um resultado que pode
> assumir os valores PASS, NEUTRAL, FAIL. Não vejo necessidade de um
> SOFTFAIL como no SPF clássico (RFC-4408). O resultado padrão, caso
> não haja um registro de política, será NEUTRAL. A semântica é a mesma
> da RFC-4408.

Há necessidade de um código para retry, a ser utilizado em erros
temporários na consulta de DNS.

> 4. Não deve haver limitação para o número de domínios associados a
> cada endereço IP, caso contrário o protocolo não poderia ser aplicado
> a servidores que enviam mensagens de múltiplos domínios. NOTA: isto
> pode trazer problemas de implementação, já que pode haver limites
> práticos em RRs do tipo TXT e tenhamos que usar outro artifício.

O número de RRs em um RRset que dá para retornar é limitado pelo
protocolo DNS em si (questões práticas, como exceder a resposta que cabe
em 512 bytes e precisar responder via EDNS0 ou via TCP), e pela
implementação dos resolvers (vai saber.  Deve haver alguns milhões de
implementações lixo por aí. Quebrar o lixo de forma espetacular é melhor
para a humanidade a médio prazo, mas não vai ajudar na aceitação do
protocolo).

Se for permitir a recursão através de um valor especial na RR retornada,
sugiro as seguintes restrições:

   Apenas 2 níveis de fan-out (raiz, nível 1, nível 2), cada nível
   restrito a subdomínios do nível anterior.

DNSSEC deveria ser obrigatório.  Note que do lado da aplicação que
verifica, isso torna _sim_ mais complicado a implementação, e que não
faz sentido obrigar DNSSEC só para um RR, teria que ser obrigatório para
todos os RRs envolvidos com a validação do SPF reverso.

> 5. Será permitido usar coringas (wildcards) para especificar os
> domínios. Talvez valha a pena considerar também uma sintaxe
> semelhante às chaves do Bourne Shell, de modo que
> 'example.{com,net,org}' expandisse para 'example.com example.net
> example.org'.

Complicar o parser é problema, e as funções de glob "estilo shell" já
foram assunto de diversos problemas BEM severos de segurança.  Recomendo
veementemente que reconsidere.

Sugiro que aceite apenas dois tipos de curinga: "*." à esquerda, e "." à
esquerda.  O "*." aceita um único componente de subdomínio.  O "."
aceita qualquer número de componentes de subdomínios.  Curingas não
podem ocorrer em nenhum outro local, e só podem ocorrer uma vez.

> 6. (questionável) Serão permitidas redireções (include) à maneira
> como se faz no SPF clássico.

Sugiro que limite os níveis, e restrinja como podem ser usadas baseado
em subdomínio.  Ou seja, não pode sair da hierarquia retornada pelo(s)
PTR(s).  Como podem ser vários PTR, podem ser várias hierarquias.

Quem precisar usar algo diferente será obrigado a usar CNAME, o que tem
lá suas vantagens.  Não vai ser tão fácil de usar, mas vai ser um pouco
mais difícil de abusar...

-- 
Henrique de Moraes Holschuh <hmh at ima.sp.gov.br>
IM@ - Informática de Municípios Associados
Engenharia de Telecomunicações
TEL +55-19-3755-6555/CEL +55-19-9293-9464

Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
e do custo que você pode evitar.