ietf-mxcomp
[Top] [All Lists]

RE: TXT lookup domain - eliminating redundancy.

2004-04-21 10:49:38

Greg Connor [gconnor(_at_)nekodojo(_dot_)org] wrote: 

--Harry Katz <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> wrote:

I sincerely hope we DO NOT want to define a new RR type!  I'm sorry 
folks, but this is simply a non-starter.  As Meng Wong pointed out 
earlier on this thread, the requirement to upgrade DNS software to 
handle a new RR makes this a huge adoption barrier.  If we want to 
have a solution deployed in anything less than geologic 
time, TXT is 
the only pragmatic option.

And please let's not fool ourselves that using TXT records 
is only an 
"interim" solution.  It's permanent.  There's no way we're going to 
get administrators to publish their MTA IP addresses in TXT records 
today and then at some point in the future get them to re-publish 
using another RR.  And of course any software that 
implements checking 
for these records would forever have to check both TXT and whatever 
new RR we come up with since there will inevitably be laggards.


Er, I disagree.  Strongly.  Sure, upgrading your DNS is a 
hassle, but I think those servers will be upgraded anyway 
regardless of what we do.  

We shouldn't underestimate the hassle and cost involved here, nor
overestimate the frequency with which this happens.  Most organizations
will require significantly greater business justification for upgrading
than just support of a new RR type.

We *are* talking about writing a new RFC here.  Five years from 
now, whoever puts their names on that proposal will probably 
look sheepishly at their toes while describing "Yeah we 
really though TXT (or A or SRV) records were not ideal but we 
didn't want to wait and we didn't want to put in an interim solution".


Five years from now, if we have widespread deployment of MARID
information in TXT records and it has contributed to a reduction in
spam, I for one would be proud to have my name on the document that led
to that result.  

Speaking of barriers to adoption, XML is a big one.  So is an 
underscore in the label. :-)


If underscore is truly a blocker -- and no one I've spoken to has yet
said that it is -- then we'll happily get rid of it. 

Let's save the XML discussion for another day.  :-)