Re: [dane] Deployment considerations - Re: draft-ietf-dane-smime

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Dan York writes:
>
>
> On Oct 20, 2014, at 11:54 AM, Paul Hoffman
> <[e-mail]<mailto:[e-mail]>> wrote:
>
> On Oct 20, 2014, at 8:23 AM, Osterweil, Eric
> <[e-mail]<mailto:[e-mail]>> wrote:
>
> , so necessarily coupling the RRs doesn't seem to make sense.
>
> It has so far in the WG. The WG asked us early on to make as few changes
> as possible to the TLSA definition.
>
> This is a key point to me.  If we are to make DANE truly successful and
> get DANE-related records out there widely, they need to be *easily*
> deployed out there.  Right now, for a great number of people out there,
> their experience of adding DNS records is to go to their DNS hosting
> provider (or very often their DNS *registrar* that is also doing the DNS
> hosting for them) and enter in DNS records through some form of web
> interface.
>
> One of the challenges we *already* face is to get those DNS hosting
> providers to add support for TLSA records.  I just went to the "domain
> manager" for an extremely larger registrar/hosting provider and looked at
> the list of DNS records that I can add as a user:  A, CNAME, MX, TXT,
> SPF, SRV, AAAA, NS.   No TLSA.  No option I saw to edit the zone file
> directly.
>
> Until we can get that large DNS registrar/hosting provider to add support
> for TLSA records to the management GUI, all the people using them can't
> use DANE.    Given the zillion other things they want to do, I would
> suspect that it's going to take some good number of customers asking to
> get them to do so.   And that's just *one* DNS hosting provider.
>
> I think it's going to be hard enough to get DNS hosting providers to add
> the TLSA record to their list of supported record types, let alone asking
> them to *also* add the SMIMEA record to the list of supported record
> types.  BUT... if SMIMEA is basically a renamed TLSA, then you can make
> that argument to them "it's just the same fields you have for TLSA but
> with a different name".  If they have already added TLSA support, adding
> SMIMEA can be just a case of re-using the code.   However, if SMIMEA adds
> more fields then it means the DNS hosting providers have to develop new
> code... and so the case has to be made to all of them about why they
> should add yet-another-record-type to their GUIs.
>
> Personally, I think it would be great if every "DANE-like" usage would
> just use the TLSA record... then we have to only fight that battle once
> to get it added into configuration/management GUIs.    But if we are to
> create other TLSA-like records to have different names, let's at least
> please keep them the same so that we can get them all more easily
> deployed.

This is one of the reasons we wrote "named-rrchecker".  It is a
simple tool that can list out the records types it supports so you
can dynamically build a list of named record types to use along side
TYPE#####.

The currently supported type list is:

A NS MD MF CNAME SOA MB MG MR NULL WKS PTR HINFO MINFO MX TXT RP
AFSDB X25 ISDN RT NSAP NSAP-PTR SIG KEY PX GPOS AAAA LOC NXT EID
NIMLOC SRV ATMA NAPTR KX CERT A6 DNAME APL DS SSHFP IPSECKEY RRSIG
NSEC DNSKEY DHCID NSEC3 NSEC3PARAM TLSA HIP CDS CDNSKEY SPF UINFO
UID GID UNSPEC NID L32 L64 LP EUI48 EUI64 URI CAA DLV

It will also parse the matching records using presentation format
if that is known and unknown record format and emit the record in
unknown record format and/or presentation format if that has been
defined.

Unknown record format means you don't have to update the name servers
everytime you update named-rrchecker.  This is suitable to be added
to any master file or to be used as input to nsupdate.

The presentation format is useful for displaying to the user what
they just entered cleaned up / converted from unknown record format.

You don't need to update web forms to add new types.  You just
update named-rrchecker periodically and the front end picks up
support for the new RR type.

Mark

> My 2 cents,
> Dan
>
> --
> Dan York
> Senior Content Strategist, Internet Society
> [e-mail]<mailto:[e-mail]>   [phone]
> Jabber: [e-mail]<mailto:[e-mail]>
> Skype: danyork   http://twitter.com/danyork
>
> http://www.internetsociety.org/deploy360/

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]