On Mon, 2004-04-19 at 23:27, Harry Katz wrote:
On Monday, April 19, 2004 7:16 AM, Markus Stumpf wrote:
On Sat, Apr 17, 2004 at 01:07:45PM +0200, Arnt Gulbrandsen wrote:
Markus Stumpf writes:
If we want to define a new RR type we should do it /now/!
But how should it be defined?
IN MARID <what goes here?>
Sorry, my bad english ;-)
What to meant to say is is "if we want to define a new RR
type why should do in this process of developing the standard
and not afterwards in a second or third version.
How the record should look like should be defined if we know
what we want to authorize.
\Maex
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.
A new RR is a dead parrot. Nailing it to the perch won't help.
To second this opinion, with respect to DNS, unlike a typical user
client, an MTA will likely have a larger cache as a means of tracking
inimical domains in addition to now valid domains in thwarting
inundations of undesired mail as well as return address spoofing. If
there are 100,000 unique domains within 10,000,000 messages, the
overhead with a large cache is incurred about once per 100 messages. If
valid sending IP information were available, the lookup overhead would
circumvent an even greater overhead of bouncing mail with spoofed return
addresses. In addition, not receiving a false bounce provides a
reduction in the task of sorting messages from otherwise trusted MTA
sources.
Optimizing DNS lookup for MTA sending domains seems to be a misplaced
effort if it prolongs a period of adoption over a minor optimization
that would impact the entire infrastructure. Ease and speed of adoption
would seem to be where efforts are best placed.
-Doug