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

[Frederico A C Neves]

Danton,

On Wed, Aug 15, 2012 at 04:33:09PM -0300, Danton Nunes wrote:
...
> 3. Cálculo do hash
> 
> Maiúsculas e minúsculas tem o mesmo valor nos nomes de domínio, mas não 
> no cálculo do MD5, então, antes de calcular o hash todos os caracteres 
> alfabéticos deverão ser convertidos em minúsculas.
> 
> Nomes de domínio internacionalizados devem ser representados em punycode 
> [RFC-3492 e RFC-5891].
> 
> O hash é calculado sobre o nome do domínio sem qualquer terminador de 
> linha.
> 
> O hash é codificado em base 16. É irrelevante se em maiúsculas ou 
> minúsculas, já que os nomes de domínios não são sensitivos ao caso.

Use base32hex, o mesmo usado no NSEC3. Veja RFC4648 7. Com este
encoding e o seu atual hash selecionado ganha-se ao menos 6 bytes :-)

> Exemplos:
> 
> example.com -> 5ababd603b22780302dd8d83498e5172
> 
> ?????????.nom.br -> (punycode) xn--riqy20ichd.nom.br ->
>  	-> 50807287f78ea82a698719357de51805
> 
> NOTA: considerei a possibilidade de codificar o hash em base-32 ou 
> base-64, que certamente resultaria em um componente do domínio mais 
> curto, no entanto ambas as bases usam caracteres que estão fora do 
> conjunto permitido para nomes de domínio e a base-64 distingue 
> maiúsculas de minúsculas, que são confundidas no escopo do DNS.

Correto quanto ao base64 uma vez que isto será usado no ownername e
não no rdata. Se fosse no rdata não teríamos problema.

...

> Questão do HASH:
> 
> escolhi MD5 um tanto arbitrariamente, me parece um tanto 'over' para esta 
> finalidade. poderia ser um hash mais curto, se bem que quanto mais curto 
> mais o fantasma da possibilidade de colisão assusta.

Esta preocupação certamente é válida quando o input da sua função de
hash é de tamanho muito maior do que o próprio hash mas com um espaço
de nomes limitado a nomes de 255 bytes, o que inclui ai também o byte
do tamanho de cada label, MD5 ainda me parece muito bom.

> por outro lado, há a dúvida, to hash or not to hash? o hash permitiria 
> tratar domínios enormes com até todos os 127 componentes permitidos pela 
> RFC do Mockapetris, enquanto se simplesmente concatenássemos o nome do 
> domínio com o do endereço IP reverso teríamos um limite de 93 componentes 
> (no domínio ip6.arpa, no caso do IPv4 seria menos restritivo). Na prática, 
> duvido que exista um domínio de e-mail com 93 componentes!

Suportar todo e qualquer domínio é o principal motivo para se utilizar
hash. É certo que a grande maioria dos nomes + reverso + in-addr.arpa
em "wireformat" será menor ou igual a 255 bytes mas não será aplicável
a qualquer caso, por isto o hash é altamente aconselhável.

> outra questão que ficou em aberto é um mecanismo de delegação para os 
> casos em que o dono dos IPs não controla o domínio reverso, tipicamente 
> quando recebe um bloco de IPv4 menor que /24. houve uma proposta 
> interessante baseada em criptografia de chave pública, mas me pareceu um 
> tanto complicada e resolvi não incorporá-la nesta altura. Estou pensando 
> em alguma abordagem mais ao estilo da BCP-20, para incorporar mais tarde.

De uma olhada nesta proposta. Pode ser aditiva a sua. É uma técnica
para representação em qualquer bit-boundary.

http://tools.ietf.org/html/draft-gersch-dnsop-revdns-cidr-02

> -- Danton.

[]s
Fred