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

[Danton Nunes]

On Wed, 1 Aug 2012, Henrique de Moraes Holschuh wrote:

> 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.

só que PTRs não se prestam ao propósito de responder a pergunta 'este 
domínio pode sair por este IP?' pois seu valor tem que ser um nome de 
domínio canônico. No nosso caso o valor tem que ser PASS, NEUTRAL, FAIL.

> 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.

a RR SPF praticamente não é usada. e não sei se a sintaxe dela servirá 
para o que queremos. mas pode ser um caminho viável.

mas como disse, não está ainda na hora dos COMOs, vamos crarificar os O 
QUEs primeiro.

> 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.

mas por suposto o dono dos IPs tem controlo do SOA.

>> 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.

acho que não faz mal nenhum admitir NEUTRAL se der erro na consulta do 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).

não faz mal nenhum reponder em TCP, essa possibilidade existe para ser 
usada. DNSsec precisa disso de qualquer forma.

por outro lado temos que pensar em como limitar o RRset de resposta. o 
ideal é que só tivesse uma entrada. eu tenho algumas idéias para isso mas 
preciso elaborá-las mais antes de falar bobagem em público. ;)

> 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.

zero níveis. minha idéia é que se resolva tudo com uma única consulta.

> 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.

sim, mas isso estaria fora do escopo do protocolo em si.

>> 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.

boa observação.

>> 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...

eu não estou certo de que 'include' seja realmente uma boa idéia. só 
coloquei isto para manter um certo paralelismo com o SPF direto.