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

In message 
<alpine(_dot_)BSF(_dot_)2(_dot_)00(_dot_)1203020941360(_dot_)37874(_at_)joyce(_dot_)lan>,
 "John R. Levine" wr
ites:
> > > By the way, what's your opinion of draft-levine-dnsextlang-02?
> > It isn't clear to me what problem you're trying to solve. For resolving
> > name servers 3597 should be enough. For authoritative name servers your
> > idea is sort of interesting, but generally upgrading the software to
> > pick up support for new RRtypes is a good idea, since you'll also pick
> > up new security fixes, etc.
> Oh, wow.  Now I see the problem: people here are totally unaware of what 
> using DNS software is like if you're not a DNS weenie.
>
> If you think that it's reasonable to require a new version of your DNS 
> software every time there's a new RR, you've conceded total defeat.  On 
> most servers I know, software upgrades are risky and infrequent.  It could 
> easily take a year for a new version of BIND to percolate out of the lab, 
> into the various distribution channels, and to be installed on people's 
> servers, by which time everyone has built their applications with TXT 
> records and it's too late.
Well for BIND it's add a new file that defines the type's methods
and recompile.  That isn't a whole new version.

> Moreover, the servers aren't the hard part, it's the provisioning systems. 
> You and I may edit our zone files with emacs, but civilians use web based 
> things with pulldown menus and checkboxes.  If they can't enter an RR into 
> one of them it doesn't matter whether the name server supports it or not. 
> This latest round of teeth gnashing was provoked by discussions in the 
> spfbis WG, where we're wondering whether to deprecate the type 99 SPF 
> record.  Among the reasons it's unused in practice is that nobody's 
> provisioning system lets you create SPF records.
Which is why there is a format for unknown types.  You can cut and
paste them as easily as known types.  Unfortunately the provision
systems often do a subset of RFC 1035 types let alone anything
newer.  Basically they are often just plain garbage.

> The point of my draft is that it's an extension language that both name 
> servers and provisioning systems can read on the fly.  Add a new stanza to 
> /etc/rrtypes and you're done, no software upgrades needed.  The risk is 
> much lower since the worst that will happen if the new stanza is broken is 
> that the provisioning software and name servers will ignore it, not 
> that the whole thing will crash.
>
> Sure, there are some RRs with complex semantics that can't be done without 
> new code (DNSSEC being the major example), but most RRs are syntactically 
> and semantically trivial, just a bunch of fields that the server doesn't 
> even interpret once it's parsed the master records or their equivalent.
>
> Until the DNS crowd admits that provisioning systems are a major 
> bottleneck, and telling people to hand-code more types into them isn't 
> going to happen, there's no chance of getting more RRs deployed.
Until provisoning systems accept UNKNOWN record types they will
always be a bottle neck.  Without that you will have to wait for
the change request to be processed.  Given the history just getting
AAAA records added to most of these system it will be forever.

All the tools we ship support UNKNOWN record types and classes.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf