Re: [dnsext] getting people to use new RRTYPEs

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, "John R Levine" writes:
> >In my view, the issue relevant to DNSEXT ("moribund" or not) is the implication of the SPFBIS approach
> >on the specification of new DNS RRtypes. I do not believe the issues faced in SPF deployment are unique
> >and I imagine there will be protocols in the future that follow the same steps, i.e., put info in the
> >DNS using TXT during initial experimental phases because it's easy/simple/doesn't require any
> >approvals/documentation/interaction with others and then come back later and try to do "the right
> >thing" when the protocol "works".
> 
> Indeed.  What could we do to encourage people to use new RRTYPEs from
> the beginning of their experiments?

The hardest thing is dealing with the naysayers.  The entire BS
that keeps getting repeated that getting a RR type is hard.  It
hasn't been hard for over a decade now.  Well before SPF needed to
make a decision about what type to use.

There is a type range for experimenting.  I used it for DLV
experimentation then got a DLV type allocated and moved the code
over to using it.  This worked.

Most of the delay was because the RFC Editor's expert reviewer
didn't get back to me on the initial request being rejected.  I
then went AD sponsered and had to convince the IESG that it wasn't
a run around of the dnsext wg which was about one additional email.
DLV is a method of publishing a set of trust anchors which was
expected to happen as far as DNSSEC was concerned.

Working file: lib/dns/rdata/generic/dlv_65323.c
revision 1.5
date: 2006-02-17 12:04:14 +1100;  author: marka;  state: dead;  lines: +1 -1;
1985.   [protocol]      DLV has now been assigned a official type code of
                        32769. [RT #15807]
----------------------------
revision 1.4
date: 2004-03-18 13:58:04 +1100;  author: marka;  state: Exp;  lines: +4 -4;
branches:  1.4.18;  1.4.584;
pullup silence compiler fixes
ifconfig.sh for Solaris 9
README updates
----------------------------
revision 1.3
date: 2004-03-16 16:22:30 +1100;  author: marka;  state: Exp;  lines: +8 -9;
copyright
----------------------------
revision 1.2
date: 2004-03-10 13:19:56 +1100;  author: marka;  state: Exp;  lines: +282 -0;
branches:  1.2.2;
1589.   [func]          DNSSEC lookaside validation.

enable-dnssec -> dnssec-enable
----------------------------
revision 1.1
date: 2004-02-20 17:35:47 +1100;  author: marka;  state: dead;
branches:  1.1.2;
file dlv_65323.c was initially added on branch rt10440.


> Wagging fingers, insulting people, and asserting that there is no
> barrier to installing new versions of software has a proven track
> record of failure.  Perhaps we could identify the actual bottlenecks
> (if you've read my previous zillion messages you know what I have in
> mind) and figure out how to fix them.

Nobody is stating that there is no barrier.  Just that the barriers
are not as big as people keep stating they are.  If your DNS hoster
doesn't support a type in their web interface complain to them or
move to someone who does.  Generic support for new types is nearly
a decade old now.

If your IDS doesn't allow new types to come through get a new IDS
because the existing one is broken.  The expection of new types has
been part of the DNS from day one.  A IDS should be able to cope
with new types.

This is about consumers picking reasonable DNS products for their
needs.  This is about vendors that deal with DNS data doing the
right thing with respect to new types.  Yes, registrars are DNS
vendors.  So too are firewall vendors.

There are a lot of DNS vendors on this list that don't do the right
thing with respect to new DNS types.  ISC has changed our policy
for new types from the "next .0 release" to "next point release"
which reminds me we need to back port HIP and URI to 9.6.x

Mark

> R's,
> John
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]