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

On 06/Mar/12 04:56, ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com wrote:
> > On 05/Mar/12 18:09, John Levine wrote:
> >
> > > Would you really want to build an SPF or DKIM parser into every
> > > DNS server?  That's a lot of code that the DNS manager doesn't
> > > care about, but the mail manager does.
> > But it would be the same code, most likely by the same author(s).
> There are some false equivalences floating around here. I don't
> think anyone is suggesting that having provisioning systems or even
> DNS servers themselves check for syntax errors in the contents of
> complex records like DKIM, SPF, DMARC, or whatever is necessarily a
> bad idea. (Whether or not it will actually happen is another
> matter; I'm dubious.)
>
> Rather, the issue is with requiring it to happen in order to deploy
> a new RRTYPE of this sort, which is the result you get if the DNS
> server returns some series of tokens instead of the original text
> string. That's the sort of thing that forces people to upgrade, or
> search around for a script to do the conversion (which won't even
> occur to some), and that's an extra burden we don't need to
> impose.
It would still be possible to work around the need for a plugin, e.g.
by depending on some wizard web site, as in John's thought experiment.

For the rest of us, the possibility to install a plugin that takes
care of all the nitty-gritty details, instead of having to wait for
the release and distribution of the next version of BIND, can make the
difference between deploying a new RR type right away and
procrastinating endlessly.

> > Why is it important what the DNS manager cares about?
> Speaking as a DNS manager myself, I care a lot about being forced
> to upgrade. Upgrades bring unwanted bugs in other areas.
(I'd be surprised if bugs in any area were wanted ;-)

The issue is to upgrade once rather than on each new RR type.

> In fact I'm not entirely thrilled with the idea of plugins to do
> some extra syntax. More code means more possibilities of bugs. I'd
> actually prefer to see more cross-checking of existing stuff - less
> code and greater benefit.
Depending on how the plugin mechanism is engineered, code insulation,
data encapsulation, and component tests against large samples of data
may help reduce bugs.

To me, an important point is that zone files keep containing data
"source", rather than the output of possibly unreproducible commands.
 Diagnostic-mode execution of the plugin together with a text-based
/etc/rrtypes may even allow to mechanically build GUI dialogs for each
type, whether for the web or for the desktop.

> > Parsers, including null parsers, would come with the same
> > sub-package that enables the new RR type definition.  Their
> > complexity would only matter to the people who read/maintain
> > their sources.
> I'm sorry, but you're being naive about this. Complexity does
> matter to the people who just use software because added complexity
> translates to more bugs.
Correct, but when you publish a complex record you are calling forth
that complexity.  I don't see much difference if the bug is at mines
or at the remote site, since their effects are comparable.

Generating zone files full of hex escapes, so as to do without any
plugin, can --perhaps should-- stay possible.  However, I doubt that
such usage would result in less bugs, on average.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf