On 5/18/2004 3:56 AM, Andrew Newton sent forth electrons to convey:
I think this thread may need some context to give it adequate framing.
Many of the proposals in MARID specify the reuse of TXT or SRV
records, and many of the participants of this group insist upon it.
To quote one person, anything else is a "non-starter".
However, this group's output will be reviewed by the wider IETF
community as part of the standardization process, and there are many
people in the IETF community who feel reuse of an existing RR is an
architectural violation. They also may be of the opinion that MARID
lacks the urgency or necessity to require such an architectural
violation.
These phantom (AFAIK) people will need to stand up and be counted, IMO.
Where have they expressed these opinions ascribed to them? I haven't
seen anything approaching a compelling argument that SPF's use of TXT is
an architectural violation, let alone a problematic one, but I have only
read about 3/4 of the posts to the list. (One post that read <I heard
someone say there was once a guy who put some random crap in a TXT
record once.>) I also read a jabber log where you, Andy, strongly
opposed use of TXT, but again provided no actual reasons for your
opposition, or support for a new RR beyond reference to an RFC. Please
provide some technical reasons. Can you provide an argument that a
worldwide rollout using a new RR is feasible in the near future in the
real world, based on the deployed software out there?
"dns needs to work and overloading causes operational issues" is just
handwaving! Where's the meat?
I agree whith what PHB just said in his second post to this thread;
answers to the abve questions are needed to proceed to answer PHB's
question.
So, there are [4] things this group can do:
1) Go head-to-head with DNS experts and debate their wisdom and
technical conclusions, such as the validity of the DNSSec
specification or RFC 3597. (I strongly recommend against this!)
2) Reuse an existing RR without addressing the stated concerns and
take our chances.
3) Reuse an existing RR and rationally explain our decision against
the stated concerns.
Where are these stated concerns, so we can do this?
I haven't even seen any proponents of a new RR trot out a list of DNS
software that supports 3597!
4) Define a new RR.
I hope that most find either 3 or 4 to be the proper path forward.
-andy
On 5/17/2004 10:19 AM, Eric A. Hall sent forth electrons to convey:
([T]here's no way to distinguish between regular TXT, SPF TXT, and
other experimental TXT RRs bound to the same owner name).
What are you talking about? SPF records start off with a unique string.
On the first
point, storing something like a 32-bit IP address and a six-bit mask as
TXT usually requires 37 octets
As PHB mentioned, I think 18 (xxx.xxx.xxx.xxx/xx) is more on the money.
(at least 9 - 1.2.3.4/8).
Given that SPF provides plenty of ways around the 512B limit (and the
real world sizes of actual SPF records, and the real world increased
receptivity to TXT records) I don't think compression is a priority.
Especially in a world in which most of the HTML flying over the 'net is
still uncompressed.
I think a likely consensus would be to allow uncompressed TXT records,
and perhaps binary/compressed dedicated MARID record type records, with
the expectation that if either exists, the other doesn't need to be
checked. A wizard that converts from one to the other would not be hard
to implement.