Re: provisioning software, was DNS RRTYPEs, the difficulty with

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In message <alpine.BSF.2.00.1203070926260.60146@xxxxxxxxx>, "John R. Levine" wr
ites:
> Gee, by sheer random walk this has wandered back to the original topic, 
> that provisioning software is the major bar to deploying new RRs.
> 
> > Most provisioning systems really don't care about most of the data
> > they are throwing about.  It may as well be a opaque blob.
> 
> I couldn't disagree more.  Other than my own homebrew system, all the 
> provisioning systems I know support a handful of specific RR types and 
> make it somewhere between painful and impossible to install anything else.
> 
> Godaddy's is a good and very large example of this.  They have a "wizard" 
> to create an SPF record, but it turns out to be a TXT record.  If you want 
> a real type 99 SPF record, you're out of luck.
> 
> Assuming you're not talking about editing zone files with vi, can you give 
> some specific examples of what you're talking about?

Most provisioning systems dump the records into a database and have
some other process extract them from the database and build the
input to the nameserver.  Those database records are also what the
customer updates when they next come back.

One of the problems with provisioning systems is they are mostly
based on a pre RFC 3597 view of the world where you *needed* to
know the type specific presentation format to enter the data.  In
a post RFC 3597 world it is possible to enter any record you want
with a common format.  You can dump that record straight into the
nameserver, nsupdate or any other RFC 3597 aware tool and it will
handle it.

GoDaddy, for example, could handle HIP, SSHFP and IPSECKEY with the
same input dialog if they wanted to by accepting the UNKNOWN record
format.  They could also handle the next type that is invented with
that same dialog box.

Stop asking for type XXXX support and ask for UNKNOWN record support
from your provider.  UNKNOWN record support will handle type XXXX
and anything new that will come along.

By supporting UNKNOWN record format, providers get to know which
types are actually being used by their customers and can then hire
developers to add support for the types that are actually being
used.

Tools to convert between UNKNOWN and type specific representations
will appear.  They are trivial to write.  This is the sort of thing
a 1st year CS student should be able to write as a learning exercise.
I would give the one type to convert for the exercise but that the
level of skill needed.

Take SPF as a example.  If providers had supported UNKNOWN format
then the SPF generation tools would have done UNKNOWN + SPF type
specific rather than TXT + SPF.

Mark

> Regards,
> John Levine, johnl@xxxxxxxx, Primary Perpetrator of "The Internet for Dummies
> ",
> Please consider the environment before reading this e-mail. http://jl.ly
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@xxxxxxx
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]