Re: [dnsext] getting people to use new RRTYPEs

[Douglas Otis <[e-mail]>]

On Apr 26, 2013, at 4:14 PM, "John Levine" <[e-mail]> wrote:

>> On Thu, Apr 25, 2013 at 06:41:31PM -0700, Doug Barton wrote:
>> 
>>> 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!
>> 
>> 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.  
> 
> 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.

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