Re: Use of TXT is rather conclusively a good idea.
2004-05-19 09:36:41
On 5/19/2004 6:45 AM, Andrew Newton sent forth electrons to convey:
On May 18, 2004, at 11:37 PM, Matthew Elvey wrote:
Much like Andy's "Thou shalt not use TXT" decree that I objected to.
I did not say that.
I think you and everyone else who read that knows that and knows exactly
what I meant.
s/"/</ would just have made the obvious more so, but I'm sorry if I
created a concern that I might have misled anyone.
You said something to that effect; see email below.
=-=-=-=
Yakov - apropos your post: It seems a bit late to say <Don't discuss RR
type now>, given that (prompted by Patrik Fältström's post justifying
it) the discussion's been had, and (hopefully) is over.
Note for the literal-minded: <Don't discuss RR type now> is not a direct
quote.
=-=-=-=
On 5/18/2004 9:06 AM, Matthew Elvey sent forth electrons to convey:
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.
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Reuse of TXT : draft-ymbk-dns-choices-00.txt, (continued)
- Re: Reuse of TXT : draft-ymbk-dns-choices-00.txt, Eric A. Hall
- Re: Reuse of TXT : draft-ymbk-dns-choices-00.txt, Matthew Elvey
- Re: Reuse of TXT : draft-ymbk-dns-choices-00.txt, Eric A. Hall
- Re: Reuse of TXT : draft-ymbk-dns-choices-00.txt, Matthew Elvey
- Re: Reuse of TXT : draft-ymbk-dns-choices-00.txt, Eric A. Hall
- Re: Use of TXT is rather conclusively a good idea., Matthew Elvey
- Re: Use of TXT is rather conclusively a good idea., Douglas Otis
- Re: Use of TXT is rather conclusively a good idea., Eric A. Hall
- Re: Use of TXT is rather conclusively a good idea., Matthew Elvey
- Re: Use of TXT is rather conclusively a good idea., Andrew Newton
- Re: Use of TXT is rather conclusively a good idea.,
Matthew Elvey <=
- Re: Use of TXT is rather conclusively a good idea., Yakov Shafranovich
- Re: Use of TXT is rather conclusively a good idea., Marshall Rose
- Re: Reuse of TXT : draft-ymbk-dns-choices-00.txt, william(at)elan.net
- Re: Reuse of TXT : draft-ymbk-dns-choices-00.txt, Pete Resnick
- Re: Reuse of TXT : draft-ymbk-dns-choices-00.txt, Matthew Elvey
- Re: Reuse of TXT : draft-ymbk-dns-choices-00.txt, Pete Resnick
- Re: Reuse of TXT : draft-ymbk-dns-choices-00.txt, Greg Connor
- Re: Reuse of TXT : draft-ymbk-dns-choices-00.txt, Patrik Fältström
- suggested new RRtype experiment, Meng Weng Wong
- Re: suggested new RRtype experiment, Andrew Newton
|
|
|