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

Wed Aug 1 18:50:50 -03 2012

On 01-08-2012 13:42, Danton Nunes wrote:
> 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.

PTR serve ao propósito de nomear o MX, e portanto permite
mover o registro SRV para um outro espaço de nomes:

MX possui o IP "a".  É utilizado por vários domínios.

DNS_REVERSO(a) retorna RRset:
    PTR   mx-foo-bar-01235232.dominio1.com.br
    PTR   mx-foo-bar-01235232.dominio2.com.br
    ...

Evidentemente que cada um desses PTRs devem resolver diretamente (sem
CNAME) para RRsets que contenham o IP "a".  E sim, isso NÃO ESCALA.

Agora, você pode utilizar a informação dominio1.com.br para criar um
lookup para um registro srv, estilo __rspf.dominio1.com.br, etc.

É uma possibilidade, já que colocar o registro SRV dentro do espaço do
reverso *cria* problemas operacionais para quem não detém o SOA.

Registros SRV não são criados no nó base, não dá para pendurar um SRV no
nó reverso-de-a, precisa ser em _(serviço)._(protocolo).reverso-de-a.
Ver RFC6335 e RFC2782.

Quem tem qualquer coisa menor que uma /24 delegada *não* detém o SOA,
o mesmo fica no upstream.  Já basta o trabalho que é conseguir que
certos upstreams façam a delegação via BCP 20/RFC 2317.  Ter que pedir
que inclua CNAMEs para os registros SRV pode ser impeditivo para a
implementação da solução.

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

Você quer validar que um certo IP aceita ser utilizado como MX para um
certo domínio, utilizando um mecanismo que está sob exclusivo controle
do detentor do espaço IP, correto?

Tem mais alguma coisa além disso?

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

Nem sempre, conforme expliquei acima.  O negócio é evitar SRV, ou mover
ele para outro espaço especificado pelos PTR, porque dentro do espaço
para reverso ele vai causar problemas para os "pequenos".

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

Faz sim.  O normal seria retornar erro 4xx no caso de erro na consulta
do DNS, enquanto que Neutral implica em tomar alguma decisão final de
encaminhamento da mensagem (descartar, marcar, encaminhar sem alterar, etc).

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

Nem sempre.  EDNS0 não foi implementado à toa.  Usar TCP é um problemão
daqueles tanto para quem precisa fazer centenas/milhares de consultas
por segundo, quanto para quem tem que responder essas consultas.

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

Ok :-)

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

Vou esperar para ver como você vai conseguir isso :-P

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

Sim, mas é escopo do RFC, que deve determinar o comportamento do agente
verificador.

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

O SRS é um defeito intransponível de projeto, e relegou o SPF a ser
muito mais um estorvo para o usuário que qualquer outra coisa.  Não
considero o SPF como exemplo a ser seguido, muito pelo contrário.

O que não significa que um "reverse SPF" não tenha futuro.  É uma
situação bem diferente.

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