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

[Danton Nunes]

On Wed, 15 Aug 2012, Frederico A C Neves wrote:

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

boa dica, Fred! mas ainda há o pad que usa o sinal = que não é válido em 
nomes de domínio. podemos usar a base32hex, excluindo qualquer padding.

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

sem dúvida. mas não gosto de riscos de natureza teórica.

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

sim, esse é O argumento pró-hash. legibilidade por humanos é O argumento 
contra. eu ficarei com o hash no meu projeto piloto.

> 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

muito bom!

valeu, Fred!

-- Danton.