Re: TXT now, new RR later (was Re: Why not XML)

Michael R. Brumm wrote:

> SMTP authorization cannot wait for RFC 3597 to be widely deployed. People will 
> not wait this long. Spam is an ever increasing burden on everyone from the 
> postmaster down to the end-user. I'm sure I don't even have to mention this.
>
> ...
>  
>
> The "SPF circus" hasn't delayed the adoption of RFC 3597, and RMX has not significantly 
> increased the adoption rate of RFC 3597. In any case, the date of RFC 3597 is "September 
> 2003", which is less than 10 months ago. I don't see how we can expect anything as incredibly 
> large-scale as SMTP authorization to be built on something that is so young and not widely 
> implemented.
>
>  
>
> ...
>  
>
> I don't see how we've lost any time to the "SPF circus". SPF and RMX haven't 
> affected RFC 3597 deployment; it's been the other way around. SPF is being adopted and 
> deployed precisely because it can be (right now) in TXT records, while RMX was hindered 
> due to its RR type requirement.
>
>  
I see three arguments in your posting: RFC3597, RFC3597, and RFC3597.

This issue had been discussed in ASRG and several mailing lists about a 
year ago, and had been considered
to not be a real problem, because most DNS servers already are able to 
forward unknown RR types.
RFC3597 is not a new invention, merely a description of a status quo 
already reached with newer
DNS servers. (I didn't  find this discussion yet in my RMX mail 
archives, because they are several
hundreds of megabytes)

BTW, this discussion was the reason why I had to drop the DNS domain 
name compression from
earlier drafts of RMX: I had made use of the domain name compression 
described in DNS in
my test implementation and it had good results depending on the RMX 
entry type (obviously
for those entry types containing a DNS name).

I received a hint from a DNS working group that this won't work. Guess why!

Because DNS name compression works only if every DNS relay is able to 
decode and
reencode the RR type. This compression method does not work if the DNS 
server
is forwarding the record without modification. And that's the problem: 
Most modern
DNS server already do forward unknown RR types, but due to the fact that 
they
are unknown,  the DNS servers can't de- and reencode them. Probably it 
was that
discussion about RMX records why it is stated explicitely in RFC3597 to 
not use
DNS compression for new record types. This problem would not have 
occured if
DNS servers would drop unknown types.

So I had to drop the compression from the draft just because too many 
DNS servers
already are forwarding unknown RR types, therefore a new RR type cannot 
be invented
with DNS compression.

And, btw, I made some tests with an RMX implementation, were at least the
DNS servers involved in the tests were forwarding the RMX records even
without beeing patched.

So the RFC3597 argument is not a good argument (all three of them).

Hadmut