On Fri, Feb 29, 2008 at 09:57:15AM -0800,
Olaf Kolkman <olaf(_at_)nlnetlabs(_dot_)nl> wrote
a message of 48 lines which said:
The IAB is ready to ask the RFC-Editor to publish
Design Choices When Expanding DNS
draft-iab-dns-choices-05
I fully agree with the overall message ("the use of a new DNS Resource
Record Type is the best solution") but not with the way that the other
choices are ridiculed:
DNS extension discussions too often focus on reuse of the TXT
Resource Record Type.
It is a bit strange that there is nowhere in the draft even a small
bit of auto-critique. If many people used TXT RR types, it is because
it has been historically quite difficult to get a new RR type
registered (the problem which is addressed by RFC 2929bis).
It was historically difficult because:
* there wasn't a standard mechanism to emit a unknown record
in master file format.
* the description of when to use compression pointers was
wrong.
* some nameserver only handled known type (through design or
as a result of implementation bugs).
* there was no clear proceedure for gettting a new RR type
allocated.
All of these issues have been addressed for years now.
A second reason why many groups used TXT RR is because middleboxes
If you worry too much about middle boxes you will never
deploy anything new. People will replace middle boxes that
interfere with their need.
and at least one Microsoft API do not allow unknown RR types. This has
been reported several times.
So you want to hold up everything because one company
produced a API that was not RFC 1123 compliant?
Reading the current I-D, one may wonder why so many people stupidly
used TXT records... (See also the very questionable "it is worth
reexamining the oft-jumped-to conclusion that specifying a new
Resource Record Type is hard" in the conclusion.)
Because people keep putting up FUD whenever anyone suggests
getting their own RR type.
Having got a new RR type, it really was not that hard and
that was a politically sensative RR. Others have gone
straight through once there was agreement about what to put
in them. You have that problem whether you use a TXT record
or not.
Also you don't have to use TXT to experiment. There are
enough types available to be able to experiment provided
you actually go to the effort of getting a proper RR when
you are done. Been there, done that too. About to do it
again.
example of new data is [...] data used for fighting spam
If this refers to RFC 4408 or 4871, then "fighting spam" is not a
correct summary (by itself, authentifying the sender does not fight
spam, spammers can be authentified too). "Email domain sender
authentication" may be a better term.
Splitting an RRSet is a protocol violation
I have a doubt here. The protocol allows to send partial RRSets, you
just have to set the TC bit (RFC 2181, 5.1).
The process for creating a new Resource Record Type is specified in
[I-D.ietf-dnsext-2929bis].
It is just an informative reference. Do you plan to publish
draft-iab-dns-choices-05 before 2929bis? (It would be a bad idea,
IMHO, to tell people they must use a new RR type, before the new
procedure for doing so is ready.)
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews(_at_)isc(_dot_)org
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf