Subject: Re: [dnsext] getting people to use new RRTYPEs

From: "John R Levine" <[email-masked]>
Date: 25 Apr 2013 17:58:30 -0400

>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?

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.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Apr 2013 10:46:32 +1000

> 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.

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 25 Apr 2013 21:32:50 -0400

> move to someone who does.  Generic support for new types is nearly

You must know a different set of DNS hosters than I do.  It's vanishingly
rare to find one that lets you insert random records via the provisioning
software.  You can go looking for ones you like, but good luck.  For the
vast majority of DNS users, it's a feature that they can't install random
crud, not a bug.

This is why I keep saying over and over again that it would be nice if we
made it easier for them to handle new RRTYPEs in a way that makes it 
harder to shoot yourself in the foor than allowing random hex strings.

R's,
John

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Apr 2013 18:41:31 -0700

> harder to shoot yourself in the foor than allowing random hex strings.

John,

I realize that you have an agenda to push your idea, but for the sake of 
anyone new to this discussion who hasn't seen my response to this before:

1. Insert the ability into the interface to add freeform stuff
2. Run the equivalent of named-checkzone prior to committing the change
3. Profit!

Fixing the provisioning systems isn't hard to do, it's not even a 
complex problem. The issue is that for the most part service providers 
don't want to make ANY changes to existing stuff because it eats into 
their profits. That's understandable, but if we're going to give in to 
that then the answer is "no new RRtypes ever," which is not acceptable.

So can we please stop trotting out the provisioning system argument? 
Mark is right, new RRtypes aren't hard to deal with. I've made the point 
previously that things like DNSSEC and AAAA have long-since "cracked the 
ice" on the old "fire and forget" method of DNS software deployment, and 
every day that goes by brings new and exciting developments in the DNS 
world. That doesn't mean that deploying new stuff is "easy," just that 
it's a lot easier than it used to be, gets easier every day, and there 
is market pressure to keep making it get easier as we go along.

Doug

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Apr 2013 12:15:29 +1000

> 2. Run the equivalent of named-checkzone prior to committing the change

And it's not like example code to do this for individual RRs doesn't
exist.  It would be about 10 minutes work to take this existing
test code and make it into a application that returns 0 or 1 for
the exit code.

It would still need a man page, test suite for the application
itself to be written, etc. but overall not a big deal.  One could
even make it spit out the records in unknown format if you were
worried about having to upgrade the nameserver quickly.

[drugs:bind9.drugs/bin/tests] marka% ./rdata_test
IN A 1.2.3.4
dns_rdatatype_fromtext returned unknown class/type(65543)
[drugs:bind9.drugs/bin/tests] marka% ./rdata_test
A IN 1.2.3.4
type = A(1)
class = IN(1)
"1.2.3.4"
[drugs:bind9.drugs/bin/tests] marka% ./rdata_test 
A IN 1.2.3.4.5
type = A(1)
class = IN(1)
dns_rdata_fromtext: stream-0x7fff7bf21a90:1: near '1.2.3.4.5': bad dotted quad
dns_rdata_fromtext returned bad dotted quad(65541)
[drugs:bind9.drugs/bin/tests] marka%

---

From: "John Levine" <[email-masked]>
Date: 26 Apr 2013 03:43:21 -0000

>> 2. Run the equivalent of named-checkzone prior to committing the change

I don't know whether to laugh or cry.

No, this won't work with provisioning systems in the real world, that
have to be usable by people who are not DNS weenies, and work in
systems where the software upgrade cycle is months or years, not days.

There are real reasons that seven years after RFC 4408, most
provisioning systems still don't handle type 99 records, and it's not
because everyone who does e-mail is stupid.

No need to respond, you've made your point, although it may not be
what you thought it was.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Apr 2013 14:11:32 +1000

> because everyone who does e-mail is stupid.

It just money.  Really that is the only reason at this point.  They
won't spend a cent to make their systems updatable or they want to
charge extra for supporting type 99 records.

> No need to respond, you've made your point, although it may not be

One can upgrade components of a system.  Nameservers are regularly
upgraded independently on the rest of the system.  Similarly
other tools are regularly upgraded.

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Apr 2013 21:23:03 -0700

> systems where the software upgrade cycle is months or years, not days.

Once again, I know that you want to promote your solution for this 
problem. That's fine, but that doesn't mean that it's the only solution, 
or even the best one. What I proposed would work "forever." There is no 
doubt that it requires more DNS knowledge, but most non-experts entering 
"special" or "custom" DNS are doing cut and paste anyway.

> because everyone who does e-mail is stupid.

Um, that's pretty much non-sequitur.

> No need to respond, you've made your point, although it may not be

Yep, a lot of that going around. :)

Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 25 Apr 2013 21:58:12 -0700

On Apr 25, 2013, at 9:23 PM, Doug Barton <[email-masked]> wrote:

> Once again, I know that you want to promote your solution for this problem. That's fine, but that doesn't mean that it's the only solution, or even the best one. What I proposed would work "forever." There is no doubt that it requires more DNS knowledge, but most non-experts entering "special" or "custom" DNS are doing cut and paste anyway.

Doug,

To be fair, a significant barrier was the Windows corporate environment translating DNS to RPC with a limited template set.  As it turns out, use of the SPF protocol at the MUA is fairly limited.  While overlaying TXT RR is bad, these also offer policy for any domain or subdomain.  Some may simply wildcard TXT records and create problems for other protocols using these records.  One of the original motivations for overlaying TXT was to permit wildcard use.

IMHO, the high overhead associated with the SPF scheme as IPv6 is deployed seems to ensure a more scalable and safer cryptograph scheme is a likely replacement using standard RRs.  Nothing needed for IPv6 is really being solved using SPF or DKIM.  Currently DKIM is easily spoofed just as Hector demonstrated many years ago.  Few providers are willing to discard based upon SPF failures, but limit use to vetting NDNs.  Many providers unwilling to run macro expansions should have cause this dangerous scheme to have been discarded long before the type 99 resource allocation based upon the same sort of justifications. 

Regards,
Douglas Otis

---

From: Jim Reid <[email-masked]>
Date: Fri, 26 Apr 2013 07:22:35 +0100

On 26 Apr 2013, at 01:46, Mark Andrews <[email-masked]> wrote:

> that keeps getting repeated that getting a RR type is hard.

It's not BS. Getting new RRtypes is easier than it used to be (in principle) but it is not easy.  Or at least, this WG creates the perception that it is not easy. Witness the recent pushback and BS around Joe's EUI{48,64} RRtypes. BWT, this was AFTER the RRtype Allocation Policy of RFC6895 had been followed and IANA had issued the type codes. That resistance from this WG -- "I'm in favour of liberalising type code assignments, but..." -- was not an isolated event.

It's disappointing but not surprising if others take the path of least resistance and go with a TXT record and avoid the hassle of the RFC6895 template and expert review. Not because that process is defective, but because the BS that tends to surface on this list. Having been on the receiving end of that treatment, I would think long and hard about coming to the IETF with a request for a new RRtype code instead of doing the "wrong" thing by following the herd and overloading the TXT record. Or just plucking a number from the reserved for private use range and hoping nobody else picks the same one.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Apr 2013 16:29:59 +1000

In message <[email-masked]>, Jim Reid writes:
> It's not BS. Getting new RRtypes is easier than it used to be (in 
> principle) but it is not easy.  Or at least, this WG creates the 
> perception that it is not easy. Witness the recent pushback and BS around 
> Joe's EUI{48,64} RRtypes. BWT, this was AFTER the RRtype Allocation 
> Policy of RFC6895 had been followed and IANA had issued the type codes. 
> That resistance from this WG -- "I'm in favour of liberalising type code 
> assignments, but..." -- was not an isolated event.

The type code is allocated.  Code supporting EUI48 and EUI64 has
shipped.  BIND 9.6, 9.8 and 9.9 all support EUI48 and EUI64.  The
rest is bikeshedding.

> It's disappointing but not surprising if others take the path of least 
> resistance and go with a TXT record and avoid the hassle of the RFC6895 
> template and expert review. Not because that process is defective, but 
> because the BS that tends to surface on this list. Having been on the 
> receiving end of that treatment, I would think long and hard about coming 
> to the IETF with a request for a new RRtype code instead of doing the 
> "wrong" thing by following the herd and overloading the TXT record. Or 
> just plucking a number from the reserved for private use range and hoping 
> nobody else picks the same one.
>

---

From: joel jaeggli <[email-masked]>
Date: Thu, 25 Apr 2013 23:47:27 -0700

> It's not BS. Getting new RRtypes is easier than it used to be (in principle) but it is not easy.  Or at least, this WG creates the perception that it is not easy. Witness the recent pushback and BS…
Well realistically, the WG is closing down so work that would involve 
draft(s) being accepted and processed would occur elsewhere.

I brought the  discussion here, when considering whether to AD sponsor 
the draft because there is a critical mass of knowledge here that is 
useful for providing feedback.

There was useful criticism that lead to the draft being revised...

There was also criticism of the codepoint assignment that's all well and 
good. but this wg isn't in the code point assignment path so that's not 
germain.

There is criticism that there are better ways to do this. (I'm sure 
there are) that's fine, good enough should not be our enemy. were this 
not to achieve the required consensus  I see not reason why the IESG 
would prevent and indepedent stream documentation of the codepoint 
assignment.

I think we can demonstrate that RFC6895 assignment process is less 
onerous than the mailing list discussion.

---

From: Jim Reid <[email-masked]>
Date: Fri, 26 Apr 2013 08:14:02 +0100

> shipped.  BIND 9.6, 9.8 and 9.9 all support EUI48 and EUI64. The

Indeed. My point is/was that the bikeshedding and other showboating in this WG create the perception that getting type codes is hard.

---

From: Jim Reid <[email-masked]>
Date: Fri, 26 Apr 2013 08:27:48 +0100

On 26 Apr 2013, at 07:47, joel jaeggli <[email-masked]> wrote:

> I think we can demonstrate that RFC6895 assignment process is less onerous than the mailing list discussion.

Fine. However the latter is more visible => creating the perception that getting type codes is "hard".

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Apr 2013 11:11:56 +0000

> Fine. However the latter is more visible => creating the perception that getting type codes is "hard".

<no hat>

I think that if you want to get a document through the IETF, and you say "oh, but I don't want to do that bit, because it's too hard," then you are really being unreasonable.   During the worst period of "new RRtype resistance" about a decade ago, I and several others managed to get a new RRtype through the intarea DNS working group.   We did get yelled at, but we persisted, and we got the result we wanted.

This is how the IETF works.   You are watching sausage being made: it isn't pretty.   No amount of public shaming is going to change this: the current conversation is an existence proof, since this sort of shaming has been going on as long as I've been participating, and the mailing list still has threads like the EUI64 thread.   This is what it means to say anyone can participate.

If you want to get work through the IETF, you have to be brave, because you will—you must—draw criticism.   And you don't get to say "I want to get my work through the IETF, but I'd like to skip that bit of the process because those guys are hard to deal with, please."

All of this is completely independent of the debate that's going on here about SPF; my point is simply that if you aren't willing to engage in debate in the IETF, you are probably in the wrong IETF.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 26 Apr 2013 08:14:24 -0400

I am speaking here as an individual and as an operator.

> 2. Run the equivalent of named-checkzone prior to committing the change

That's preposterously naive.  Step 2.1 is "Find that customer who has
no theory of the mystifying DNS arcana screwed it up, so you can't
publish, and now you have to contact a human.  Stop.  Invoke expensive
off-page customer service process."  In some significant number of
cases, we never get to step 3.  In the DNS business, the margins are
small.  

This list -- and indeed, much of the IETF, as is often lamented -- is
heavily populated by people who either are not operators or else are
not consumer-facing operators, though there are notable exceptions.
It sseems at least possible that this introduces a bias of ignoring
problems that others report (or that are observable in deployment)
because they're not the problems of the people who happen to be here.

I have to agree with John Levine that the usual answer of the DNS
community to provisioning problems -- in caricature, "This is easy,
you must be morons."  -- is not helpful, and is indicative of a closed
mindedness that is unbecoming.  Maybe, just maybe, the people out
there who are successfully operating systems at some scale have
something to teach us about the real barriers to the things we think
would be ideal.  We dismiss those observations not at our peril, but
at the peril of the DNS (and Internet).

A

-- 
Andrew Sullivan
[email-masked]

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 26 Apr 2013 14:40:32 +0200

Subject: Re: [dnsext] getting people to use new RRTYPEs Date: Fri, Apr 26, 2013 at 08:14:24AM -0400 Quoting Andrew Sullivan ([email-masked]):

> mindedness that is unbecoming.  

The proper answer is "This ought to be easy, and usually is,
but half-assed implementations that are in conflict with both letter
and intent of the DNS standards and culture make it unnecessarily hard,
for some people. Vendors most of the time act against better knowledge
because of reasons. This is moronic."

/Måns, ivory-tower-sited operator of DNS zones and email servers. 
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
My haircut is totally traditional!

---

From: Warren Kumari <[email-masked]>
Date: Fri, 26 Apr 2013 13:29:32 -0400

>> systems where the software upgrade cycle is months or years, not days.

+1

>> because everyone who does e-mail is stupid.

Yup. And even many of the ones that *do* support type 99 don't allow adding arbitrary types.
I use GoDaddy as a registrar (never underestimate the power of apathy :-)). I just changed a test domain to use their hosted DNS solution.

I can add any of the following though the web interface:
A (Host)
CNAME (Alias)
MX (Mail Exchanger)
TXT (Text)
SPF (Sender Policy Framework)
SRV (Service)
AAAA (IPv6 Host)
NS (Nameserver)

(I wasn't actually expecting them to support SPF, but they do (and even have a reasonable interface for it). Pleasant, if pointless,  surprise).

But, there is no way (that I've found) to add other record types (like TLSA or SSHFP or…). [There was some "Premium DNS" option that I didn't try (see the apathy comment) -- maybe it does it?]

There is an "Export.." and "Import…" option. Lets try that…
Export the current zone file...
Add "test    3600   IN       TYPE65530  \# 1 ( 42 )"
Click Import. Fails with "Invalid file". Ok, maybe something a little less unusual…

Try SSHFP. No love.
Try TLSA. No love.

I get why they don't allow arbitrary types (it costs a little more, very few of their customers need it, there is some (small) security risk, some customer will enter "Bob" in a type-17 record and then wonder why Bob isn't suddenly responsible, etc), but it does make me sad…

Unfortunately I don't really see a way to change this -- most registrars are incentivized to provide what the majority of the customers want for the minimum cost. My auntie won't choose a different registrar because her current one doesn't support NAPTR…

(It looks like Dyn may support arbitrary record types (http://dyn.com/support/record-types-standard-dns/), but I'm not 100% sure. See the apathy comment again)

> It just money.  Really that is the only reason at this point.  

Yup[0], but saying "Its just money" in this context is like saying you can solve world hunger by "Just giving everyone more food" -- while true, it's not particularly helpful.

> They

Yup. 

> other tools are regularly upgraded.

W.
[0]: Actually I wouldn't say that it is only money -- there is also the concern about customers shooting themselves in the foot, and then you having to help them recover, time, priorities, keeping a clean UI, etc.

-- 
"I think it would be a good idea." 
- Mahatma Ghandi, when asked what he thought of Western civilization

---

From: Doug Barton <[email-masked]>
Date: Fri, 26 Apr 2013 11:01:29 -0700

On 04/26/2013 05:14 AM, Andrew Sullivan wrote:
> That's preposterously naive.

Careful, that's dangerously close to ad hominem. :)

> Step 2.1 is "Find that customer who has
> publish, and now you have to contact a human.

No, you don't. You write the documentation in advance about how the 
known type codes work, and when the thing fails you send them to a page 
that says, "I think you meant to do 'this' which should look like 
'that.' If that's not what you wanted, go 'here' which has a big list o' 
DNS records and their proper format."

Not to throw resumes around or anything, but I used to be in that 
business. I've written management platforms for DNS. When I left Yahoo! 
we had over 600,000 domains in our registrar-reseller business. My 
current business is enterprise DNS/DHCP/IPAM management solutions. Prior 
to that I was working for a company that does hosted solutions for mom 
and pop's all the way up to major e-commerce sites.

I'm not talking out of my ass here, I'm explaining that there is a real 
solution to this problem. The real issue (as you point out below) is 
that it isn't free, in either sense (speech or beer).

> Stop.  Invoke expensive

Thank you for confirming the real problem, which as I have pointed out 
in the past, is that the operators, especially hosting providers that 
cater to naive users, don't want to make ANY changes because it costs 
money on both the front and the back ends.

> mindedness that is unbecoming.

I'm not close-minded, and I'm not naive. I'm also not willing to allow 
all progress on new DNS type codes to be held hostage to providers 
unwilling to invest in their own infrastructure.

Doug

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 26 Apr 2013 14:04:07 -0400

> (It looks like Dyn may support arbitrary record types (http://dyn.com/support/record-types-standard-dns/), but I'm not 100% sure. See the apathy comment again)

Nope, we don't.  

Last I checked, also, GoDaddy actually _published_ the SPF records you
send them as a TXT, but I haven't checked recently.  

That's what Dyn tells you to do in the "Standard DNS" product.  Our
enterprise product (DynECT DNS) offers the TYPE 99, partly because that
product involves access to our concierge people, who can help you out
when things go wrong.  The low-price Standard offering is only possible
to offer if our support costs are kept low, which means "no
hand-holding".  Because we're interested in a good customer
experience, we have to be conservative about what we offer.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 26 Apr 2013 23:14:30 -0000

>cases, we never get to step 3.  In the DNS business, the margins are

You also forgot step 1.9, in which the software faeries magically
update named-checkzone for every new RRTYPE, even though the times
when new RRTYPEs are defined bear no relation to any sort of software
update or release schedule, and people who want to experiment with new
RRTYPEs are unlikely also to have the skills or inclination to patch
the BIND parser.

R's,
John

PS: That's why my hack, using an idea from Vixie, automatically
configures new RRTYPEs as they're published, with no software changes
or updates needed.  Again, I don't claim that's the only way to do it,
but I do strongly believe that a useful configurable provisioning or
DNS system can't require per-RR software changes.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 26 Apr 2013 17:15:28 -0700

John,

A configurable provisioning scheme sounds nice until you realize a defined and provisioned method to encode CIDR prefixes in binary existed several years with suitable input schemes before SPF's text approach was developed.  Bind was not the barrier.  It was RPC templates missing in Windows.  Substantial amounts were offered to those willing to implement Sender-ID, but they themselves were unable to support established DNS resource records?  Do you really think had there been a provisioning scheme in place things would have been different?  

If done today, Lists of Address Prefixes (APL RR) sets offer a superior solution.  If APL instead of TXT had been the choice made then, configuring prefixes would be easier and less burdened with unused options and poorly considered features.  A prefix label in SRV fashion with APL offers more interesting, concise, and cleaner results.  This may not convince a web designer wanting to add dancing fruit, but XMPP used web techniques to implement a safer and more scalable StartTLS solution using binary RRs.  Why not do the same with SMTP?  

Regards,
Douglas Otis